25f2ee5067
Convert a few more URLs from http to https. - Legacy-Id: 9819 Note: SVN reference [9803] has been migrated to Git commit 73d876f9127ccd224edc06c49f4f99258445885c
264 lines
12 KiB
Plaintext
264 lines
12 KiB
Plaintext
{% if doc.stream %}{% if doc.stream.slug == 'ietf' %}{% if doc.group.type.slug == 'individ' %}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?
|
|
|
|
(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
|
|
|
|
Relevant content can frequently be found in the abstract
|
|
and/or introduction of the document. If not, this may be
|
|
an indication that there are deficiencies in the abstract
|
|
or introduction.
|
|
|
|
Working Group Summary
|
|
|
|
Was the document considered in any WG, and if so, why was
|
|
it not adopted as a work item there? Was there controversy
|
|
about particular points that caused the WG to not adopt the
|
|
document?
|
|
|
|
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?
|
|
|
|
Personnel
|
|
|
|
Who is the Document Shepherd? Who is 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.
|
|
|
|
(4) Does the document Shepherd have any concerns about the depth or
|
|
breadth of the reviews that have been performed?
|
|
|
|
(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.
|
|
|
|
(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.
|
|
|
|
(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.
|
|
|
|
(8) Has an IPR disclosure been filed that references this document?
|
|
If so, summarize any discussion and conclusion regarding the IPR
|
|
disclosures.
|
|
|
|
(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?
|
|
|
|
(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.)
|
|
|
|
(11) Identify any ID nits the Document Shepherd has found in this
|
|
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
|
|
Checklist). Boilerplate checks are not enough; this check needs to be
|
|
thorough.
|
|
|
|
(12) Describe how the document meets any required formal review
|
|
criteria, such as the MIB Doctor, media type, and URI type reviews.
|
|
|
|
(13) Have all references within this document been identified as
|
|
either normative or informative?
|
|
|
|
(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?
|
|
|
|
(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.
|
|
|
|
(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.
|
|
|
|
(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).
|
|
|
|
(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.
|
|
|
|
(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.
|
|
{% else %}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?
|
|
|
|
(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
|
|
|
|
Relevant content can frequently be found in the abstract
|
|
and/or introduction of the document. If not, this may be
|
|
an indication that there are deficiencies in the abstract
|
|
or introduction.
|
|
|
|
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?
|
|
|
|
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?
|
|
|
|
Personnel
|
|
|
|
Who is the Document Shepherd? Who is 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.
|
|
|
|
(4) Does the document Shepherd have any concerns about the depth or
|
|
breadth of the reviews that have been performed?
|
|
|
|
|
|
|
|
(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.
|
|
|
|
(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.
|
|
|
|
(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.
|
|
|
|
(8) Has an IPR disclosure been filed that references this document?
|
|
If so, summarize any WG discussion and conclusion regarding the IPR
|
|
disclosures.
|
|
|
|
(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?
|
|
|
|
(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.)
|
|
|
|
(11) Identify any ID nits the Document Shepherd has found in this
|
|
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
|
|
Checklist). Boilerplate checks are not enough; this check needs to be
|
|
thorough.
|
|
|
|
(12) Describe how the document meets any required formal review
|
|
criteria, such as the MIB Doctor, media type, and URI type reviews.
|
|
|
|
(13) Have all references within this document been identified as
|
|
either normative or informative?
|
|
|
|
(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?
|
|
|
|
(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.
|
|
|
|
(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.
|
|
|
|
|
|
(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).
|
|
|
|
(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.
|
|
|
|
(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.
|
|
{% endif %}{% else %}There is no default template for the {{d.stream}} stream
|
|
{% endif %}{% else %}There is no stream set for this document (thus, no default template)
|
|
{% endif %}
|