Re: [netext] Fwd: AD Evaluation : draft-ietf-netext-update-notifications

All,
      I just want to notify the WG of a slight change in the processing 
of this document.  Normally, as the document goes through IESG review 
and discussion, the document authors, WG chairs, and draft shepherd are 
copied on all correspondence.  For this draft, we will be experimenting 
with also having the WG mailing list copied on the discussion.

      The goal is to have as much transparency as possible into the 
review and publication process.  Having the WG mailing list copied will 
allow everyone to see (and comment on) feedback from directorate and AD 
reviews.  Once the publication process is complete, I would invite you 
to send me any and all feedback you might have on this change.

Regards,
Brian

On 7/24/13 2:20 PM, Brian Haberman wrote:
>
>
>
> -------- Original Message --------
> Subject: AD Evaluation : draft-ietf-netext-update-notifications
> Date: Wed, 24 Jul 2013 14:16:26 -0400
> From: Brian Haberman <brian@innovationslab.net>
> To: netext-chairs@tools.ietf.org <netext-chairs@tools.ietf.org>,
> draft-ietf-netext-update-notifications@tools.ietf.org
>
> All,
>       I have performed my AD evaluation of
> draft-ietf-netext-update-notifications as a part of the RFC publication
> process.  Thank you for a well-written document.  The following
> comments/questions need to be addressed prior to issuing an IETF Last
> Call for the draft.  Please let me know if there is any clarification I
> can provide on these comments.
>
> * Introduction
>
> - The 2nd sentence in the 2nd paragraph is clunky.  I finally figured
> out that what it is trying to say is that the MAG proxies all MIPv6
> signaling on behalf of the mobile node and the LMA acts as a MIPv6 home
> agent.  I would suggest re-writing the sentence to be clearer for those
> readers who are not experts in the mobility protocols.
>
> - The last sentence of the 2nd paragraph should say that PMIPv6 does not
> *currently* have an LMA-to-MAG signaling mechanism.
>
> - The first sentence in the 3rd paragraph is missing an article.  I
> believe it should be "... re-register the mobility session..."
>
> - The last sentence in the 3rd paragraph that discusses the use of
> existing headers is confusing.  It starts off by saying it is possible
> to use existing headers for this signaling and ends by saying they can't
> be used.
>
> * Section 4
>
> - Is there any guidance needed on managing the wrapping of the Sequence
> #'s?
>
> - Is it worth mentioning the Pad1 and PadN options given the alignment
> requirements?
>
> - Are there informative references that could be added for mobility
> options other than the vendor-specific ones?
>
> * Section 5
>
> - The last bullet is extraneous since it simply points to the very next
> sub-section.
>
> - Can you provide an example of where an LMA would not request an ACK
> for a UPN?
>
> - I assume that the sequence numbers used in these messages are the same
> sequence numbers used for other PMIPv6/MIPv6 messages.  It might be
> worthwhile to mention that, if it is true.
>
> * Section 5.2
>
> - I am surprised by the use of SHOULD (SHOULD NOT) for re-transmission
> rules.  When would you expect these rules to be ignored?
>
> * Section 6.1
>
> - The 2nd bullet is useless.  If an implementation does not support
> these messages, they wouldn't know to look here for responses.  The base
> PMIPv6 spec covers the response message for unknown message types.
>
> - Should there be any validation performed on the sequence number?
>
> * IANA
>
> - I would like to see some more guidance given to IANA on where the new
> registries should be placed in their protocol hierarchy.
>
> Regards,
> Brian
>
>
> _______________________________________________
> netext mailing list
> netext@ietf.org
> https://www.ietf.org/mailman/listinfo/netext