Special Use IPv4 Addresses
draft-vegoda-cotton-rfc5735bis-03

[Ballot discuss]
At the risk of having this be a "piling-on" DISCUSS, I'll use DISCUSS rather than NO OBJECTION in order to make a concrete suggestion.  Basically, this is supporting Brian's and Pete's DISCUSS positions.

Currently, this document specifies a bunch of address ranges, which includes 192.0.0.0/24.

The "IANA IPv4 Special Purpose Address Registry" ( http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xml ) sub-allocates that 192.0.0.0/24 block.

I suggest that this document do the following:

- Add a new registry to the "Internet Protocol version 4 (IPv4) Address Space" group.  Call it "IANA Special Use IPv4 Address Blocks".

- Make the allocation policy for the new registry be "IETF Review or IESG Approval."

- Make the new registry have two sections, "Summary Table" and "Details".

- Populate the "Summary Table" section with the contents of Section 3 of this document.

- Populate the "Details" section with the contents of Section 2 of this document.

- Change one paragraph in the "Details" section as follows:
OLD
  192.0.0.0/24 - This block is reserved for IETF protocol assignments.
  At the time of writing this document, there are no current
  assignments.  Allocation policy for future assignments is given in
  [RFC5736].
NEW
  192.0.0.0/24 - This block is reserved for IETF protocol assignments.
  Current assignments are in the "IPv4 Special Purpose Address Registry".
  Allocation policy for future assignments is given in [RFC5736].

[Note that this last bit is a DISCUSS-level error in this document anyway.]

[Ballot comment]
I agree with the Discuss position suggesting this document
should be populating an IANA registry.  I'll allow Brian and
Pete to resolve the issue.

[Ballot comment]
I would make this a Discuss, but I am sure that Pete will ably prosecute the point.

I do not understand why we are publishing an evolving set of RFCs to fulfill the function of a code-point registry.

[Ballot discuss]
I wish to support and amplify Brian's DISCUSS point #2: Why are the contents of this document necessary at all? Why is not all of this information in the !Pv4 Special Use Registry and this document simply populates that registry? I would think that the idea of a such a registry is so that we don't have to republish documents like this every so often.

[Ballot comment]
So this might be style thing, but since this document is obsoleting another document which obsoleted another document would it be better to retain Appendix A from RFC 5375 and just add an Appendix B which lists the differences between 5375 and this draft?  That way the trail of changes is kept?

[Ballot comment]
- typo: assignmnets

- the word "on" has disappeared from the description of 172.16/12
and of 192.168/16

- the word "to" has appeared in the description of 192.88.99/24

[Ballot discuss]
Thank you for a very concise and easy to read document.  I only have two points that I think warrant some discussion...

1. The corresponding RFC for the IPv6 space is RFC 5156.  It contains a specific discussion of ::/0, the default route.  It would be good to have a definitive statement for IPv4's default route 0.0.0.0/0.

2. Is there a reason why this draft does not specify that these addresses should appear in the IANA Special Purpose Address Registry?  It would seem that we need to ensure that the registry reflects the special purpose addresses allocated within IPv4, and it currently does not.

[Ballot comment]
Two things:
- It would be good to add a sentence in the intro why it this draft is updating RFC 6441, simply ensuring that the reader refers back to RFC 6441.
- Why has the reoccuring sentence "RFC, addresses within this block do not legitimately appear the" lost the 'on'? The update sentence does not parse well, at least not for me.

Authors prepared an update to address Last Call comments. The main changes are:
- Appendix A information is now in the Abstract, so Appendix A removed
- Reference to updating RFC 6441 removed as requested
- Terminology section, including RFC 2119 reference, removed as requested
- Russ' rewording of Intro, par 2 accepted
- Section 5 on policy issues deleted as requested
- Russ' rephrasing of the IANA Considerations section accepted
- SHOULD NOT lowercased in the Security Cconsideration section as requested
- Acknowledgements section now uses RFC 5735 section text
- List of references updated
- Our office address is updated

IANA has reviewed draft-vegoda-cotton-rfc5735bis-02, which is currently in Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no IANA Actions that need completion.

Shepherd write-up:

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

BCP. This is the correct status as it obsoletes RFC 5735, and
updates RFC 6441 which are also BCP documents. It documents best
operational practices.

(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 obsoletes RFC 5735 and updates RFC 6441.  It describes
  the global and other specialized IPv4 address blocks that have been
  assigned by the Internet Assigned Numbers Authority (IANA).  It does
  not address IPv4 address space assigned to operators and users through
  the Regional Internet Registries, nor does it address IPv4 address
  space assigned directly by IANA prior to the creation of the Regional
  Internet Registries.  It also does not address allocations or
  assignments of IPv6 addresses or autonomous system numbers.

Working Group Summary

  This document is not the product of a working group.

Document Quality

  This document brings the authoritative reference for special use
  IPv4 addresses up to date. Competent network operators already reflect
  the statements in this document in their configurations.

Personnel

  Russ Housley is both the Document Shepherd and the Responsible
  Area Director.

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

Russ Housley reviewed the document and believes that it is ready for
IETF Last Call and IESG Evaluation.

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

No

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

As the document is merely a collation of information provided in other
documents and does not introduce any new registrations, the most
significant reviews occurred during the publication of those documents.

(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 interested community has
discussed those issues and has indicated that it still wishes to advance
the document, detail those concerns here.

No concerns are known.

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

The authors do not believe that there is any IPR associated with
this document.

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

The authors are not aware of any IPR associated with this document.

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

The interested community is mostly the network operations community. The
IESG determined that there was a rough consensus in favour of RFC 6441,
which led to this document being written. Now that the discussion of
RFC 6441 is over, the authors believe there is a consensus for this
document to be approved and published as a BCP.

(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. No extreme discontent has been voiced.

(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 nit is that RFC 6441 is mentioned in the Abstract and
references but not in the body of the document. This is because the
document deal with the authoritative list of special use IPv4 addresses
and not best practices on filtering based on the list.

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

None of those formal review criteria apply.

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

Yes.

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

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

None.

(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
interested community considers it unnecessary.

Yes, this document will obsolete RFC 5735 and update RFC 6441. This
information is clearly described on the front page.

(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 clear. The document does not create
new requirements, registries or registrations.

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

None.

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

The document does not include XML code, BNF rules, MIB definitions,
or similar.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Special Use IPv4 Addresses) to Best Current Practice


The IESG has received a request from an individual submitter to consider
the following document:
- 'Special Use IPv4 Addresses'
  as Best Current Practice

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 2012-08-09. 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 obsoletes RFC 5735 and updates RFC 6441.  It describes
  the global and other specialized IPv4 address blocks that have been
  assigned by the Internet Assigned Numbers Authority (IANA).  It does
  not address IPv4 address space assigned to operators and users
  through the Regional Internet Registries, nor does it address IPv4
  address space assigned directly by IANA prior to the creation of the
  Regional Internet Registries.  It also does not address allocations
  or assignments of IPv6 addresses or autonomous system numbers.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-vegoda-cotton-rfc5735bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-vegoda-cotton-rfc5735bis/ballot/

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