Re: [Gen-art] Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10
Ben Campbell <ben@estacado.net> Wed, 16 September 2009 22:31 UTC
Return-Path: <ben@estacado.net>
X-Original-To: gen-art@core3.amsl.com
Delivered-To: gen-art@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83C573A6882; Wed, 16 Sep 2009 15:31:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level:
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3U1oSyuUHCk9; Wed, 16 Sep 2009 15:31:12 -0700 (PDT)
Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 4B0A63A69A7; Wed, 16 Sep 2009 15:31:10 -0700 (PDT)
Received: from dn3-213.estacado.net (dn3-213.estacado.net [172.16.3.213]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n8GMVhZR063139 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 Sep 2009 17:31:43 -0500 (CDT) (envelope-from ben@estacado.net)
Mime-Version: 1.0 (Apple Message framework v1076)
Content-Type: text/plain; charset="us-ascii"; format="flowed"; delsp="yes"
From: Ben Campbell <ben@estacado.net>
In-Reply-To: <C5A96676FCD00745B64AE42D5FCC9B6E20471F32@zrc2hxm0.corp.nortel.com>
Date: Wed, 16 Sep 2009 17:31:43 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <AC2F3747-4ACE-407E-AF13-1A4B0C146DFF@estacado.net>
References: <5D6C0FF6-7B89-42D3-A8FF-FA5177585825@estacado.net> <C5A96676FCD00745B64AE42D5FCC9B6E20008DDA@zrc2hxm0.corp.nortel.com> <31684C7B-E11F-4EC2-BFBC-89A92E64141C@estacado.net> <C5A96676FCD00745B64AE42D5FCC9B6E2024F768@zrc2hxm0.corp.nortel.com> <C51BF7B4-FB47-4B35-9355-F54CF4FEDA33@estacado.net> <C5A96676FCD00745B64AE42D5FCC9B6E20345E87@zrc2hxm0.corp.nortel.com> <189467D4-84E5-465B-ADD0-5392AC560A06@estacado.net> <C5A96676FCD00745B64AE42D5FCC9B6E2038ABBB@zrc2hxm0.corp.nortel.com> <63ABAEBE-E2D3-4584-8833-2001B6DCDB74@estacado.net> <C5A96676FCD00745B64AE42D5FCC9B6E20471F32@zrc2hxm0.corp.nortel.com>
To: Ahmad Muhanna <amuhanna@nortel.com>
X-Mailer: Apple Mail (2.1076)
Cc: "Laganier, Julien" <julienl@qualcomm.com>, ietf@ietf.org, General Area Review Team <gen-art@ietf.org>, pyegani@juniper.net, sgundave@cisco.com, Jari Arkko <jari.arkko@piuha.net>, marcelo@it.uc3m.es, Mohamed Khalil <mkhalil@nortel.com>
Subject: Re: [Gen-art] Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Sep 2009 22:31:13 -0000
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@cisco.com; >> pyegani@juniper.net; General Area Review Team; ietf@ietf.org; >> Jari Arkko; marcelo@it.uc3m.es; 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@estacado.net] >>> Sent: Monday, September 14, 2009 2:02 PM >>> To: Muhanna, Ahmad (RICH1:2H10) >>> Cc: Khalil, Mohamed (RICH2:2S20); sgundave@cisco.com; >>> pyegani@juniper.net; General Area Review Team; ietf@ietf.org; Jari >>> Arkko; marcelo@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:ben@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! >>>>> >>> >>>
- [Gen-art] Gen-ART LC and Telechat Review of draft… Ben Campbell
- Re: [Gen-art] Gen-ART LC and Telechat Review of d… Ben Campbell
- Re: [Gen-art] [PART-I] Gen-ART LC and Telechat Re… Jari Arkko
- Re: [Gen-art] [PART-I] Gen-ART LC and Telechat Re… Ahmad Muhanna
- Re: [Gen-art] [PART-I] Gen-ART LC and Telechat Re… Ben Campbell
- Re: [Gen-art] [PART-I] Gen-ART LC and Telechat Re… Ben Campbell
- Re: [Gen-art] [PART-II] Gen-ART LC and Telechat R… Ahmad Muhanna
- Re: [Gen-art] [PART-I] Gen-ART LC and Telechat Re… Ahmad Muhanna
- Re: [Gen-art] [PART-II] Gen-ART LC and Telechat R… Ben Campbell
- Re: [Gen-art] [PART-I] Gen-ART LC and Telechat Re… Ben Campbell
- Re: [Gen-art] [PART-II] Gen-ART LC and Telechat R… Ahmad Muhanna
- Re: [Gen-art] [PART-I] Gen-ART LC and Telechat Re… Ahmad Muhanna
- Re: [Gen-art] [PART-II] Gen-ART LC and Telechat R… Ben Campbell
- Re: [Gen-art] [PART-II] Gen-ART LC and Telechat R… Ahmad Muhanna
- Re: [Gen-art] [PART-I] Gen-ART LC and Telechat Re… Ben Campbell
- Re: [Gen-art] [PART-I] Gen-ART LC and Telechat Re… Ahmad Muhanna
- Re: [Gen-art] [PART-I] Gen-ART LC and Telechat Re… Ben Campbell
- Re: [Gen-art] [PART-I] Gen-ART LC and Telechat Re… Ahmad Muhanna
- Re: [Gen-art] [PART-I] Gen-ART LC and Telechat Re… Ben Campbell
- [Gen-art] Gen-ART LC and Telechat Review of draft… Ahmad Muhanna
- Re: [Gen-art] Gen-ART LC and Telechat Review of d… Ben Campbell
- Re: [Gen-art] Gen-ART LC and Telechat Review of d… Ahmad Muhanna
- Re: [Gen-art] Gen-ART LC and Telechat Review of d… Ben Campbell
- Re: [Gen-art] Gen-ART LC and Telechat Review of d… Ahmad Muhanna
- Re: [Gen-art] Gen-ART LC and Telechat Review of d… Ben Campbell
- Re: [Gen-art] Gen-ART LC and Telechat Review of d… Ahmad Muhanna
- Re: [Gen-art] Gen-ART LC and Telechat Review of d… Ahmad Muhanna
- Re: [Gen-art] Gen-ART LC and Telechat Review of d… Ben Campbell
- Re: [Gen-art] Gen-ART LC and Telechat Review of d… Ahmad Muhanna
- Re: [Gen-art] [DISCUSS + Gen-ART] Review of draft… Ahmad Muhanna
- [Gen-art] Followup on Gen-ART review of draft-iet… Ben Campbell
- Re: [Gen-art] Followup on Gen-ART review of draft… Ahmad Muhanna
- Re: [Gen-art] Followup on Gen-ART review of draft… Ben Campbell