Update Notifications for Proxy Mobile IPv6
draft-ietf-netext-update-notifications-12

[Ballot comment]
Robert Sparks raised a clarity issue in the document in his Gen-ART review, and there has been discussion with the authors to correct the issue, and the correction has made it to a private version of the draft. I wish that version would be published so that we could deal with as clean document as possible, free of issues that have already been resolved.

(If you had no other issues to resolve, I'd probably raise this as a discuss, because I'd want to avoid accidentally approving the document without the changes making it to the last version.)

[Ballot comment]
For the record, here is Carlos Pignataro's feedback, part of OPS-DIR. It's been worked on by Suresh

Minor comment:

This document specifies two configurable variables in Section 7. It clearly specifies that these variables need to survive reboots, and also specifies what it seems to be sensible defaults. However, it does not specify ranges or considerations for these two values. I'd suggest adding some more details about ranges.

The MAX_UPDATE_NOTIFICATION_RETRANSMIT_COUNT default says it can be retransmitted once. The MIN_DELAY_BETWEEN_UPDATE_NOTIFICATION_REPLAY default is the minimum value, which means that retransmission delay cannot be less than a second. I expect this is OK, but would ask whether it makes sense to have the variable in milliseconds and the default as 1,000. The answer can perfectly be "no, does not make sense".

Also, a small nit in two IANA actions:

  o  Action-3: This specification defines a new registry for
      Notification Reasons.  Its called, "Update Notification Reasons
      Registry".  This registry should be created under "Mobile IPv6
      Parameters" registry at (https://www.iana.org/assignments/
      mobility-parameters/mobility-parameters.xhtml).  The Notification

  o  Action-4: This specification defines a new registry for Status.
      Its called, "Update Notification Acknowledgement Status Registry".
      This registry should be created under "Mobile IPv6 Parameters"
      registry at (https://www.iana.org/assignments/mobility-parameters/
      mobility-parameters.xhtml).  The status is a field in the Update

The URL should not point to the .xhtml pages, they should point to the extension-less URLs.

A question:

If the Status Codes are partitioned as 0-127 as success and 128-255 as error, why the error allocations start at 129?

      0 -  Success
      129 -  FAILED-TO-UPDATE-SESSION-PARAMETERS
      130 -  MISSING-VENDOR-SPECIFIC-OPTION
 
Should 128 be assigned?

Another protocol problem:

  o  If the local mobility anchor receives an Update Notification
      Acknowledgement message with a failure Status and the value of
      larger than 128, then it SHOULD log an error.

Why the status "larger" than 128 and not "larger than or equal to" 128? This needs to be fixed (> 127 or >= 128)

Hope these are clear and useful!

Carlos.

[Ballot discuss]
Simple to resolve, and the authors are already aware of this: as raised in the IANA review, the IANA Considerations section uses the correct URI for the IANA registry in actions 1 and 2:

  http://www.iana.org/assignments/mobility-parameters

...but does not use the correct one for actions 3 and 4:

  https://www.iana.org/assignments/mobility-parameters/mobility-parameters.xhtml

Please change the URIs in actions 3 and 4 to match the ones in actions 1 and 2 (it doesn't matter whether they use http: or https:, but please make all four the same).

[Ballot discuss]

5.2: What happens if the IPsec SA is re-negotiated
automatically? Isn't there a potential layering/sync problem
so that these notifications couldn't ever be verified since a
new SA would be in use? I think you just need to say the same
or an automatically renegotiated SA (not sure what's the
right terminology, sorry). I think 6.1 has the same issue and
maybe other bits too. That kind of check also seems to
imply that the interface between the MAG or LMA and the
IPsec code needs to know that the right SA is being used
which could be tricky. What's really done here?

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-netext-update-notifications-07.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document four IANA actions are required to be completed.

First, in the Mobility Header Types - for the MH Type field in the Mobility Header registry located at:

http://www.iana.org/assignments/mobility-parameters

a new Mobility Header Type is to be registered as follows:

Value: [ TBD-at-registration ]
Description: Update Notification
Reference: [ RFC-to-be ]

Second, also in the Mobility Header Types - for the MH Type field in the Mobility Header registry located at:

http://www.iana.org/assignments/mobility-parameters

a new Mobility Header Type is to be registered as follows:

Value: [ TBD-at-registration ]
Description: Update Notification Acknowledgement
Reference: [ RFC-to-be ]

Third, a new registry is to be created called the "Update Notification Reasons Registry". This registry will be created under "Mobile IPv6 Parameters" registry located at https://www.iana.org/assignments/mobility-parameters). The registry is managed through "Specification Required" as defined by RFC 5226.

There are initial values in this registry as follows:

Code Reason Reference
------+--------------------------------+---------------------
0 Reserved [ RFC-to-be ]
1 FORCE-REREGISTRATION [ RFC-to-be ]
2 UPDATE-SESSION-PARAMETERS    [ RFC-to-be ]
3 VENDOR-SPECIFIC-REASON [ RFC-to-be ]

Fourth, a new registry will be created called the "Update Notification Acknowledgement Status Registry". This registry will be created under "Mobile IPv6 Parameters" registry located at

https://www.iana.org/assignments/mobility-parameters

The registry is managed through "Specification Required" as defined by RFC 5226.

The status codes between 0 and 127 signify successful processing of the Update Notification message and codes between 128 and 255 signify that an error occurred during processing of the Update Notification message.

There are initial values in this new registry as follows:

Code Status Reference
------+-------------------------------------+--------------------
0 Success [ RFC-to-be ]
129 FAILED-TO-UPDATE-SESSION-PARAMETERS [ RFC-to-be ]
130 MISSING-VENDOR-SPECIFIC-OPTION [ RFC-to-be ]

NOTE: Please remove the second /mobility-parameters.xhtml from the URL
in the IANA Considerations section:

FROM:
(https://www.iana.org/assignments/
      mobility-parameters/mobility-parameters.xhtml).

TO:
https://www.iana.org/assignments/mobility-parameters

This will ensure the URL will always work and point to the most current
version/extension.

IANA understands that these four actions are the only ones that need to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Update Notifications for Proxy Mobile IPv6) to Proposed Standard


The IESG has received a request from the Network-Based Mobility
Extensions WG (netext) to consider the following document:
- 'Update Notifications for Proxy Mobile IPv6'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-08-29. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document specifies protocol enhancements for allowing the local
  mobility anchor in a Proxy Mobile IPv6 domain to asynchronously
  notify the mobile access gateway about changes related to a mobility
  session.  These update notification messages are exchanged using a
  new Mobility Header message type specifically designed for this
  purpose.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-netext-update-notifications/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-netext-update-notifications/ballot/


No IPR declarations have been submitted directly on this I-D.

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

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

Proposed Standard


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

This document specifies protocol enhancements for allowing the local
mobility anchor in a Proxy Mobile IPv6 domain to asynchronously
notify the mobile access gateway about changes related to a mobility
session. These update notification messages are exchanged using a
new Mobility Header message type specifically designed for this
purpose.

Working Group Summary:

The extension to Proxy Mobile IPv6 was viewed as essential to the
protocol and hence was adopted by the working group and progressed
with no issues.

Document Quality:

The document has been reviewed by multiple experts within the working
group and has been updated based on the feedback received. The quality
of the document itself is good and ready for IESG review. All
reviewers have been acknowledged in the I-D. The extension is relevant
and has been requested by 3GPP as an enhancement to the
protocol. Multiple vendors are likely to implement this extension to
Proxy Mobile IPv6.

Are there existing
Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Document Shepherd: Basavaraj Patil
Responsible AD: Brian Haberman


(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

I have reviewed the I-D multiple times during the course of the work
being progressed in the working group. The authors have been receptive
to the suggestions and have updated the draft accordingly. At this
time I am satisfied with the quality of the I-D and believe that it is
ready for IESG review.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No. The I-D has been reviewed sufficiently.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No. The I-D proposes an extension to the base protocol (Proxy Mobile
IPv6) and hence does not need any additional review from experts in
other areas.

(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

The WG does not have any concerns with this I-D. No major issues or
concerns have been raised that would need to be flagged here.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed. If not, explain why?

Each author has confirmed that they are in line with the provisions of
BCP 78, 79.


(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosures have been filed w.r.t this I-D.


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

There is broad WG consensus on the need for this extension to Proxy
Mobile IPv6. I believe most of the active WG participants understand
the need for this extension and are supportive of it.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

I have checked the I-D for nits with the following result:

"
Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment
(--).
"


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

The I-D does not specify any MIB, media type or URI types.

(13) Have all references within this document been identified as
either normative or informative?

Yes. The I-D splits the references into normative and informative
sections.


(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?

No normative references exist which are pending advancement.

(15) Are there downward normative references references (see RFC
3967)? If so, list these downward references to support the Area
Director in the Last Call procedure.

No.


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

Status of existing Proxy Mobile IPv6 RFCs will not be affected. This
is an extension to the base protocol and hence there is no impact
caused to the base protocol itself.


(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226).

The IANA considerations section is complete and includes all the
information that would be required by IANA.
A new registry is required. And the details for this are specified in
the IANA considerations section.


(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

A new IANA registry called : "Update Notification Reasons Registry" is
required. Experts who can assist IANA for these registries include the
current working group chairs (Basavaraj Patil/Rajeev Koodli) as well
as other active participants in this WG such as: Charles Perkins, Kent
Leung, Pete McCann.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

Not required for this I-D.