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

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

Hi Ben,

Not at all. 
I just thought that would work better for you. But, I am okay with
keeping the text and adding the note.

Regards,
Ahmad
 

> -----Original Message-----
> From: Ben Campbell [mailto:[e-mail]] 
> Sent: Wednesday, September 16, 2009 5:32 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,
> 
> 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!
> >>>>>
> >>>
> >>>
> 
>