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

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

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