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

"Ahmad Muhanna" <amuhanna@nortel.com> Mon, 19 January 2009 23:23 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 24D503A6A45; Mon, 19 Jan 2009 15:23:49 -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 93F243A6A4F for <mext@core3.amsl.com>; Mon, 19 Jan 2009 15:23:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.464
X-Spam-Level:
X-Spam-Status: No, score=-6.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 nkBAzsHOOFU9 for <mext@core3.amsl.com>; Mon, 19 Jan 2009 15:23:47 -0800 (PST)
Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 3738E3A6A16 for <mext@ietf.org>; Mon, 19 Jan 2009 15:23:46 -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 n0JNNQZ07142; Mon, 19 Jan 2009 23:23:26 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 19 Jan 2009 17:23:21 -0600
Message-ID: <C5A96676FCD00745B64AE42D5FCC9B6E1CAF5FAF@zrc2hxm0.corp.nortel.com>
In-Reply-To: <A39C75E50DED4C43A4B0EA9B51B0B6B34DE500@EUEX02.eu.qualcomm.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Comments on draft-ietf-mext-binding-revocation-02
Thread-Index: AclbLn3taqHuU6TUSgeN3dxQhl2ykQArrD7gALKdDZAEWRBysAGXgEdQAGd43wAAl3PFsAADWf9w
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>
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,

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.  


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