Hi Ben, I am fine with your proposed text. Many thanks for your review and comments.
Regards, Ahmad > -----Original Message----- > From: Ben Campbell [mailto:b...@estacado.net] > Sent: Monday, September 14, 2009 2:02 PM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: Khalil, Mohamed (RICH2:2S20); sgund...@cisco.com; > pyeg...@juniper.net; General Area Review Team; ietf@ietf.org; > Jari Arkko; marc...@it.uc3m.es; 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:b...@estacado.net] > >>>> 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 mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
