Re: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10

[Ben Campbell <[e-mail]>]

Hi Ahmad,

I guess that's okay since the removed text talks about behavior under  
an error condition anyway, so I won't object further if you do it this  
way. But I actually prefer the old text with the warning about  
retransmissions. My concern is, the proposal below simply leaves the  
case of A being set but having no matching binding undefined. I think  
that makes implementors even more likely to decide not to send a BRA  
in that case.

  Is the warning about retransmissions causing concern?

On Sep 16, 2009, at 5:19 PM, Ahmad Muhanna wrote:

> Hello Ben,
>
> Thinking about this a little more, I think that you also would  
> accept if
> we remove the text causing grief all together:) In other words, what
> about if we reword the text as below:
>
> OLD TEXT:
> =========
>   o  If the Acknowledge (A) bit is set in the Binding Revocation
>      Indication and its Binding Update List contains an entry for the
>      IP address in the Type 2 routing header, the mobile node MUST  
> send
>      a Binding Revocation Acknowledgement.  However, in all other  
> cases
>      when the Acknowledge (A) bit is set in the BRI, the mobile node
>      SHOULD sends a Binding Revocation Acknowledgement, the mobile  
> node
>      MUST do so according to Section 10.2.
>
> NEW TEXT:
> =========
>
>   o  If the Acknowledge (A) bit is set in the Binding Revocation
>      Indication and its Binding Update List contains an entry for the
>      IP address in the Type 2 routing header, the mobile node MUST  
> send
>      a Binding Revocation Acknowledgement.
>
>
> This way we do not need to add the clarification note.
>
> What do you think?
>
> Please let me know and many thanks again!
>
> Regards,
> Ahmad
>
>
>> -----Original Message-----
>> From: Muhanna, Ahmad (RICH1:2H10)
>> Sent: Monday, September 14, 2009 2:06 PM
>> To: 'Ben Campbell'
>> Cc: Khalil, Mohamed (RICH2:2S20); [e-mail];
>> [e-mail]; General Area Review Team; [e-mail];
>> Jari Arkko; [e-mail]; Laganier, Julien
>> Subject: RE: Gen-ART LC and Telechat Review of
>> draft-ietf-mext-binding-revocation-10
>>
>> Hi Ben,
>>
>> I am fine with your proposed text.
>> Many thanks for your review and comments.
>>
>> Regards,
>> Ahmad
>>
>>
>>> -----Original Message-----
>>> From: Ben Campbell [mailto:[e-mail]]
>>> Sent: Monday, September 14, 2009 2:02 PM
>>> To: Muhanna, Ahmad (RICH1:2H10)
>>> Cc: Khalil, Mohamed (RICH2:2S20); [e-mail];
>>> [e-mail]; General Area Review Team; [e-mail]; Jari
>>> Arkko; [e-mail]; Laganier, Julien
>>> Subject: Re: Gen-ART LC and Telechat Review of
>>> draft-ietf-mext-binding-revocation-10
>>>
>>> Hi Ahmad,
>>>
>>> Please see inline for my suggested text for the
>> retransmission issue.
>>> Otherwise, I agree this closes the open issues.
>>>
>>> Thanks!
>>>
>>> Ben.
>>>
>>> On Sep 12, 2009, at 3:23 AM, Ahmad Muhanna wrote:
>>>
>>>> Hi Ben,
>>>> Hopefully we can close on all of the open issues.
>>>> Please see inline.
>>>>
>>>> Regards,
>>>> Ahmad
>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Ben Campbell [mailto:[e-mail]]
>>>>>>> Subject: Re: Gen-ART LC and Telechat Review of
>>>>>>> draft-ietf-mext-binding-revocation-10
>>>>>>>
>>>>>>> This is a followup on revision 12, since it came out
>>>>> before I got to
>>>>>>> revision 11:
>>>>>>>
>>>>>>> Overall, I think this revision is much better. Most of
>>> my concerns
>>>>>>> have been addressed, but I have a few minor ones remaining.
>>>>>>>
>>>>>>> Specific comments:
>>>>>>>
>>>>>>>
>>>>>>> -- Section 10.1, 2nd bullet:
>>>>>>>
>>>>>>> I don't think we resolved my concern about the SHOULD
>>> in the last
>>>>>>> sentence. To recap, I think that needs to either be a
>>> MUST, or the
>>>>>>> draft should offer guidance about the reasoning for the
>>> SHOULD and
>>>>>>> the consequences of not following it. I'm picking on
>> this one in
>>>>>>> particular because it seems like not sending a BRA when
>>>>> the A bit was
>>>>>>> set is likely to cause retransmissions on the part of the
>>>>> initiator.
>>>>>>
>>>>>> [Ahmad]
>>>>>> If the MN does NOT have a binding in its BUL for the HoA
>>>>> address that
>>>>>> is included in the Type 2 Routing header, the mobile node
>>>>> should not
>>>>>> respond back (that was specifically discussed in details
>>> on the wg
>>>>>> ml).
>>>>>> It is like instructing the MN to delete a session that does
>>>>> not exist.
>>>>>> Although, the (A) bit is set, it is up to the mobile node
>>>>> whether to
>>>>>> send a BRA or not. I do not believe we need to mandate
>> that via a
>>>>>> MUST.
>>>>>> I am sure some handset vendors will not like that at all.
>>>>>
>>>>> Did the work group consider that if a MN doesn't respond, it can
>>>>> expect to get a bunch of retransmissions--each of which it
>>> will need
>>>>> to parse, check for bindings, etc.; possibly eating more
>> resources
>>>>> than responding in the first place would have?
>>>>>
>>>>> I could understand if the concern was that the MN might get
>>>>> irrelevant (or even malicious) BRIs from arbitrary
>>> sources, but since
>>>>> they should only be arriving from trusted peers over
>>> established SAs,
>>>>> I find the choice surprising.
>>>>>
>>>>> But in any case, my concern was that it should be a MUST _or_ it
>>>>> should have discussion of the consequences of not doing
>>> it. A line or
>>>>> two mentioning why this is a should, under what circumstances it
>>>>> makes sense to not respond, and most importantly
>> pointing out the
>>>>> potential for needless retransmission would help.
>>>>
>>>> [Ahmad]
>>>> Yes we discussed that, but there are cases when the MN is
>>> not able to
>>>> send a BRA, for example, losing coverage, etc. "SHOULD"
>>> still a very
>>>> strong requirement, the node MUST do it unless there is a
>> very good
>>>> valid reason not to.
>>>
>>>> But, please see below.
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>> Also, the last sentence does not seem to make grammatical
>>>>> sense after
>>>>>>> the edits.
>>>>>>
>>>>>> Thx, here is the new text, please let me know if you are
>>>>> okay with it.
>>>>>>
>>>>>> o  If the Acknowledge (A) bit is set in the Binding Revocation
>>>>>>    Indication and its Binding Update List contains an
>>>>> entry for the
>>>>>>    IP address in the Type 2 routing header, the mobile
>> node MUST
>>>>>> send
>>>>>>    a Binding Revocation Acknowledgement.  However, in
>> all other
>>>>>> cases
>>>>>>    when the Acknowledge (A) bit is set in the BRI, the
>>> mobile node
>>>>>>    SHOULD sends a Binding Revocation Acknowledgement following
>>>>>> Section 10.2.
>>>>>
>>>>> That's better, depending on the resolution of the SHOULD
>>> discussion
>>>>> above.
>>>>
>>>> [Ahmad]
>>>> Here is the text with the proposed addition as suggested above:
>>>>
>>>>  o  If the Acknowledge (A) bit is set in the Binding Revocation
>>>>     Indication and its Binding Update List contains an
>>> entry for the
>>>>     IP address in the Type 2 routing header, the mobile
>> node MUST
>>>> send
>>>>     a Binding Revocation Acknowledgement.  However, in all other
>>>> cases
>>>>     when the Acknowledge (A) bit is set in the BRI, the
>> mobile node
>>>>     SHOULD sends a Binding Revocation Acknowledgement following
>>>> Section
>>>>     10.2. In the case when the MN does not send a BRA message in
>>>> response
>>>>     to a BRI with the Acknowledge (A) bit is set, the MN
>>> may receive
>>>> a
>>>>
>>>>     retransmit of the BRI message.
>>>>
>>>> Is that acceptable?
>>>>
>>>
>>> Mostly. I would say "one or more" retransmissions, as they
>> are likely
>>> to get several. Also, keep in mind this causes additional
>> work for the
>>> initiator, who would have to retransmit in the first case. Perhaps
>>> something to the effect of:
>>>
>>>  "Note that anytime the MN does not send an requested
>> acknowledgement
>>> to a BRI, the initiator is likely to retransmit the BRI multiple
>>> times. This causes additional load on the initiator who sends the
>>> retransmissions, as well as on the MN that will receive and process
>>> them."
>>>
>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>> -- Same section, 4th bullet:
>>>>>>>
>>>>>>> This one  still seems to ignore the A bit value. Given
>> the other
>>>>>>> edits, am I correct in assuming that you expect a BRA if
>>> the A bit
>>>>>>> was set, otherwise a silent discard?
>>>>>>
>>>>>> [Ahmad]
>>>>>> I believe we discussed this a little before. It is a fatal
>>>>> error and
>>>>>> the
>>>>>> MN should never receive a BRI with the (P) bit set.
>> That why this
>>>>>> behavior is the same regardless of the (A) bit is set or
>>> not. If you
>>>>>> feel that some clarification about the (A) bit needs to be
>>>>> added, I
>>>>>> can
>>>>>> say,
>>>>>> ...... regardless if the Acknowledge (A) bit is set or not,
>>>>> the mobile
>>>>>> node MUST silently discard the BRI message.
>>>>>
>>>>> From previous discussion, I thought we had converged on
>>> the idea that
>>>>> the A-bit should always be authoritative, rather than having the
>>>>> A-bit treatment change due to context. Again, my concern
>>> is that the
>>>>> sender is likely to retransmit multiple times if you
>> don't respond.
>>>> [Ahmad]
>>>> Yes, the (A) bit is authoritative when it is used
>> according to this
>>>> specification. If used in violation of this
>> specification, then we
>>>> should have the choice to NOT allow it to be that authoritative!
>>>> Again, this is a fatal error that is NOT supposed to
>>> happen. But, what
>>>> about if we recommend to the MN to send a BRA with code
>> "Revocation
>>>> Function NOT Supported"
>>>
>>> I like the idea of recommending sending the BRA with a
>> non-supported
>>> code.
>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>> -- Section 11, (InitMINDelayBRIs) (I think I commented 
>> on this,
>>>>>>> but can't find the resolution)
>>>>>>>
>>>>>>> Did you intend for the _default_ to be a range
>> (between .5 and 1
>>>>>>> sec), or did you mean to say the default was 1 second, and it
>>>>>>> must not be configured to less than .5 seconds? I suspect the
>>>>>>> latter, but it's not clear from the text.
>>>>>>
>>>>>> [Ahmad]
>>>>>> Sure, will fix this as follows:
>>>>>>
>>>>>> Initial Minimum Delay Between BRI messages (InitMINDelayBRIs)
>>>>>>
>>>>>>    This variable specifies the initial delay timeout in seconds
>>>>>>    before the revoking mobility entity retransmits a
>> BRI message.
>>>>>>    The default is 1 second but not to be configured
>> less than 0.5
>>>>>> seconds.
>>>>>
>>>>> That's better, thanks!
>>>>>
>>>
>>>