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

From: Basavaraj Patil <[email-masked]>
Date: Wed, 30 May 2007 17:26:58 -0500

Hi Kuntal,

I agree that the mh-signaling draft is generic. But my point is that we
could utilize such a generic signaling mechanism as the means to solve some
of the issues such as binding revocation in addition to the examples that
the I-D provides from an applicability perspective.
I guess the argument here is that binding revocation is special type of
signaling that needs to be specified in new messages and cannot be addressed
by the mh-signaling draft.
This is the point that I am not convinced about.

If we have good arguments that the generic signaling mechanism is
inadequate, we can specify binding revocation separately. I guess one
argument is the fact that no ack is required as per the mh-signaling I-D.

Some example scenarios why the mh-signaling message is not apt for binding
revocations would help.

-Raj

On 5/30/07 4:40 PM, "ext Chowdhury, Kuntal" <[email-masked]>
wrote:

> Hi Raj,
> 
> I think the confusion is regarding the scope of the two documents.
> 
> I think the scope of I-D: mh-signaling is quite generic with many uses
> cases as described in that document. Besides the uses cases that are
> described in that document there may be other use cases that are
> deployment specific. That's why I would consider this document to have a
> generic scope with opaque container to accommodate many uses cases. No
> response from the receiver is mandated in this mechanism.
> 
> The scope of I-D: binding-revocation is very specific i.e. revoke the
> mobility binding with the MN, HA, (and MAG, LMA). The use cases for this
> mechanism are specific as well. A response from the receiver is mandated
> in some cases in this mechanism.
> 
> So, I think we should agree on the scope of these two documents and
> progress both of them through the IETF process.
> 
> BR,
> Kuntal
> 
> 
>> -----Original Message-----
>> From: Basavaraj Patil [mailto:[email-masked]]
>> Sent: Wednesday, May 30, 2007 12:19 PM
>> To: ext Ahmad Muhanna; [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-revocatio
>>> 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
> 
> 
> "This email message and any attachments are confidential information of
> Starent Networks, Corp. The information transmitted may not be used to create
> or change any contractual obligations of Starent Networks, Corp.  Any review,
> retransmission, dissemination or other use of, or taking of any action in
> reliance upon this e-mail and its attachments by persons or entities other
> than the intended recipient is prohibited. If you are not the intended
> recipient, please notify the sender immediately -- by replying to this message
> or by sending an email to [email-masked] -- and destroy all
> copies of this message and any attachments without reading or disclosing their
> contents. Thank you."

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

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Thu, 31 May 2007 11:00:47 -0400

Hi Raj,

The revocation procedure that we proposed can be defined using the
mh-signaling message framework. In order to do that, we have to embed
the revocation message as a sub-type (or something like that) of the
Mobility Header type. 

Embedding a message within another message is not a clean design, IMHO.
I think the scope of the two documents should be left as is:

Mh-signaling message: sending opaque TLVs
Revocation message: revoke mobility binding

-Kuntal

> Sent: Wednesday, May 30, 2007 5:27 PM
> To: Chowdhury, Kuntal; ext Ahmad Muhanna; [email-masked]
> > Starent Networks, Corp. The information transmitted may not be used
to
> create
> > or change any contractual obligations of Starent Networks, Corp.
Any
> review,
> > retransmission, dissemination or other use of, or taking of any
action
> in
> > recipient, please notify the sender immediately -- by replying to
this
> message
> > or by sending an email to [email-masked] -- and
destroy
> all
> > copies of this message and any attachments without reading or
disclosing
> their