Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-02
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-02
Hi Patrick,
Thanks. One slight modification below.
Regards,
Ahmad
> -----Original Message-----
> From: Stupar, Patrick [mailto:pstupar at qualcomm.com]
> Sent: Friday, January 16, 2009 11:18 AM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: mext at 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 thFrom mext-bounces at ietf.org Fri Jan 16 10:52:21 2009
Return-Path: <mext-bounces at ietf.org>
X-Original-To: mip6-archive at megatron.ietf.org
Delivered-To: ietfarch-mip6-archive at 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 at core3.amsl.com
Delivered-To: mext at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 84B633A6A2D
for <mext at 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 at 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 at 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 at zrc2hxm0.corp.nortel.com>
In-Reply-To: <A39C75E50DED4C43A4B0EA9B51B0B6B34DE379 at 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 at EUEX02.eu.qualcomm.com>
<C5A96676FCD00745B64AE42D5FCC9B6E1C2CF213 at zrc2hxm0.corp.nortel.com>
<A39C75E50DED4C43A4B0EA9B51B0B6B3404AC6 at EUEX02.eu.qualcomm.com>
<C5A96676FCD00745B64AE42D5FCC9B6E1C7307B3 at zrc2hxm0.corp.nortel.com>
<A39C75E50DED4C43A4B0EA9B51B0B6B34DE379 at EUEX02.eu.qualcomm.com>
From: "Ahmad Muhanna" <amuhanna at nortel.com>
To: "Stupar, Patrick" <pstupar at qualcomm.com>
Cc: mext at ietf.org
Subject: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-02
X-BeenThere: mext at 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 at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/mext>
List-Post: <mailto:mext at ietf.org>
List-Help: <mailto:mext-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>,
<mailto:mext-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mext-bounces at ietf.org
Errors-To: mext-bounces at ietf.org
Hi Patrick,
Thanks. One slight modification below.
Regards,
Ahmad
> -----Original Message-----
> From: Stupar, Patrick [mailto:pstupar at qualcomm.com]
> Sent: Friday, January 16, 2009 11:18 AM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: mext at 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 followe 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 packeing 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 itst 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 at ietf.org
https://www.ietf.org/mailman/listinfo/mext
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 at ietf.org
https://www.ietf.org/mailman/listinfo/mext
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
