1.Does the working group (WG) consensus represent the strong
concurrence of a few individuals, with others being silent, or did it
reach broad agreement?
There is broad support for this draft in the WG.
2.Was there controversy about particular points, or were there
decisions where the consensus was particularly rough?
No.
3. Has anyone threatened an appeal or otherwise indicated extreme
discontent?
No.
4. For protocol documents, are there existing implementations of the
contents of the document?
Yes.
5. Does this document need review from other IETF working groups or
external organizations?
No.
6. Describe how the document meets any required formal expert review
criteria, such as the MIB Doctor, YANG Doctor, media type, and URI
type reviews.
No such formal review required.
7. If the document contains a YANG module, has the final version of
the module been checked with any of the recommended validation tools
for syntax and formatting validation?
This document does not contain a YANG module.
8. Describe reviews and automated checks performed to validate
sections of the final version of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL,
etc.
No such formal language exists in this draft.
9. Based on the shepherd's review of the document, is it their opinion
that this document is needed, clearly written, complete, correctly
designed, and ready to be handed off to the responsible Area Director?
Yes. (See Shepherd's review here:
https://mailarchive.ietf.org/arch/msg/babel/5FDtAT-0y5gZ9w-t8MQhiwoulnw/
all comments in which have been resolved.)
10. Several IETF Areas have assembled lists of common issues that
their reviewers encounter. Do any such issues remain that would merit
specific attention from subsequent reviews?
https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
Nothing pops out as need special attention. The draft has had an
early Routing Directorate review. See
https://datatracker.ietf.org/doc/review-ietf-babel-rtt-extension-03-rtgdir-early-halpern-2023-07-18/
11. What type of RFC publication is being requested on the IETF stream
(Best Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental, or Historic)?
Standards Track as it updates Proposed Standard RFC 8966 and
describes a protocol change that has been in successful use for
several years.
12. Has the interested community confirmed that any and all
appropriate IPR disclosures required by BCP 78 and BCP 79 have been
filed?
Yes, see
https://mailarchive.ietf.org/arch/msg/babel/fqqucGWKpjtnK2prCBX60OHCyfI/https://mailarchive.ietf.org/arch/msg/babel/o7nDNTn0cDWE96BT1snIKJ5GmCA/https://mailarchive.ietf.org/arch/msg/babel/Bwt_0_YUw8lYis0owgN-ReB65nY/
13. If yes, summarize any discussion and conclusion regarding the
intellectual property rights (IPR) disclosures, including links to
relevant emails. If the number of Authors/Editors on the front page is
greater than 5, please provide a justification.
There was no discussion regarding intellectual property because no
such IPR has been disclosed. There are 2 authors on the title page.
14. Identify any remaining I-D nits in this document. (See the idnits
tool and the checkbox items found in Guidelines to Authors of
Internet-Drafts). Simply running the idnits tool is not enough; please
review the entire guidelines document.
https://www6.ietf.org/tools/idnits/
The I-D nits tools complains about non-ASCII characters but these
are all legitimate characters in names or the like. The Updates
header on the title page should say 8966 rather than 8967 but
this is expected to be fixed during resolution of AD/Directorate
comments.
15. Should any informative references be normative or vice-versa?
No. References are correctly classified as normative or informative.
16. List any normative references that are not freely available to
anyone.
All normative references are standards track RFCs and so freely
available.
17. Are there any normative downward references (see RFC 3967, BCP
97)?
No.
18. Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?
No.
19. Will publication of this document change the status of any
existing RFCs?
No.
20. 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 aspects of the document requiring IANA
assignments are associated with the appropriate reservations in IANA
registries. Confirm that any referenced IANA registries have been
clearly identified.
Tht IANA Considerations for this document correctly only specify the
assignment of a single code point from the already existing babel
Sub-TLV Types registry. Since this is Expert Review, the type has
already been assigned as shown in the document.
21. List any new IANA registries that require Designated Expert Review
for future allocations. Are the instructions to the Designated Expert
clear?
No IANA registries created.