Document Shepherd write up for draft-ietf-pwe3-dynamic-ms-pw-19.txt
The PWE3 working group request that
Dynamic Placement of Multi Segment Pseudowires
draft-ietf-pwe3-dynamic-ms-pw-19.txt
is published as an RFC on the standards track.
(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?
The document should be published as a Proposed Standard.
The document defines new protocol procedures, information elements as well as
assigns code points from IANA registries that requires IETF consensus. The
document needs to be on the standards track.
All the infor is correctly captured in the title page header.
(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 section:
Technical Summary
A Multi-Segment pseudowire (MS-PW) is defined as a set of two or more
contiguous pseudowire (PW) segments that behave and function as a single point-
to-point PW. This document describes extensions to the PW control
protocol to dynamically place the segments of the multi segment
pseudowire among a set of Provider Edge (PE) routers.
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 process was pretty straightforward, though
sometimes a bit slow since it has been waiting for completion of
other documents.
Several individual proposals were intiially sent to the PWE3 group to
suggest solutions to the Dynamic MS-PW space. The working group
requested that they were merged into a single document. This document
were accepted as a working group document. To the shepherd's knowledge,
there is no dissent regarding the final version of thedocument.
(What is included below does not need to go into the Working Group Summary,
but is information for he IESG and reviewers,)
The only thing that need to be mentioned is that it has taken a very
long time for the document to reach this publication request.
The delay have several different reason, at the start there were several
individual drafts that were merged in to one singel document that were
accepted as a working group document.
Since this document specifies how to dynamically set up multi-segment
pseudowires it has been in a waiting mode for e.g.:
[RFC6073] Martini et.al. "Segmented Pseudowire", RFC6073,
January 2011
That draft is essential when it comes to set up configured pesudowires.
Lately it was also realized that all the "natural" shepherds were listed as
authors and contributors to the document. The current shepherd came on
early 2013 and i has taken some time to complete this write-up, please see
also the IPR section,
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?
The document is well reviewed and the shepherd has no concerns
about the level of review.
The working group mailing list has been polled about implementations
of this draft.
We know existing implementations of this draft.
We know of further vendors that has stated that they will implement the
draft.
We also have indications that the implementations that has been deployed.
There are no MIB doctor or media type expert review needed.
Personnel
Who is the Document Shepherd? Who is the Responsible Area
Director?
Loa Andersson is the Document Shepherd
Stewart Bryant is the Responsible AD
(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 shepherd was asked to shepherd this document fairly late; the
working group chairs had a problem to find a shepherd since the
"all the active members of the working group" are listed as co-authors
(editors, authors and contributing authors).
The shepherd did a detailed review of the document; resulting in a
significant number of comments. These comments has all been addressed.
The shepherd is convinced that the document is ready to be published.
(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
No such 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 need for this type of reviews.
(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.
Other than what is captured in section 7, the shepherd as no concerns
or issues about this document.
(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.
Background:
This document did originate as several individual documents that
were merged i to a single document, the first working group document
were published in December 2005.
Responses on the IPR poll:
As a result there are 20 authors listed in the authors address section,
the understanding of the shepherd is that all these people have had influnce
on the document at one time or another.
An IPR poll have been sent to the 20 authors and to the working group
mailing list.
All the authors and contributors has responded that apart from the IPR disclosures
found om the IETF IPR web page they are not aware of any IPR.
Four of the authors (Luca Martini, Vasile Radoca, Mike Duckett and
Yohan(Yeong-il) Seo) has chosen not to respond to the mailing list, but
sent mails uni-directional to the shepherd and/or the wg chairs.
(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
There are fiveIPR disclosures against this document.
The first of these disclosures were filed in 2008, which is quite some time
after the first version of the wg document was published in 2005.
The other three disclosures were filed in 2012, which is almost 6.5 years after
the first publication of the wg document.
It has not been possible to check on the IPR disclosures on the documents
that were merged into the current document.
One of the IPR disclosures (#1885 is a third party disclosure that points to an
IPR the the disclosing party where involved in developing for an earlier
employer.
There is a fifth (third party) disclosure ( # 2176) was made by the by the same
person that made disclosure #1885 . The content of disclosure # 2176, is
a notification that the ownership of the IPR has changed.
The current owner of the IPR disclosed in # 2176 has chosen not to make
an IPR disclosure..
The shepherd has sent a mail to the working mailing explaining the IPR
situation, pointing out that we have an IPR that has not been disclosed by the
IPR owner and where we don't know the terms and conditions that applies
if a vendor implements this specification.
The shepherds conclusion is that the working group are content with the IPR
situation.
(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?
Since a huge portion of the active working group participants are listed as
co-authors this is in itself a strong indication that there is strong support for
the document.
The shepherd has also been active on the wg mailing list with (late) comments
on draft, and so far no opposition has been registered.
It is the opinion of the shepherd that this document has good to strong
support in the working group.
(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 such threats.
(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 ID nits tool gives one warning.
The document contain a disclaimer for pre-RFC5378 work, it is beyond the
Shepherd to advice in this case; the document certainly originated
before 10 November 2008. But the Shepherd has not been able to find out
if there are "original auhtors" that is not still listed as edors, authors or
contributors. The disclaimer has therefore been left in the docukent.
(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
No such formal review requirements.
(13) Have all references within this document been identified as
either normative or informative?
Yes - the references are correctly identified.
(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 the references (both normative and informative) are to existing
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.
No downward references.
(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 does not change any existing RFCs, it adds new
capabilities to the MPLS signaling protocols used for Dynamic Multi-Segment
PW setup.
(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).
This document defines new code points from already existing and
well defined IANA registries.
All the code points are assigned through IETF Consensus or Standards
Action.
All the code points have been temporarily allocated by "Early Allocation".
IANA is now asked to make these temporary allocations permanent.
(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.
There are no new IANA registries defined in this document.
(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 this document.