Re: [netext] Review of I-D: draft-ietf-netext-update-notifications-03

Suresh Krishnan <> Fri, 17 May 2013 04:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 233D221F8A6B for <>; Thu, 16 May 2013 21:29:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0yjfym-mY865 for <>; Thu, 16 May 2013 21:29:05 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BFB2721F89FD for <>; Thu, 16 May 2013 21:29:05 -0700 (PDT)
X-AuditID: c6180641-b7f7b6d000001a44-cc-5195b21057a1
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id DA.93.06724.012B5915; Fri, 17 May 2013 06:29:04 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Fri, 17 May 2013 00:29:04 -0400
From: Suresh Krishnan <>
To: Basavaraj Patil <>
Thread-Topic: [netext] Review of I-D: draft-ietf-netext-update-notifications-03
Thread-Index: AQHOTDYVRUI6Mx8dXEmv1CB+aWXd+5kI1bMG
Date: Fri, 17 May 2013 04:29:03 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/alternative; boundary="_000_lgaqln5hv9ey0vyp4c48dvjx1368764941954emailandroidcom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUyuXSPn67ApqmBBpNPW1nM2T6BxeLaz6fs DkweO2fdZfdYsuQnUwBTFJdNSmpOZllqkb5dAlfG2sPrmQoOWFY8XjKJvYHxgn4XIyeHhICJ xLbbzSwQtpjEhXvr2boYuTiEBI4yStx78okdwlnOKLG44xUrSBUbUMeGnZ+ZQGwRAXWJIzv2 s4PYzED2rflnwSYJCwRIHHp8lxGiJlBi54rpLBC2kcSTqdPA6lkEVCWmzzzJDGLzCrhJ7N61 BqxGCKj35rULQL0cHJxAvVdbpEDCjEDHfT+1hglilbjErSfzmSCOFpBYsuc8M4QtKvHy8T9W iJociYenD7JDjBeUODnzCcsERpFZSNpnISmbhaQMIq4ncWPqFDYIW1ti2cLXzBC2rsSMf4dY kMUXMLKvYuQoLU4ty003MtzECIyeYxJsjjsYF3yyPMQozcGiJM7brT01UEggPbEkNTs1tSC1 KL6oNCe1+BAjEwenVAOjrdv0Zxrlx1zY7OdvSghfcebWhYl3ej4f5Dq94KOGzin2QFEFEft/ L2OPtM7n25Kz+/b22FVft5osln726eGkRQEKZ1tiXf5E9JySe62UabTWyWHK6edreLy2fksM cFCRdd75wfhleEJ51j7OnV9c+rT/a1xKuaQiM8Hq/OFXHXq1vIJst6ZGKLEUZyQaajEXFScC AEkg85ZsAgAA
Cc: "" <>
Subject: Re: [netext] Review of I-D: draft-ietf-netext-update-notifications-03
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 17 May 2013 04:29:12 -0000

Hi Raj,
Thanks for your detailed review. We have submitted a new version of the draft to address your comments. Specifically we have added a new configuration value for limiting the number of retransmissions and fixed all the editorial issues.

I did not understand the issue about the vendor specific reason. We require IANA registration of all reasons with the policy "specification required". Did you want us to change this? Once we agree on a resolution to this issue, the draft will be ready for WGLC.


----- Original Message -----
From: Basavaraj Patil <>
To: "" <>
Sent: 5/8/2013 5:50 PM
Subject: [netext] Review of I-D: draft-ietf-netext-update-notifications-03

My review of this I-D.



In order to ensure interoperability, the I-D should state that if an
LMA sends an Update notification to a MAG and does not receive an Ack,
then the MAG may not support the ability to update sessions.
The I-D should specify a backoff mechanism in terms of retransmitting
an update message from the LMA and stop after X number of messages
with no response.

The update notification message could be abused by the introduction of
a vendor specific notification reason. The specification should
mandate the registration of all notification reasons in IANA and not
allow any vendor specific types.


s/ These update notifications are exchanged using a Mobility
   Header message type specifically designed for this purpose./These
   update notifications are exchanged using a new Mobility
   Header message type specifically designed for this purpose.


The Introduction starts off as : "In some situations, there is a need
for the local mobility anchor ..."
This is pretty ambiguous. Please rephrase.

s/The base Proxy
   Mobile IPv6 specification does not have a provision for this./ The
   base Proxy Mobile IPv6 specification does not have a provision for
   sending unsolicited informational messages from the LMA to the

s/participation from the mobile node/participation by the mobile node

s/for the mobile node in Mobile IPv6 [RFC6275]/for the mobile node as
specified in Mobile IPv6 [RFC6275]

Q: ID states:
"One such scenario where such a mechanism is needed is when the local
   mobility anchor wants to inform the mobile access gateway that it
   needs to re-register mobility session for a mobile node."

In what scenario would the LMA want to inform the MAG that an MN needs
to be re-registered?

s/and so it can obtain the updated policy/in order to update the
policies associated with the mobility session of an MN.

s/or and updated IPv4/or an updated IPv4

Basavaraj Patil