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

From: Basavaraj Patil <[email-masked]>
Date: Wed, 8 May 2013 16:50:13 -0500

My review of this I-D.

-Raj

Comments:
---------

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.

Editorial:

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.

Comment:

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
   MAG.

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

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 17 May 2013 04:29:03 +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.

Thanks
Suresh

----- Original Message -----
From: Basavaraj Patil <[email-masked]>
To: "[email-masked]" <[email-masked]>
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.

-Raj

Comments:
---------

Editorial:

Comment:

s/The base Proxy

Q: ID states:

--
Basavaraj Patil

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 17 May 2013 11:44:17 -0500

Hi Suresh,

I just wanted to make sure that we are requiring IANA registration for all
reasons that get specified subsequently. Since that is required and clearly
mentioned in the IANA considerations section of the I-D I am fine with it.

Will go ahead and submit a WG LC request.

-Raj

-- 
Basavaraj Patil