Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-02
"Stupar, Patrick" <pstupar@qualcomm.com> Tue, 20 January 2009 10:01 UTC
Return-Path: <mext-bounces@ietf.org>
X-Original-To: nemo-archive@megatron.ietf.org
Delivered-To: ietfarch-nemo-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BA8E3A6A7A; Tue, 20 Jan 2009 02:01:13 -0800 (PST)
X-Original-To: mext@core3.amsl.com
Delivered-To: mext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D69BF3A6A7A for <mext@core3.amsl.com>; Tue, 20 Jan 2009 02:01:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.599
X-Spam-Level:
X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 ZXy37HO6M8Ae for <mext@core3.amsl.com>; Tue, 20 Jan 2009 02:01:10 -0800 (PST)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 5C53A3A69B3 for <mext@ietf.org>; Tue, 20 Jan 2009 02:01:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=pstupar@qualcomm.com; q=dns/txt; s=qcdkim; t=1232445654; x=1263981654; h=x-mimeole:content-class:mime-version:content-type: content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator: thread-topic:thread-index:references:from:to:cc: x-originalarrivaltime:x-ironport-av; z=X-MimeOLE:=20Produced=20By=20Microsoft=20Exchange=20V6.5 |Content-class:=20urn:content-classes:message |MIME-Version:=201.0|Content-Type:=20text/plain=3B=0D=0A =09charset=3D"us-ascii"|Content-Transfer-Encoding:=20quot ed-printable|Subject:=20RE:=20Comments=20on=20draft-ietf- mext-binding-revocation-02|Date:=20Tue,=2020=20Jan=202009 =2009:59:35=20-0000|Message-ID:=20<A39C75E50DED4C43A4B0EA 9B51B0B6B34DE566@EUEX02.eu.qualcomm.com>|In-Reply-To:=20< C5A96676FCD00745B64AE42D5FCC9B6E1CAF5FAF@zrc2hxm0.corp.no rtel.com>|X-MS-Has-Attach:=20|X-MS-TNEF-Correlator:=20 |Thread-Topic:=20Comments=20on=20draft-ietf-mext-binding- revocation-02|Thread-Index:=20AclbLn3taqHuU6TUSgeN3dxQhl2 ykQArrD7gALKdDZAEWRBysAGXgEdQAGd43wAAl3PFsAADWf9wABxFuoA =3D|References:=20<A39C75E50DED4C43A4B0EA9B51B0B6B340478F @EUEX02.eu.qualcomm.com>=20<C5A96676FCD00745B64AE42D5FCC9 B6E1C2CF213@zrc2hxm0.corp.nortel.com>=20<A39C75E50DED4C43 A4B0EA9B51B0B6B3404AC6@EUEX02.eu.qualcomm.com>=20<C5A9667 6FCD00745B64AE42D5FCC9B6E1C7307B3@zrc2hxm0.corp.nortel.co m>=20<A39C75E50DED4C43A4B0EA9B51B0B6B34DE379@EUEX02.eu.qu alcomm.com>=20<C5A96676FCD00745B64AE42D5FCC9B6E1CA46D5F@z rc2hxm0.corp.nortel.com>=20<A39C75E50DED4C43A4B0EA9B51B0B 6B34DE500@EUEX02.eu.qualcomm.com>=20<C5A96676FCD00745B64A E42D5FCC9B6E1CAF5FAF@zrc2hxm0.corp.nortel.com>|From:=20"S tupar,=20Patrick"=20<pstupar@qualcomm.com>|To:=20"Ahmad =20Muhanna"=20<amuhanna@nortel.com>|Cc:=20<mext@ietf.org> |X-OriginalArrivalTime:=2020=20Jan=202009=2010:00:53.0563 =20(UTC)=20FILETIME=3D[FB19A0B0:01C97AE5]|X-IronPort-AV: =20E=3DMcAfee=3Bi=3D"5300,2777,5500"=3B=20a=3D"14797602"; bh=SjKoWhJAXLqzKQ9zgy37nfpDTyxJeifnJAJfky6v9dw=; b=wXV1pDS9s7/azMi+XftZQgqibN5tnbX8usd+QG+RpEg6TMIo4XJXX8Z3 bTbCPFY9jY/3+Wyix/TOGKgORIgVKUJvWXllU09AeAfAhNodGOSWT6m3T MaN2NY1eknGwL/3YBb7RrA0hOuL9ib+Rp5xo5j7SLHBJu787RT0ajjs9t c=;
X-IronPort-AV: E=McAfee;i="5300,2777,5500"; a="14797602"
Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jan 2009 02:00:54 -0800
Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n0KA0suw018280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Jan 2009 02:00:54 -0800
Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n0KA0rJu012802; Tue, 20 Jan 2009 02:00:53 -0800
Received: from EUEX02.eu.qualcomm.com ([10.222.228.33]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Jan 2009 02:00:53 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 20 Jan 2009 09:59:35 -0000
Message-ID: <A39C75E50DED4C43A4B0EA9B51B0B6B34DE566@EUEX02.eu.qualcomm.com>
In-Reply-To: <C5A96676FCD00745B64AE42D5FCC9B6E1CAF5FAF@zrc2hxm0.corp.nortel.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Comments on draft-ietf-mext-binding-revocation-02
Thread-Index: AclbLn3taqHuU6TUSgeN3dxQhl2ykQArrD7gALKdDZAEWRBysAGXgEdQAGd43wAAl3PFsAADWf9wABxFuoA=
References: <A39C75E50DED4C43A4B0EA9B51B0B6B340478F@EUEX02.eu.qualcomm.com> <C5A96676FCD00745B64AE42D5FCC9B6E1C2CF213@zrc2hxm0.corp.nortel.com> <A39C75E50DED4C43A4B0EA9B51B0B6B3404AC6@EUEX02.eu.qualcomm.com> <C5A96676FCD00745B64AE42D5FCC9B6E1C7307B3@zrc2hxm0.corp.nortel.com> <A39C75E50DED4C43A4B0EA9B51B0B6B34DE379@EUEX02.eu.qualcomm.com> <C5A96676FCD00745B64AE42D5FCC9B6E1CA46D5F@zrc2hxm0.corp.nortel.com> <A39C75E50DED4C43A4B0EA9B51B0B6B34DE500@EUEX02.eu.qualcomm.com> <C5A96676FCD00745B64AE42D5FCC9B6E1CAF5FAF@zrc2hxm0.corp.nortel.com>
From: "Stupar, Patrick" <pstupar@qualcomm.com>
To: Ahmad Muhanna <amuhanna@nortel.com>
X-OriginalArrivalTime: 20 Jan 2009 10:00:53.0563 (UTC) FILETIME=[FB19A0B0:01C97AE5]
Cc: mext@ietf.org
Subject: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-02
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mext-bounces@ietf.org
Errors-To: mext-bounces@ietf.org
Hi Ahmad, I don't think that the "MODIFIED" text you proposed is wrong, I think that part of it is redundant and already covered. If you think that your proposal is more suitable I can live with that. Some additional comments below. Regards, Patrick > -----Original Message----- > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > Sent: Tuesday, January 20, 2009 12:23 AM > To: Stupar, Patrick > Cc: mext@ietf.org > Subject: RE: Comments on draft-ietf-mext-binding-revocation-02 > > Hi Patrick, > > As I said, your proposed text for the second bullet was not clear to > me. > On the other hand, the first bullet specify what happened if any of the > two checks fail, i.e. if the received BRI does not have an entry in its > BUL. > > The second bullet specify what happened if these two checks were > successful. There is nothing wrong in being explicit and clear without > any ambiguity. Finally, how come your question is valid against the > clarified text and NOT against yours? > > Can I say that you have a problem with the following text: Can you > specify what is wrong in it? > > o If the Acknowledgement (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. You added the sentence "and its Binding Update List contains an entry for the IP address in the type 2 routing header": this is already described in the previous bullet, that's why I had the comment against your modified text and not mine. But as I said before, it's not wrong but only redundant. > > > Regards, > Ahmad > > > > -----Original Message----- > > From: Stupar, Patrick [mailto:pstupar@qualcomm.com] > > Sent: Monday, January 19, 2009 8:00 PM > > To: Muhanna, Ahmad (RICH1:2H10) > > Cc: mext@ietf.org > > Subject: RE: Comments on draft-ietf-mext-binding-revocation-02 > > > > Hi Ahmad, > > > > Please see below. > > > > Best Regards, > > > > Patrick > > > > > -----Original Message----- > > > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > > Sent: Friday, January 16, 2009 7:51 PM > > > To: Stupar, Patrick > > > Cc: mext@ietf.org > > > Subject: RE: Comments on draft-ietf-mext-binding-revocation-02 > > > > > > Hi Patrick, > > > Thanks. One slight modification below. > > > > > > Regards, > > > Ahmad > > > > > > > > > > -----Original Message----- > > > > From: Stupar, Patrick [mailto:pstupar@qualcomm.com] > > > > Sent: Friday, January 16, 2009 11:18 AM > > > > To: Muhanna, Ahmad (RICH1:2H10) > > > > Cc: mext@ietf.org > > > > Subject: RE: Comments on draft-ietf-mext-binding-revocation-02 > > > > > > > > > > [Ahmad] > > > > > I see what you are saying. I assumed that this is in the > > > > form of NAI. > > > > > we > > > > > can add some text to clarify that, would that address your > > > > concern or > > > > > you have in mind a possible different format? > > > > > > > > I think this would be good. Either a definition in section > > > > 2.2 or a clarification in the text would be fine with me. > > > > > > [Ahmad] > > > Sure. > > > > > > > > > > > > > > > > [Ahmad] > > > > > Currently, neither the HoA nor the CoA is included in the > > > > BRI message. > > > > > Are you suggesting that we add those options as valid ones > > > > in the BRI? > > > > > > > > No I am not. What I meant here is that HoA is in the > > routing header > > > > of the packet containing the BRI. Checking of HoA would be enough > > > > IMO. It could be moved to the previous bullet of the list > > as in the > > > > following proposed text: > > > > OLD TEXT: > > > > " > > > > o The mobile node MUST verify that the IP address in > > the type 2 > > > > routing header is its Home Address. > > > > > > > > o If the Acknowledgement (A) bit is set in the Binding > > Revocation > > > > Indication and the MN has the BCE in registered state, the > > > > mobile > > > > node MUST send a Binding Revocation Acknowledgement. > > > > However, in > > > > all other cases when the (A) bit is set in the BRI, > > the mobile > > > > node SHOULD send a Binding Revocation > > Acknowledgement. In all > > > > cases, the mobile node MUST follow Section 11.2 when send a > > BRA > > > > using the appropriate status code. > > > > " > > > > NEW TEXT > > > > " > > > > o The mobile node MUST verify that the IP address in > > the type 2 > > > > routing header is its Home Address and that its > > Binding Update > > > > List contains an entry for that Home Address. If one of > > the tests > > > > fails, > > > > the mobile node SHOULD silently discard the received BRI > > > > message. > > > > > > > > o If the Acknowledgement (A) bit is set in the Binding > > Revocation > > > > Indication, the mobile > > > > node MUST send a Binding Revocation Acknowledgement. > > > > However, in > > > > all other cases when the (A) bit is set in the BRI, > > the mobile > > > > node SHOULD send a Binding Revocation > > Acknowledgement. In all > > > > cases, the mobile node MUST follow Section 11.2 when send a > > BRA > > > > using the appropriate status code. > > > > " > > > > > > [Ahmad] > > > I am not sure I follow the second bullet of the "NEW TEXT". > > What about > > > the following modified text: > > > > > > "MODIFIED TEXT" > > > > > > o The mobile node MUST verify that the IP address in the type 2 > > > routing header is its Home Address and that its Binding > Update > > > List contains an entry for that Home Address. If one of > > the tests, > > > fails the mobile node SHOULD silently discard the received BRI > > > message. > > > > > > o If the Acknowledgement (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 (A) bit is set in the BRI, the > mobile > > > node SHOULD send a Binding Revocation Acknowledgement. In > all > > > cases, the mobile node MUST follow Section 11.2 when > > send a BRA > > > using the appropriate status code. > > > > > [Patrick] > > The actions in the first bullet apply to any received BRI > > (also to those with the A bit set). Having said that, in the > > second bullet it is only required to specify the additional > > operation (i.e. sending a BRA) the MN has to perform when the > > A bit is set. IMO the text you added is redundant and not > > required. Do you have some particular scenario I am missing? > > > > > > > > > > > > > > Please note that the proposed text overlaps with the last bullet > > > > listed in section 11.2. I would remove that as in the > > > > following: > > > > > > > > Old text: > > > > "11.2. Sending Binding Revocation Acknowledgement > > > > > > > > When the mobile node receive a valid Binding Revocation > > Indication > > > > with the (A) bit is set from its home agent and while > > having this > > > > BCE > > > > in registered state, the mobile node MUST send a packet to its > > > home > > > > agent containing a Binding Revocation Acknowledgement > according > > to > > > > the procedure in Section 7.1 and the following: > > > > > > > > o The mobile node MUST set the status field to successful to > > > > reflect > > > > that it has received the Binding Revocation Indication and > > > > acknowledge that its IP connectivity with its home > > agent has > > > > been > > > > revoked. > > > > > > > > o The destination IP address of the IPv6 packet of the > Binding > > > > Revocation Acknowledgement is set to the source IP > > address of > > > > the > > > > received IPv6 packet of the Binding Revocation Indication. > > The > > > > Mobile Node MUST include its home address in the > > Home Address > > > > option in the Destination Option. > > > > > > > > o If the mobile node receives a Binding Revocation Indication > > > > from a > > > > home agent which the mobile node does not have a registered > > > > binding with, the mobile node SHOULD silently > > discard the BRI > > > > message. The mobile node should continue to use > > its assigned > > > > HoA > > > > to access its IP mobility service." > > > > > > > > New text: > > > > "11.2. Sending Binding Revocation Acknowledgement > > > > > > > > When the mobile node receive a valid Binding Revocation > > Indication > > > > with the (A) bit is set from its home agent and while > > having this > > > > BCE > > > > in registered state, the mobile node MUST send a packet to its > > > home > > > > agent containing a Binding Revocation Acknowledgement > according > > to > > > > the procedure in Section 7.1 and the following: > > > > > > > > o The mobile node MUST set the status field to successful to > > > > reflect > > > > that it has received the Binding Revocation Indication and > > > > acknowledge that its IP connectivity with its home > > agent has > > > > been > > > > revoked. > > > > > > > > o The destination IP address of the IPv6 packet of the > Binding > > > > Revocation Acknowledgement is set to the source IP > > address of > > > > the > > > > received IPv6 packet of the Binding Revocation Indication. > > The > > > > Mobile Node MUST include its home address in the > > Home Address > > > > option in the Destination Option." > > > > > > [Ahmad] > > > Sure. That is fair and good. > > > > > > Best Regards, > > > Ahmad > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext
- [MEXT] Comments on draft-ietf-mext-binding-revoca… Stupar, Patrick
- Re: [MEXT] Comments on draft-ietf-mext-binding-re… Ahmad Muhanna
- Re: [MEXT] Comments on draft-ietf-mext-binding-re… Stupar, Patrick
- Re: [MEXT] Comments on draft-ietf-mext-binding-re… Ahmad Muhanna
- Re: [MEXT] Comments on draft-ietf-mext-binding-re… Ahmad Muhanna
- Re: [MEXT] Comments on draft-ietf-mext-binding-re… Stupar, Patrick
- Re: [MEXT] Comments on draft-ietf-mext-binding-re… Ahmad Muhanna
- Re: [MEXT] Comments on draft-ietf-mext-binding-re… Stupar, Patrick
- Re: [MEXT] Comments on draft-ietf-mext-binding-re… Ahmad Muhanna
- Re: [MEXT] Comments on draft-ietf-mext-binding-re… Stupar, Patrick