(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
fixed.
Personnel:
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
https://www.ietf.org/mail-archive/web/babel/current/msg00531.html
Ths Shepherd looked it over and found a typo introduced by the update
to version -04 which has been fixed in -05. See
https://www.ietf.org/mail-archive/web/babel/current/msg01563.html
(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 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:
https://www.ietf.org/mail-archive/web/babel/current/msg01424.html
(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
discontent?
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).
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
reviews.
No such formal review required.
(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?
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.