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

[Basavaraj Patil <[e-mail]>]

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


On Thu, May 16, 2013 at 11:29 PM, Suresh Krishnan <
[e-mail]> wrote:

>  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 <[e-mail]>
> To: "[e-mail]" <[e-mail]>
> 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:
> ---------
>
>  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
>



-- 
Basavaraj Patil