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

"Stupar, Patrick" <pstupar@qualcomm.com> Mon, 19 January 2009 19:01 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 0CC8028C178; Mon, 19 Jan 2009 11:01:23 -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 D701D28C113 for <mext@core3.amsl.com>; Mon, 19 Jan 2009 11:01:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.266
X-Spam-Level:
X-Spam-Status: No, score=-105.266 tagged_above=-999 required=5 tests=[AWL=1.333, 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 GG3lkaUCsqX2 for <mext@core3.amsl.com>; Mon, 19 Jan 2009 11:01:20 -0800 (PST)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 633F928C157 for <mext@ietf.org>; Mon, 19 Jan 2009 11:01:20 -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=1232391664; x=1263927664; 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:=20Mon,=2019=20Jan=202009 =2018:59:40=20-0000|Message-ID:=20<A39C75E50DED4C43A4B0EA 9B51B0B6B34DE500@EUEX02.eu.qualcomm.com>|In-Reply-To:=20< C5A96676FCD00745B64AE42D5FCC9B6E1CA46D5F@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 ykQArrD7gALKdDZAEWRBysAGXgEdQAGd43wAAl3PFsA=3D=3D |References:=20<A39C75E50DED4C43A4B0EA9B51B0B6B340478F@EU EX02.eu.qualcomm.com>=20<C5A96676FCD00745B64AE42D5FCC9B6E 1C2CF213@zrc2hxm0.corp.nortel.com>=20<A39C75E50DED4C43A4B 0EA9B51B0B6B3404AC6@EUEX02.eu.qualcomm.com>=20<C5A96676FC D00745B64AE42D5FCC9B6E1C7307B3@zrc2hxm0.corp.nortel.com> =20<A39C75E50DED4C43A4B0EA9B51B0B6B34DE379@EUEX02.eu.qual comm.com>=20<C5A96676FCD00745B64AE42D5FCC9B6E1CA46D5F@zrc 2hxm0.corp.nortel.com>|From:=20"Stupar,=20Patrick"=20<pst upar@qualcomm.com>|To:=20"Ahmad=20Muhanna"=20<amuhanna@no rtel.com>|Cc:=20<mext@ietf.org>|X-OriginalArrivalTime:=20 19=20Jan=202009=2019:01:00.0725=20(UTC)=20FILETIME=3D[44D C5E50:01C97A68]|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2 777,5500"=3B=20a=3D"14777523"; bh=Eq/Jzeg2lETRZmDmvHbWJrboKdGbWVP7tu1jO5OLxIE=; b=bSJKpPwTAKqm7BYJD7hVfT7pVxi8v+ehVwWCJ4RhEpKwGWZRNscQog4c suU+bJ4bV90ZuMotFV3BbuNsIO4EUkhaWt1Ir9bpXhMH+HFF/GHLfZiYP Xa7wNRs+ZIfAf5mRh9ngYFRADp05cWJDvFWaJFDW4qqSAR+3UfTzW7B59 M=;
X-IronPort-AV: E=McAfee;i="5300,2777,5500"; a="14777523"
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; 19 Jan 2009 11:01:04 -0800
Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n0JJ14Sj016527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 19 Jan 2009 11:01:04 -0800
Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n0JJ12Wv021114; Mon, 19 Jan 2009 11:01:03 -0800
Received: from EUEX02.eu.qualcomm.com ([10.222.228.33]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jan 2009 11:01:00 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 19 Jan 2009 18:59:40 -0000
Message-ID: <A39C75E50DED4C43A4B0EA9B51B0B6B34DE500@EUEX02.eu.qualcomm.com>
In-Reply-To: <C5A96676FCD00745B64AE42D5FCC9B6E1CA46D5F@zrc2hxm0.corp.nortel.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Comments on draft-ietf-mext-binding-revocation-02
Thread-Index: AclbLn3taqHuU6TUSgeN3dxQhl2ykQArrD7gALKdDZAEWRBysAGXgEdQAGd43wAAl3PFsA==
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>
From: "Stupar, Patrick" <pstupar@qualcomm.com>
To: Ahmad Muhanna <amuhanna@nortel.com>
X-OriginalArrivalTime: 19 Jan 2009 19:01:00.0725 (UTC) FILETIME=[44DC5E50:01C97A68]
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,

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