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