Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-02

"Ahmad Muhanna" <amuhanna@nortel.com> Fri, 16 January 2009 18:52 UTC

Return-Path: <mext-bounces@ietf.org>
X-Original-To: mip6-archive@megatron.ietf.org
Delivered-To: ietfarch-mip6-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27A1B3A6A2D; Fri, 16 Jan 2009 10:52:21 -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 84B633A6A2D for <mext@core3.amsl.com>; Fri, 16 Jan 2009 10:52:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.433
X-Spam-Level:
X-Spam-Status: No, score=-6.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 ekbEZHexrQYs for <mext@core3.amsl.com>; Fri, 16 Jan 2009 10:52:18 -0800 (PST)
Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 4BDE83A6906 for <mext@ietf.org>; Fri, 16 Jan 2009 10:52:18 -0800 (PST)
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n0GIpwd26236; Fri, 16 Jan 2009 18:51:58 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 16 Jan 2009 12:50:50 -0600
Message-ID: <C5A96676FCD00745B64AE42D5FCC9B6E1CA46D5F@zrc2hxm0.corp.nortel.com>
In-Reply-To: <A39C75E50DED4C43A4B0EA9B51B0B6B34DE379@EUEX02.eu.qualcomm.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Comments on draft-ietf-mext-binding-revocation-02
Thread-Index: AclbLn3taqHuU6TUSgeN3dxQhl2ykQArrD7gALKdDZAEWRBysAGXgEdQAGd43wA=
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>
From: Ahmad Muhanna <amuhanna@nortel.com>
To: "Stupar, Patrick" <pstupar@qualcomm.com>
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 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.

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