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

["Ahmad Muhanna" <[e-mail]>]

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!
> >>
> 
>