Shepherd writeup
rfc7611-10

(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?

A Standard Track publication is requested, and the title page header mentions it.
This is the proper type for a document proposing and updating procedures.

(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:

   Under certain conditions it is desirable for a BGP route reflector to
   be able to modify the Route Target list of a VPN route that is
   distributed by the route reflector, enabling the route reflector to
   control how a route originated within one VRF is imported into other
   VRFs.  This technique works effectively as long as the VRF that
   exports the route is not on the same PE as the VRF(s) that import the
   route.  However, due to the constraints of the BGP protocol, it does
   not work if the two are on the same PE.  This document describes a
   modification to the BGP protocol allowing this technique to work when
   the VRFs are on the same PE, allowing the technique to be used in a
   standard manner throughout an autonomous system.

Working Group Summary:

Opposition to the proposal was initally expressed by one contributor, but there was 
good support for adoption and no particular follow-up from that contributor.

Document Quality:

The specs are clear and concise, and document a fairly straightforward optional 
change to the BGP protocol procedures. The document was discussed in both l3vpn 
and idr working groups. These specs have been implemented at least in Cisco's IOS 
XR with field deployment.

Personnel:

Thomas Morin is the Document Shepherd.
Adrian Farrel 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 document is ready for IESG review. The document shepherd has done a thorough 
review of the document, a few minor editorial changes are suggested, that can be 
integrated by authors in parallel with the IESG review.

(4) Does the document Shepherd have any concerns about the depth or breadth of the 
reviews that have been performed?

No.

(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 specific concern.

(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?

All authors confirmed during WGLC (in May 2014) that any and all appropriate IPR 
disclosures required for full conformance with the provisions of BCP 78 and BCP 79 
have already been filed.

(8) Has an IPR disclosure been filed that references this document? If so, summarize 
any WG discussion and conclusion regarding the IPR disclosures.

No.

(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?

Good consensus.
10 to 20 people were involved, which is reasonable given that the use case is quite a 
niche use case.

(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.

Only one nit raised by idnits.

  -- The document seems to contain a disclaimer for pre-RFC5378 work, and may
     have content which was first submitted before 10 November 2008.  The
     disclaimer is necessary when there are original authors that you have been
     unable to contact, or if some do not wish to grant the BCP78 rights to the
     IETF Trust.  If you are able to get all authors (current and original) to
     grant those rights, you can and should remove the disclaimer; otherwise,
     the disclaimer is needed and you can ignore this comment. (See the Legal
     Provisions document at http://trustee.ietf.org/license-info for more
     information.)

The shepherd has taken the action of asking authors if they agree to grand these 
rights and then remove the said disclaimer in the next draft revision.

(12) Describe how the document meets any required formal review criteria, such as 
the MIB Doctor, media type, and URI type reviews.

Yes (allocation of a codepoint in a FCFS IANA registry: no review needed).

(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?

No such case.

(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 normative reference.

(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.

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. 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).

One new codepoint needed in an FCFS registry, properly explained in the IANA 
section, and the codepoint has already been allocated by IANA.
No new registry.

(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.

N/A

(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.

N/A