Proto writeup for draft-ietf-karp-bfd-analysis:
(1) This is targeted to be an Informational RFC. It's role is
providing guidance to protocol authors. The type is listed on the
title page header.
(2) Sample IESG approval announcement:
Technical Summary
This document analyzes the security mechanisms for BFD, according
to the guidelines set forth in Section 4.2 of Keying and Authentication
for Routing Protocols Design Guidelines. In analyzes the current
security state of BFD, describes gaps, and discusses work that
needs to be done to close those gaps.
Working Group Summary
The Working Group was happy with the document. There was no
controversy. A chair of the BFD WG was active in its development
and review.
Document Quality
This document has been reviewed by the Working Group and by the
chairs. It does a good job laying out the issues with securing
BFD. The level of detail is appropriate to the working group goals
as laid out in the charter and the guidelines document.
Personnel
Brian Weis <bew@cisco.com> is the document shepherd. Adrian Farrel
<adrian@olddog.co.uk> is the responsible AD.
(3) The document shepherd has reviewed the document and believes
it is ready for publication.
(4) The document shepherd believes the document achieved sufficient
review during its development and Working Group last call process.
(5) Although this document is generated in the Routing Area, the
entire document relates to security. A substantial amount of the
working group comprises individuals who participate in the Security
Area and the document shepherd believes an adequate security review
was obtained.
(6) The document shepherd has no specific concerns or issues with
the document.
(7) Each author has confirmed that any and all appropriate IPR
disclosures have been filed.
(8) No IPR disclosures have been filed.
(9) WG consensus is solidly behind this document.
(10) There are no appeals expected, or claims of discontent expected.
(11) IDnits shows a clean run of the document, with one exception:
The abstract should not contain a reference. This will be corrected
in the next version.
(12) There are no required formal reviews.
(13) All references within this document have been identified as
either normative or informative.
(14) All normative references are stable published RFCs.
(15) There are no downward normative references.
(16) Publication of this document will not change the status of any
existing RFCs.
(17) There are no IANA considerations in this document.
(18) There are no new IANA registries added with this document.
(19) None of the document is written in a formal language.