Subject: ] RE: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt

From: "Mohamed Khalil" <[email-masked]>
Date: Thu, 31 May 2007 12:59:21 -0500

Hi Brian,

please, see my comments

-----Original Message-----
From: Brian Haley [mailto:[email-masked]] 
Sent: Thursday, May 31, 2007 11:00 AM
To: Khalil, Mohamed (RICH2:2S20)
Cc: Basavaraj Patil; [email-masked]
Subject: Re: [Mip6] FW: I-D
ACTION:draft-muhanna-mip6-binding-revocation-00.txt

Hi Mohamed,

Mohamed Khalil wrote:
> Hi Raj,
> 
> If we include revocation protocol in information options, we will end
> up with three levels of protocol complexity as follows:
> 
> 1- The Information option Request message.
> 2- The information option containing the revocation request, let us
> call it revocation option.
> 3- the revocation attributes, or sub-options.

How often do you think additional attributes/sub-options will be 
present?  In every message?  Will they be defined in a -02 version of 
the draft or is that something for another draft?

Mohamed>> There are multiple attributes including MNs' NAI(s), network
prefix(es) (new or old), IP address(es), time for session to expire etc
could be defined by this  document or by other documents to specify the
behavior of revoked session(s). A multiple of those attributes may be
included in each message depending on the revoked session and the status
of the network.          

-Brian

> This means that the revocation option needs to be structured very much
> similarly to the Binding Revocation Indication message, as per Binding

> Revocation draft, where it has to carry all possible options as 
> sub-options. This simply a control protocol imbedded inside another 
> one which introduce unnecessary complexity.
> 
> If we don't have this container mechanism, the process is simple.
> 
> 1- The revocation protocol request message.
> 2- The revocation related options.
> 
> Regards
> 
> Mohamed
> 
> -----Original Message-----
> From: Basavaraj Patil [mailto:[email-masked]]
> Sent: Wednesday, May 30, 2007 3:24 PM
> To: Khalil, Mohamed (RICH2:2S20); [email-masked]
> Subject: Re: [Mip6] FW: I-D 
> ACTION:draft-muhanna-mip6-binding-revocation-00.txt
> 
> 
> 
> MK,
> 
> I don't think anyone is designing a new protocol here. In MIP6 we have
> a protocol (RFC3775) and are now extending it for meeting some of the 
> requirements which would enable deployment and adding a few new 
> limited features.
> 
> The mobility header signaling message is a generic extension that can
> be used for various purposes as indicated in the draft itself. To me 
> binding revocation is merely another notification. I don't understand 
> what complexities you are refering to below or processing issue.
> 
> Can you clarify why the binding revocation cannot be solved by the
> specification of an option in the mobility header signaling message?
> 
> -Raj
> 
> 
> On 5/30/07 2:41 PM, "ext Mohamed Khalil" <[email-masked]> wrote:
> 
>> Hi Raj,
>>
>> I strongly disagree on the idea of designing a protocol which is used

>> as a container for other protocols. Each protocol should have a 
>> limited scope and designed according to certain requirements. It is 
>> very difficult to design  a generic protocol which satisfy all the 
>> requirements for all future protocols. This container idea has many 
>> issues, the simplest is that it increases, unnecessarily, the 
>> processing time for the contained protocol (e.g. revocation). In 
>> addition there some situations where a simple Request/Reply will not 
>> be enough to do the job. Let us leave each protocol designer(s) to do

>> what it is required to do and don't limit their thinking.
>>
>> -----Original Message-----
>> From: Basavaraj Patil [mailto:[email-masked]]
>> Sent: Wednesday, May 30, 2007 12:19 PM
>> To: Muhanna, Ahmad (RICH1:2H10); [email-masked]
>> Subject: Re: [Mip6] FW: I-D 
>> ACTION:draft-muhanna-mip6-binding-revocation-00.txt
>>
>>
>>
>> Ahmad,
>>
>> Binding revocation is a useful feature.
>> However, we have a I-D: Mobility Header Signaling Message 
>> <draft-haley-mip6-mh-signaling-02.txt> which can be used as the means

>> for binding revocation as well.
>>
>> In Prague, we discussed this I-D and agreed to consider it as a WG 
>> document.
>>
>> -Raj
>>
>>
>> On 5/28/07 7:43 AM, "ext Ahmad Muhanna" <[email-masked]> wrote:
>>
>>>  
>>> Hello Folks,
>>>
>>> We submitted this draft for Binding Revocation for IPv6 Mobility. It

>>> handles several use cases which are applicable to Client Mobile IPv6

>>> and PMIPv6. Please take a look and we appreciate your comments.
>>>
>>> Thanks in advance.
>>>
>>> Regards,
>>> Ahmad Muhanna
>>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]]
>>> Sent: Friday, May 25, 2007 2:50 PM
>>> To: [email-masked]
>>> Subject: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts 
>>> directories.
>>>
>>>
>>> Title  : Binding Revocation for IPv6 Mobility
>>> Author(s) : A. Muhanna, et al.
>>> Filename : draft-muhanna-mip6-binding-revocation-00.txt
>>> Pages  : 18
>>> Date  : 2007-5-25
>>>
>>>    The service binding revocation semantics are missing in Mobile
> IPv6
>>>    Specificaion [RFC-3775] and PMIPv6 [PMIP6-SPEC].  This document
>>>    defines the semantics of the revocation of a mobile node
>> registration
>>>    binding, which could have been established using a Client Mobile
>> IPv6
>>>    or a Proxy Mobile IPv6 signaling.  The proposed revocation
>> mechanism
>>>    uses generic message properties which is applicable to Mobile
IPv6
>>>    and Proxy Mobile IPv6 and can be used by any two mobility
> entities.
>>>    As an example, this mechanism allows local mobility agent,
> involved
>>>    in providing IP mobility services to a mobile node, to notify the
>>>    mobility access gateway of the termination of the mobile node
>>>    registration.
>>>
>>>
>>>
>>> A URL for this Internet-Draft is: 
>>> http://www.ietf.org/internet-drafts/draft-muhanna-mip6-binding-revoc
>>> a
>>> t
>>> io
>>> n-00.txt
>>>
>>> To remove yourself from the I-D Announcement list, send a message to

>>> [email-masked] with the word unsubscribe in the body 
>>> of the message. You can also visit
>>> https://www1.ietf.org/mailman/listinfo/I-D-announce
>>> to change your subscription settings.
>>>
>>> Internet-Drafts are also available by anonymous FTP. Login with the 
>>> username "anonymous" and a password of your e-mail address. After 
>>> logging in, type "cd internet-drafts" and then "get 
>>> draft-muhanna-mip6-binding-revocation-00.txt".
>>>
>>> A list of Internet-Drafts directories can be found in 
>>> http://www.ietf.org/shadow.html or 
>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>>> Internet-Drafts can also be obtained by e-mail.
>>>
>>> Send a message to:
>>> [email-masked].
>>> In the body type:
>>> "FILE
>>> /internet-drafts/draft-muhanna-mip6-binding-revocation-00.txt".
>>>
>>> NOTE: The mail server at ietf.org can return the document in 
>>> MIME-encoded form by using the "mpack" utility.  To use this 
>>> feature,
> 
>>> insert the command "ENCODING mime" before the "FILE" command.  To 
>>> decode the response(s), you will need "munpack" or a MIME-compliant 
>>> mail reader.  Different MIME-compliant mail readers exhibit 
>>> different
> 
>>> behavior, especially when dealing with "multipart" MIME messages 
>>> (i.e. documents which have been split up into multiple messages), so

>>> check your local documentation on how to manipulate these messages.
>>>
>>> Below is the data which will enable a MIME compliant mail reader 
>>> implementation to automatically retrieve the ASCII version of the 
>>> Internet-Draft. _______________________________________________
>>> Mip6 mailing list
>>> [email-masked]
>>> https://www1.ietf.org/mailman/listinfo/mip6
>>
>> _______________________________________________
>> Mip6 mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/mip6
>>
>> _______________________________________________
>> Mip6 mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/mip6
> 
> 
> _______________________________________________
> Mip6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mip6
> 

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6