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

From: Brian Haberman <[email-masked]>
Date: Wed, 24 Jul 2013 14:20:59 -0400

-------- Original Message --------
Subject: AD Evaluation : draft-ietf-netext-update-notifications
Date: Wed, 24 Jul 2013 14:16:26 -0400
From: Brian Haberman <[email-masked]>
To: [email-masked] <[email-masked]>, 
[email-masked]

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

---

From: Brian Haberman <[email-masked]>
Date: Thu, 25 Jul 2013 10:04:26 -0400

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:
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Sat, 27 Jul 2013 23:09:44 +0000

Hi Brian,

Thanks for the review comments. Please see inline.

>readers who are not experts in the mobility protocols.

OK. Will reword that sentence/paragraph.

>*currently* have an LMA-to-MAG signaling mechanism.

Sure.

>believe it should be "... re-register the mobility session..."

Ok. Sure

>to use existing headers for this signaling and ends by saying they can't

Will reword it.

>- Is there any guidance needed on managing the wrapping of the Sequence

We just require some random number, without collusions. We can add some
text to say how to manage that field.

>- Is it worth mentioning the Pad1 and PadN options given the alignment

That was implied with all options. But, its probably good to include some
text.

>options other than the vendor-specific ones?

Potentially some some new work items that we can point to. If there are
Active I-D's will add a reference.

>- The last bullet is extraneous since it simply points to the very next

Agree. Will remove it

>- Can you provide an example of where an LMA would not request an ACK

Message String extension. LMA sending some status messages related to the
service its offering. These service message may not need Ack's.

Also, a UPN message with NR=RE-register may not need a Ack messages. The
LMA after sending the UPN message with that NR code can wait the PBU
message.

>worthwhile to mention that, if it is true.

This is a good point. We did not say one way, or the other. Will clarify
it.

>rules.  When would you expect these rules to be ignored?

Ok. Will review this again.

>PMIPv6 spec covers the response message for unknown message types.

This is about LMA sending a UPN message to a MAG that does not support and
how to deal with that scenario.
If the response to a UPN message is a Binding Error message, then the LMA
can be forced not to send any more UPN messages.

>- Should there be any validation performed on the sequence number?

Exact considerations from 6275 apply here. Its just for matching the
request to the response. Will review the text related to this field.

>registries should be placed in their protocol hierarchy.

Ok. Will review this

---

From: Brian Haberman <[email-masked]>
Date: Mon, 29 Jul 2013 03:43:47 -0400

Hi Sri,
      I have deleted those points where there is no additional 
discussion needed...

> text to say how to manage that field.

Ok.  Just ensure that the descriptive text does not impact the Sequence 
# usage defined in the base PMIPv6 spec.

> Active I-D's will add a reference.

That would be useful.  Just make sure they are informative references so 
that this spec does not get held up on a reference to an I-D.

> LMA after sending the UPN message with that NR code can wait the PBU

So, is it worth mentioning these in the draft?  It seems that the LMA is 
in full control of whether an ACK is needed, but it *could* be useful to 
describe the *types* of options that do not need an ACK.

I am not insisting on this.  Just trying to see if such an addition 
would make the spec easier to understand/implement.

> Ok. Will review this again.

If the SHOULDs are appropriate, it would be good to describe a scenario 
(or type of scenaro) where the SHOULD would be ignored.

> can be forced not to send any more UPN messages.

Given that section 6.1 talks about MAG considerations, it seemed odd to 
describe how the MAG is supposed to respond if it doesn't support this 
function.

Regards,
Brian

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 29 Jul 2013 08:19:17 +0000

Hi Brian,

Please see inline.

># usage defined in the base PMIPv6 spec.

Ok

>that this spec does not get held up on a reference to an I-D.

Ok

>describe the *types* of options that do not need an ACK.

IMO, this may not be needed, unless the protocol definition is incorrect.
But, we can add a statement or two explaining as when the LMA may choose
not to set the flag..in general terms.

>(or type of scenaro) where the SHOULD would be ignored.

Ok

>describe how the MAG is supposed to respond if it doesn't support this

Let me check on this. Will fix it.

Will post the updated document this week.

Regards
Sri