Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts
RFC 6123

Received changes through RFC Editor sync (changed abstract to 'It has often been the case that manageability considerations have been retrofitted to protocols after they have been specified, standardized, implemented, or deployed. This is sub-optimal. Similarly, new protocols or protocol extensions are frequently designed without due consideration of manageability requirements.

The Operations Area has developed "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions" (RFC 5706), and those guidelines have been adopted by the Path Computation Element (PCE) Working Group.

Previously, the PCE Working Group used the recommendations contained in this document to guide authors of Internet-Drafts on the contents of "Manageability Considerations" sections in their work. This document is retained for historic reference. This document defines a Historic Document for the Internet community.')

> (1.a) Who is the Document Shepherd for this document?
Julien Meuric
> 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?
Yes
> (1.b) Has the document had adequate review both from key WG members
> and from key non-WG members?
Yes. (RFC 5706 from OPSAWG can be seen as a superset of this draft.)
> Does the Document Shepherd have
> any concerns about the depth or breadth of the reviews that
> have been performed?
No concerns.
> (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?
No concerns (historic status).
> (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.
No concerns.
> 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 IPR.
> (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?
WG supports historic status (the draft has been used by other documents).
> (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 known conflict.
> (1.g) Has the Document Shepherd personally verified that the
> document satisfies all ID nits? (See theInternet-Drafts Checklist
> andhttp://tools.ietf.org/tools/idnits/). Boilerplate checks are
> not enough; this check needs to be thorough.
Yes.
> Has the document
> met all formal review criteria it needs to, such as the MIB
> Doctor, media type and URI type reviews?
Yes.
> (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?
No.
> If such normative references exist, what is the
> strategy for their completion? 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].
N/A.
> (1.i) Has the Document Shepherd verified that the document IANA
> consideration section exists and is consistent with the body
> of the document?
IANA section is consistent.
> 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].
N/A.
> 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?
Not needed.
> (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

It has often been the case that manageability considerations have
been retrofitted to protocols after they have been specified,
standardized, implemented, or deployed. This is sub-optimal.
Similarly, new protocols or protocol extensions are frequently
designed without due consideration of manageability requirements.

The Operations Area has developed "Guidelines for Considering
Operations and Management of New Protocols and Protocol Extensions"
(RFC 5706), and those guidelines have been adopted by the PCE Working
Group.

Previously, the PCE Working Group used the recommendations contained
in this document to guide authors of Internet-Drafts on the contents
of "Manageability Considerations" sections in their work. This
document is retained for historic reference.
> Working Group Summary
WG consensus to publish as historic RFC and move towards RFC 5706.
> Document Quality
No protocol extensions but the initiative has resulted in RFC 5706.
>