Re: [MEXT] I-D Action:draft-ietf-mext-binding-revocation-12.txt

Hi Ahmad

On 9/11/09 3:12 PM, "Ahmad Muhanna" wrote:

>> You have confused the heck out of me. :) Ok, back to the
>> issue. The MAG sends a bulk revocation message with the 'G'
>> flag set, but with the 'A' flag not set. What is the LMA
>> behavior for this?
>> 
>> The current text says the LMA must silently discard the BRI.
>> This doesn't make sense.
>> 
>> Can you first explain what the LMA should do before we try to
>> change any text?
> [Ahmad]
> Agreed. I was thinking that the message comes from the LMA to the MAG :(
> 
> 1. If the MAG does not set the (A) bit, it is communicating to the LMA
> that it is NOT interested in getting back a BRA.
> 2. Consequently, when the MAG does not set the (A) bit, it does not
> retransmits the BRI and it does not track the BRI as one of the
> outstanding BRI messages.
> 
> 3. NOW, when the LMA receives such message, as per this specification
> the MAG MUST have set the (A) bit in this case, but it did not. What the
> options for the LMA:
> 
> 3.1. Process the message and remove all bindings without sending a BRA,
> but the MAG did violate the protocol and mandating that the MAG set the
> (A) bit in this case means something.
> 3.2. Process the message and send a BRA with an unsuccessful status
> code, well, the LMA can do that, BUT unfortunately it wont help in
> anything. Because as I said the MAG is NOT expecting a BRA and is not
> tracking the BRI as an outstanding message.
> 3.3. LMA consider this BRI as a violation of the protocol and does not
> remove the mobility sessions based on this message. In addition, since
> the (A) bit is not set, the LMA does not send a BRA. This means, LMA
> discard the message.
> 
> IMO, option No. 3 is the correct one and that what rev 12 text says.

Option 3 is the least acceptable to me. Silently discarding the message
without letting the MAG know that something is wrong doesn't make sense.

Option 2 makes sense. If there is an error in a message you send, you should
always be ready to process the response that points to the error. We might
need to come up with a new status for this.

This actually proves that leaving the ack optional makes no sense.

Vijay

> 
> Hope it is clearer this time.
> 
> Regards,
> Ahmad
> 
>> 
>> Vijay
>> 
>>> 
>>> Regards,
>>> Ahmad
>>> 
>>>> 
>>>> Just removing the 'A' bit would help. :)
>>>> 
>>>> Vijay
>>>> 
>>>>> 
>>>>> Regards,
>>>>> Ahmad
>>>>> 
>>>>>> 
>>>>>> Vijay
>>>>>> 
>>>>>> 
>>>>>> On 9/9/09 11:58 PM, "Ahmad Muhanna" wrote:
>>>>>> 
>>>>>>> FYI,
>>>>>>> 
>>>>>>> A new revision has been published which clarifies further
>>>> the wild
>>>>>>> card NAI as per Pasi's comment. It also uses proper RFC2119
>>>>>>> requirements in couple of places as per Ralph's comment.
>>>>>>> 
>>>>>>> Regards,
>>>>>>> Ahmad
>>>>>>>  
>>>>>>> 
>>>>>>>> -----Original Message-----
>>>>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org]
>>>>>> On Behalf
>>>>>>>> Of Internet-Drafts@ietf.org
>>>>>>>> Sent: Thursday, September 10, 2009 1:45 AM
>>>>>>>> To: i-d-announce@ietf.org
>>>>>>>> Cc: mext@ietf.org
>>>>>>>> Subject: [MEXT] I-D
>>>>>> Action:draft-ietf-mext-binding-revocation-12.txt
>>>>>>>> 
>>>>>>>> A New Internet-Draft is available from the on-line
>>>> Internet-Drafts
>>>>>>>> directories.
>>>>>>>> This draft is a work item of the Mobility EXTensions for
>>>>>> IPv6 Working
>>>>>>>> Group of the IETF.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Title           : Binding Revocation for IPv6 Mobility
>>>>>>>> Author(s)       : A. Muhanna, et al.
>>>>>>>> Filename        : draft-ietf-mext-binding-revocation-12.txt
>>>>>>>> Pages           : 43
>>>>>>>> Date            : 2009-09-09
>>>>>>>> 
>>>>>>>> This document defines a binding revocation mechanism to
>>>>>> terminate a
>>>>>>>> mobile node's mobility session and the associated
>>>>>> resources.  These
>>>>>>>> semantics are generic enough and can be used by mobility
>>>>>> entities in
>>>>>>>> the case of Mobile IPv6 and its extensions.  This
>>>> mechanism allows
>>>>>>>> the mobility entity which initiates the revocation
>> procedure to 
>>>>>>>> request its peer to terminate either one, multiple or all
>>>>>> specified
>>>>>>>> binding(s).
>>>>>>>> 
>>>>>>>> A URL for this Internet-Draft is:
>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-re
>>>>>>> vocation-12.txt
>>>>>>>> 
>>>>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>>>> 
>>>>>>>> Below is the data which will enable a MIME compliant
>> mail reader 
>>>>>>>> implementation to automatically retrieve the ASCII
>>>> version of the
>>>>>>>> Internet-Draft.
>>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> MEXT mailing list
>>>>>>> MEXT@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/mext
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>> 
>> 