Re: [Gen-art] [DISCUSS + Gen-ART] Review of draft-ietf-mext-binding-revocation-10

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

Hello All,

We have submitted a new revision (13) of the Binding Revocation draft
which addresses all comments including Ben and Ralph outstanding ones.
In summary, we did the following:

1. After some discussion, we removed the Acknowledge (A) bit but
maintained the same logic.
2. We also simplified the structure of the document to eliminate
duplication and moved all common text under The Initiator and Responder
sections.
3. For simplification, added new terminology: Initiator and Responder.
4. Defined a new Error Code "Proxy Binding Revocation NOT Supported" to
allow the mobile node to reject a BRI with the (P) bit is set.

Please take a look and let us know if you still have any comments or you
are satisfied with the way your comments have been addressed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation-1
3.txt

Many thanks in advance!


Regards,
Ahmad
 

> -----Original Message-----
> From: Muhanna, Ahmad (RICH1:2H10) 
> Sent: Wednesday, September 16, 2009 5:34 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,
> 
> 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!
> > >>>>>
> > >>>
> > >>>
> > 
> >