Shepherd writeup

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

Informational as indicated on the title page.

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

Babel is a routing protocol based on the distance-vector algorithm
augmented with mechanisms for loop avoidance and starvation avoidance.
This applicability document argues that there exist niches where Babel
is useful and that are not adequately served by other protocols.

  Working Group Summary:

This was not a particularly controversial draft in the WG. There was
substantial suport and no objection on the mailing list and consensus
was declared during the WG meeting at IETF-102.

  Document Quality:

This is a brief applicability document. There are multiple independent
interoperable implementation of the routing protocol which is its
subject. A Shepherd's review found only one minor typo that has been

     Document Shepherd:  Donald Eastlake
     Responsible Area Director:  Martin Vigoureux

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

This is a short document that has had a routing review. See
Ths Shepherd looked it over and found a typo introduced by the update
to version -04 which has been fixed in -05. See

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

No such special review required. A rotuing QA review was done 31
January 2017.

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

 (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. Here is the IPR staement of the one author:

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

No IPR disclosures.

 (9) How solid is the WG consensus behind this document?

There is adequate consensus for the document. There was significant
discussion at WG Last Call time.

(10) Has anyone threatened an appeal or otherwise indicated extreme


(11) Identify any ID nits the Document Shepherd has found in this
     document. (See and the
     Internet-Drafts Checklist).

Didn't find any nits.

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

No such formal review required.

(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

The only normative reference is draft-ietf-babel-rfc6126bis which is
expected to be advanced soon.

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

(16) Will publication of this document change the status of any
     existing RFCs?

This document does not change the status of any other RFCs.

(17) Describe the Document Shepherd's review of the IANA
     considerations section, especially with regard to its consistency
     with the body of the document.

This document requires no IANA actions.

(18) List any new IANA registries that require Expert Review for
     future allocations.

No IANA registries created.

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

No such formal language is used in this document.