Using 127-Bit IPv6 Prefixes on Inter-Router Links
draft-ietf-6man-prefixlen-p2p-01

[Ballot comment]
I have reduced my position from a Discuss after useful discussion with two of the authors about whether an "updates" clause would be useful/relevant.

It would be good to find a way to dilute the language that appears to say the I-D is fixing some specific issues in a specific RFC. Maybe a way forward would be to be more positive about this document "This document provides a definitive statement on..." "This document clarifies issues in a number of previous RFCs that have led to misunderstandings..." "This document offers latest guidance / best common practice on the use of..."
I'll leave this with the authors/shepherd/AD to think about, and if you think it is silly or wrong or impossible, then it's your document and this is only a Comment.

[Ballot discuss]
A relatively light-weight Discuss that is nearly trivial to handle.

In section 4:
  [RFC3627] discourages the use of 127-bit prefix lengths due to
  conflicts with the Subnet-Router anycast addresses, while stating
  that the utility of Subnet-Router Anycast for point-to-point links is
  questionable.

  [RFC5375] also says the usage of 127-bit prefix lengths is not valid
  and should be strongly discouraged, but the stated reason for doing
  this is to be in compliance with [RFC3627].

Given that this work proposes the use of 127-bit prefixes, is it the case that this I-D updates 3627 and 5375?

[Ballot comment]
Section 6., paragraph 3:
>      a) Addresses with all zeros in the rightmost 64 bits SHOULD NOT be
>      assigned as unicast addresses, to avoid colliding with the Subnet-
>      Router anycast address [RFC4291].
>
>      b) Addresses in which the rightmost 64 bits are assigned the
>      highest 128 values, (i.e., ffff:ffff:ffff:ff7f to ffff:ffff:ffff:
>      ffff), SHOULD NOT be used as unicast addresses to avoid colliding
>      with Reserved Subnet Anycast Addresses [RFC2526].

  Any reason these are not MUST NOTs?

[Ballot comment]
Pedantic, editorial nits about this text from the introduction:

  address,
  except those that start with the binary value 000,

s/address/addresses/
s/those/those unicast addresses/ (to clarify that
"those" == addresses and not IIDs)

[Ballot discuss]
Quick DISCUSS, which I can clear after a short answer:

Is there a reason not to list this document as updating RFC 4291?  What
about obsoleting RFC 3627 and updating RFC 5375?

[Ballot comment]
Pedantic, editorial nits about this text from the introduction:

  address,
  except those that start with the binary value 000,

s/address/addresses/
s/those/those unicast addresses/ (to clarify that those == addresses and not IIDs)

[Ballot discuss]
Quick DISCUSS, which I can clear after a short answer:

Is there a reason not to list this document as updating RFC 4291?  What about obsoleting RFC 3627 and updating RFC 5375?

State changed to In Last Call from Publication Requested.

The following Last Call Announcement was sent out:

To: IETF-Announce 
From: The IESG
Reply-to: ietf@ietf.org
CC:
Subject: Last Call: draft-ietf-6man-prefixlen-p2p (Using 127-bit IPv6 Prefixes on Inter-Router Links) to Proposed Standard

The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document:

- 'Using 127-bit IPv6 Prefixes on Inter-Router Links '
    as a 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 2011-01-06. 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.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-6man-prefixlen-p2p-01.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=20680&rfc_flag=0

Document Shepherd Write-Up for

> > (1.a) Who is the Document Shepherd for this document? Has the
> >      Document Shepherd personally reviewed this version of the
> >      document and, in particular, does he or she believe this
> >      version is ready for forwarding to the IESG for publication?

Bob Hinden.  I think the document is ready for publication.

> >
> > (1.b) Has the document had adequate review both from key WG members
> >      and from key non-WG members? Does the Document Shepherd have
> >      any concerns about the depth or breadth of the reviews that
> >      have been performed? 

This document has received adequate review in the working group.  The document shepherd and w.g. co-chair do not have any concerns with those reviews.

> >
> > (1.c) Does the Document Shepherd have concerns that the document
> >      needs more review from a particular or broader perspective,
> >      e.g., security, operational complexity, someone familiar with
> >      AAA, internationalization or XML?

The Security considerations section is on the light side.  The document includes a discussion about security related issues.  The document shepherd thinks this is adequate, but this should be reviewed.

Also, taking another look at if should this update/obsolete RFC3627.  It currently doesn't do this.

> >
> > (1.d) Does the Document Shepherd have any specific concerns or
> >      issues 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. Has an IPR disclosure related to this document
> >      been filed? If so, please include a reference to the
> >      disclosure and summarize the WG discussion and conclusion on
> >      this issue.

No concerns.

> >
> > (1.e) 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? 


The working group consensus is solid.  There has been push back from two individuals, but overall there is broad support in the w.g.  To quote Brian Carpenters email on Nov. 19, 2010: "Ship it. Long overdue, and good enough."


> >
> > (1.f) 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
> >      entered into the ID Tracker.)

No appeal has been threatened.

> >
> > (1.g) Has the Document Shepherd personally verified that the
> >      document satisfies all ID nits? (See the Internet-Drafts Checklist
> >      and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
> >      not enough; this check needs to be thorough. Has the document
> >      met all formal review criteria it needs to, such as the MIB
> >      Doctor, media type and URI type reviews?

The draft passes id nits checks.  There are no MIBs, URIs, or similar items.

> >
> > (1.h) Has the document split its references into normative and
> >      informative?

Yes

> > 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
> >      strategy for their completion?


All references point to published RFCs.


> > Are there normative references
> >      that are downward references, as described in [RFC3967]? If
> >      so, list these downward references to support the Area
> >      Director in the Last Call procedure for them [RFC3967].

There are no normative downward references.

> >
> > (1.i) Has the Document Shepherd verified that the document IANA
> >      consideration section exists and is consistent with the body
> >      of the document? If the document specifies protocol
> >      extensions, are reservations requested in appropriate IANA
> >      registries? Are the IANA registries clearly identified? If
> >      the document creates a new registry, does it define the
> >      proposed initial contents of the registry and an allocation
> >      procedure for future registrations? Does it suggest a
> >      reasonable name for the new registry? See [RFC5226]. If the
> >      document describes an Expert Review process has Shepherd
> >      conferred with the Responsible Area Director so that the IESG
> >      can appoint the needed Expert during the IESG Evaluation?

Yes, there are not any IANA considerations that needed to be processed.

> >
> > (1.j) Has the Document Shepherd verified that sections of the
> >      document that are written in a formal language, such as XML
> >      code, BNF rules, MIB definitions, etc., validate correctly in
> >      an automated checker?

N/A

> >
> > (1.k) 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
> >      Relevant content can frequently be found in the abstract
> >      and/or introduction of the document. If not, this may be
> >      an indication that there are deficiencies in the abstract
> >      or introduction.


This document defines the use of 127-bit IPv6 prefixes on inter-router point-to-point links.  This is similar to current practice in IPv4 of using 31-bit prefixes as defined in RFC3021.  This document specifies the reasons and motivation to use 127-bit IPv6 prefixes on inter-router point-to-point links, and requires that routers must support the assignment of /127 prefixes on point-to-point inter-router links.


> >
> >  Working Group Summary
> >      Was there anything in WG process that is worth noting? For
> >      example, was there controversy about particular points or
> >      were there decisions where the consensus was particularly
> >      rough?

The working group reviewed and discussed this document several times.  The draft has significantly improved from earlier versions and there is a consensus to move the document forward in it's current form.

> >
> >  Document Quality
> >      Are there existing implementations of the protocol? Have a
> >      significant number of vendors indicated their plan to
> >      implement the specification? Are there any reviewers that
> >      merit special mention as having done a thorough review,
> >      e.g., one that resulted in important changes or a
> >      conclusion that the document had no substantive issues? If
> >      there was a MIB Doctor, Media Type or other expert review,
> >      what was its course (briefly)? In the case of a Media Type
> >      review, on what date was the request posted?



This document has been reviewed by key members of the 6MAN working group and the chairs.