Re: [netext] Review of I-D: draft-ietf-netext-redirect-10

Hi Jouni,

Just one issue that still bothers me:

>> 4. In Section 4, it would be useful to explain (in brief) what is the
>>   functionality of a specific option. For example the
>>   'Redirect-Capability Mobility Option': The text has no explanation
>>   what this option is supposed to do in a message. You could add at
>>   least one sentence saying that it is used to indicate the redirect
>>   capability supported by the MAG, LMA entitied.

>I see your point. However, these texts were removed by discuss comments in IESG.

I disagree. I think that text explaining the decription of the option is useful and helps readability.
If you see Secs 6.2.4, .5 etc in RFC3775 as an example, these are also options for MIP6 and they
do provide a brief explanation. Having such text IMO would be useful in this I-D.

Thx.
-Raj

________________________________________
From: ext jouni korhonen [jouni.nospam@gmail.com]
Sent: Monday, September 12, 2011 6:10 AM
To: Patil Basavaraj (Nokia-CIC/Dallas)
Cc: netext@ietf.org; draft-ietf-netext-redirect@tools.ietf.org
Subject: Re: [netext] Review of I-D: draft-ietf-netext-redirect-10

Raj,

Thanks for the review. See my comments inline.

On Sep 10, 2011, at 1:24 AM, <Basavaraj.Patil@nokia.com> <Basavaraj.Patil@nokia.com> wrote:

>
> My WGLC review comments on Rev 10 of the I-D: draft-ietf-netext-redirect
>
> 1. Abstract can be improved. Rather than just mentioning the scope you
>   could describe briefly the feature specified in this I-D.

   This document describes a runtime Local Mobility Anchor assignment
   functionality and corresponding mobility options for Proxy Mobile
   IPv6. The runtime Local Mobility Anchor assignment takes place during
   a Proxy Binding Update and a Proxy Binding Acknowledgement message
   exchange between a Mobile Access Gateway and a Local Mobility Anchor.
   The runtime Local Mobility Anchor assignment functionality defined in
   this specification can be used, for example, for load balancing purposes.

> 2. Would be useful to describe in the introduction how runtime LMA
>   assignment is different from the normal mode as specified in
>   RFC5213 (which you do in Sec 5.2 1st paragraph)

Hmm.. I think there is no reason to repeat that technical stuff in Introduction.

> 3. s/assumed to have required Security Associations (SA)already set up
>   in advance./assumed to have the required Security Associations (SA)
>   pre-established.

Ack.

> 4. In Section 4, it would be useful to explain (in brief) what is the
>   functionality of a specific option. For example the
>   'Redirect-Capability Mobility Option': The text has no explanation
>   what this option is supposed to do in a message. You could add at
>   least one sentence saying that it is used to indicate the redirect
>   capability supported by the MAG, LMA entitied.

I see your point. However, these texts were removed by discuss comments in IESG.

> 5. Missing the direction of the signaling flow message no 1 in fig 1.

Ack.

> 6. s/There is no need to resend a PBU to the r2LMA after a successful
>   runtime assignment./The MAG is not required to send a fresh PBU to
>   the r2LMA after a successful runtime assignment.

Ack.

> 7. s/The MAG MUST send subsequent binding refreshing PBUs and user
>   traffic to the new r2LMA address./
>   The MAG MUST send all user traffic to the r2LMA address. The MAG MUST
>   send subsequent binding refresh PBUs to the r2LMA address.

Ack.

And thanks,
        Jouni

>
> -Raj
>
> _______________________________________________
> netext mailing list
> netext@ietf.org
> https://www.ietf.org/mailman/listinfo/netext