(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 clearly marked on the title page. This is
appropriate since this documents a protocol 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 an IP-based encapsulation for MPLS, referred to as
MPLS-in- UDP (User Datagram Protocol).
Working Group Summary
There is WG consensus to progress this document.
Document Quality
There are at least three existing implementations of the protocol, and some
deployment. One or more other vendors are believed to be either implementing or
planning to implement. The document has been well reviewed.
Personnel
Loa Andersson is the Document Shepherd.
Alia Atlas is the Responsible Area Director.
Note: Until recently Ross Callon was the Document Shepherd, but as
part of the IETF Last Call process he became an author.
During the same process Adrian Farrel (former responsible AD) contributed
key text on Congestion Control and has been listed as contributor.
(3) Briefly describe the review of this document that was performed by
the Document Shepherd.
Ross as Shepherd:
The document shepherd has read the document and has also checked the reviews
that we done by the MPLS review team and the joint Transport and Routing/MPLS
team. This is a relatively simple protocol and the document shepherd believes
that it is ready for publication.
Loa as Shepherd:
The current shepherd was involved in the process to adopt this as a wg document
and reviewed the document carefully at that time. In the intermediate period the
reviews has been limited to folow what has been going on. The shepherd has
re-read version -08 now and agree with the former shepherd's assessment.
(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?
This document has been well reviewed. It was reviewed by the MPLS Review Team.
The IETF last call and discussions in the Transport area revealed concerns
related to congestion control and use of the UDP checksum. A joint team of
routing and transport area experts and document authors have carefully reviewed
and updated the document to relieve these concerns. No further review is felt
necessary other than a repeat of the IETF last call.
(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?
No concerns.
Don't know exactly where to place this. The document had - when publication was
requested - five authors. The process to resolve the IETF LC comments added two
new authors and one contributor, We have, after consulting with the authors,
moved two of the original authors to the contributor section.
(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. One IPR disclosure was filed on the individual document before it was
considered for adoption as a WG document, and was reissued to apply to the WG
document. All authors and contributors have indicated that they are not aware
of any other IPR that applies to this document.
(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
One IPR disclosure was filed and was mentioned in the call for adoption and in
the WG last calls.
(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 WG as a whole understands the document. There are multiple people in favor,
one person was earlier opposed, and a significant number of people are neutral.
(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?
There are no threats of appeals.
(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.
No IDnits found.
(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
Not applicable.
(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?
All normative reference are already 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.
All normative references are to Standards Track RFCs or BCPs.
(16) Will publication of this document change the status of any
existing RFCs?
No.
(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 section looks correct and appropriate to the document shepherd. Two UDP
Port numbers will need to be assigned.
(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.
No new IANA registries are needed.
(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.
There is no formal language in the document.