As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.
Changes are expected over time. This version is dated 24 February 2012.
(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?
This draft updates RFC 6333, which is a Proposed Standard, and is
informational. That seems strange. We could make it a BCP that updates the
proposed standard, which is also strange. The working group, by charter, is
limited to producing informational and BCP documents. I'll leave this in the
capable hands of the IESG - let us know what status you think it should have.
(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
DS-Lite, defined in RFC 6333, directs IANA to reserve 192.0.0.0/29
for the B4 element. This memo directs IANA to generalize that
reservation to include other cases where a non-routed IPv4 interface
must be numbered as part of an IPv6 transition solution.
Working Group Summary
There was support in the working group for the draft, and little if any dissent.
Document Quality
This is not a protocol; it is advice to implementers of 464xlat that the prefix
set aside for use with DS-Lite may also be used by them. Per Lorenzo Colitti,
it is implemented in the Android OS, and works.
Personnel
Document Shepherd: Fred Baker
Responsible Area Director: Joel Jaeggli
(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.
(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
No. It was reviewed by softwire, which contemplated taking it themselves and
didn't. It has been heavily reviewed by the working group. I doubt that it
needs review by other parties in the IETF.
(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.
(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.
(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.
(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
None 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?
The working group as a whole understands it and is OK with it. I wouldn't
describe that as a loud clamor, but if anyone was opposed, I'm pretty sure that
I would know.
(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.
The draft makes specific reference to the prefix from RFC 6333, which is
192.0.0.0/29. That shows up in idnits. That, however, is fundamental to the
document.
(13) Have all references within this document been identified as
either normative or informative?
The document refers to two RFCs: 6333 and 6877. Both are normative, and both
are current.
(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.
no
(16) Will publication of this document change the status of any
existing RFCs?
It does not change the status of RFC 6333, but it updates that document in the
sense that a prefix 6333 sets apart for a specific use is also made available
for another non-conflicting use.
(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.
The IANA is directed to update the description of an existing registry. The
IANA Considerations section conforms to IANA guidelines.