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? > > > > >> > >> -- 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" > > > > > >> > >> -- 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