Support for Adjustable Maximum Router Lifetimes per Link
draft-ietf-6man-maxra-04

[Ballot comment]
Everyone likely knows this, but is it worth adding a suggestion to retry rejected RAs with a Router Lifetime of more than 9000 seconds, with a new RA that uses 9000 seconds?

5.  Host Behavior

  Legacy hosts on a link with updated routers may have issues with a
  Router Lifetime of more than 9000 seconds.  In the few
  implementations we have tested with general purpose operating
  systems, there does not seem to be any issues with setting this field
  to more than 9000, but there might be implementations that
  incorrectly (since RFC4861 requires receivers to handle any value)
  reject such RAs.

I think this meshes with Mirja's suggestion to state whether 9000 is still the default ...

[Ballot comment]
Thanks for addressing my discuss and comment. I find the formulation in the document being updated problematic, but you've done a deft job of not repeating the error in this document.

[Ballot comment]
[Based on a conversation with the sponsoring AD regarding the nature of the text in the next version of the document, I'm moving my previous DISCUSS text into a comment and trusting him to take care of the ambiguity prior to publication.]

Lacking a formal definition of "between," the following normative statement is ambiguous: "AdvDefaultLifetime MUST either be zero (the router is not to be used as a default router) or be a value between MaxRtrAdvInterval and 65535." Normative statements cannot be ambiguous. Please clarify whether this is an inclusive "between" or an exclusive "between."

Section 4 contains:

  As explained in Section 3, the relationship between MaxRtrAdvInterval
  and AdvDefaultLifetime must be chosen to take into account the
  probability of packet loss.

The use of a non-normative "must" here indicates that you probably want to update your RFC2119 boilerplate to be RFC8174 boilerplate.

[Ballot comment]
Editorial Comments:

- Abstract: Please mention the fact this updates 4861 in the abstract.

- Given that there are at least a few "should" and "must" instances in lower case, please consider using the boilerplate from 8174 rather than 2119.

[Ballot discuss]
Lacking a formal definition of "between," the following normative statement is ambiguous: "AdvDefaultLifetime MUST either be zero (the router is not to be used as a default router) or be a value between MaxRtrAdvInterval and 65535."

Normative statements cannot be ambiguous.

Please clarify whether this is an inclusive "between" or an exclusive "between."

[Ballot discuss]
I'm concerned that this normative statement is ambiguous (2nd paragraph of section 4), and that the ambiguity around allowed values may lead to interop issues:

  AdvDefaultLifetime
  MUST either be zero (the router is not to be used as a default
  router) or be a value between MaxRtrAdvInterval and 65535.

From the text in section 3, I infer that MaxRtrAdvInterval is *not* an allowed value.

From the "no greater than 65535" language, I infer that 65535 *is* an allowed value.

Please ensure that your normative statement here is very clear about whether "between" is intended to include its high and low limits as acceptable values.

[Ballot comment]
Section 4 contains:

  As explained in Section 3, the relationship between MaxRtrAdvInterval
  and AdvDefaultLifetime must be chosen to take into account the
  probability of packet loss.

The use of a non-normative "must" here indicates that you probably want to update your RFC2119 boilerplate to be RFC8174 boilerplate.

[Ballot comment]
I like what the document does, but it could really really do with a good editing pass; I've sent some nits / comments to Suresh off-list.
Some bits I was unable to parse, but I trust Suresh to fix them.

I'm a bit surprised it doesn't mention RFC7772 - it feels very related to me, but I may just be wrong!

[Ballot comment]
Just one quick question to double-check: Are the defaut values in RFC4861 still recommended or not? Maybe note this in the text to avoid any confusion!

Also, as already noted in the sphepherd write-up, the abstract should mention the update.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-6man-maxra-03, which is currently in Last Call, and has the following comments:

We have a question about this document:

We understand that this document updates RFC 4861, which is the reference for a number of registrations and registries at https://www.iana.org/assignments/icmpv6-parameters. Should this document be listed as an additional or replacement reference for any of those registrations/registries?

If not, we understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Amanda Baber
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2017-09-15):

From: The IESG
To: IETF-Announce
CC: ipv6@ietf.org, bob.hinden@gmail.com, draft-ietf-6man-maxra@ietf.org, otroan@employees.org, terry.manderson@icann.org, 6man-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Support for adjustable maximum router lifetimes per-link) to Proposed Standard


The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document: - 'Support for adjustable maximum router
lifetimes per-link'
  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 2017-09-15. 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


  The neighbor discovery protocol specifies the maximum time allowed
  between sending unsolicited multicast Router Advertisements from a
  router interface as well as the maximum router lifetime.  It also
  allows the limits to be overridden by link-layer specific documents.
  This document allows for overriding these values on a per-link basis.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-6man-maxra/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-6man-maxra/ballot/


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

Title          : Support for adjustable maximum router lifetimes per-link
Authors        : Suresh Krishnan
                  Jouni Korhonen
                  Samita Chakrabarti
                  Erik Nordmark
                  Andrew Yourtchenko
Filename        : draft-ietf-6man-maxra-03.txt
Pages          : 6
Date            : 2017-07-03

(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

  This is appropriate as this document updates a standards track
  RFC.  Standards Track is indicated on the title page header and
  abstract.


(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:

  The neighbor discovery protocol specifies the maximum time allowed
  between sending unsolicited multicast Router Advertisements from a
  router interface as well as the maximum router lifetime.  It also
  allows the limits to be overridden by link-layer specific documents.
  This document allows for overriding these values on a per-link basis.

Working Group Summary:

  There is support for this document in the 6MAN working group.  Several
  issues were raised during the w.g. last call.  These issues are
  resolved in the current draft.  There is a concensus to advance this
  document.

Document Quality:

  The quality of the document is good, it has received adequate review
  in the working group on the mailing list and at several 6man sessions
  at IETF meetings. 


Personnel:

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

  Document Shepherd:  Bob Hinden
  Responsible AD: Terry Manderson


(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.

  The document Shepard has followed the process in the working group,
  followed the discussion in the working group, and thinks that the
  issues raised have been resolved in the current draft.


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

  No concerns.


(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, N/A


(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.

  No specific concerns.


(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?

  Yes, all of the authors have confirmed that there is no IPR and full
  conformance with BCP78 and BCP79.


(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.


(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 a good consensus around this document.  There has been
  active discussion on the mailing list and at 6man face to face
  sessions. 


(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 appeals have been threatened, nor is there any extreme discontent.


(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.

  The only ID Nit is that the abstract needs to mention that RFC4861 is
  updated.  This will be fixed in the next version.


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

  N/A

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

  The document has a separate Normative and Information reference
  section.  References are characterized correctly.

(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, all references are published RFCs.


(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.

  N/A


(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.

  This document will not change the status of any other RFCs.  It does
  update RFC4861, and this is noted in the header.  It needs to be added
  to the Abstract when the next version is published.


(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).

  There are no IANA actions in the document.


(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.

  N/A


(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.

  N/A