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:ben@xxxxxxxxxxxx] > Sent: Wednesday, September 16, 2009 5:32 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, > > 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); 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