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); sgundave@xxxxxxxxx;
> pyegani@xxxxxxxxxxx; General Area Review Team; ietf@xxxxxxxx;
> Jari Arkko; marcelo@xxxxxxxxxx; 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:ben@xxxxxxxxxxxx]
> > Sent: Monday, September 14, 2009 2:02 PM
> > To: Muhanna, Ahmad (RICH1:2H10)
> > Cc: Khalil, Mohamed (RICH2:2S20); sgundave@xxxxxxxxx;
> > pyegani@xxxxxxxxxxx; General Area Review Team; ietf@xxxxxxxx; Jari
> > Arkko; marcelo@xxxxxxxxxx; 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:ben@xxxxxxxxxxxx]
> > >>>> 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!
> > >>
> >
> >
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf