RNFD: Fast border router crash detection in RPL
draft-ietf-roll-rnfd-03

Document Shepherd Write-Up for Group Documents
This version is dated 4 July 2022.

>Document History
>Does the working group (WG) consensus represent the strong concurrence of a
>few individuals, with others being silent, or did it reach broad agreement?
>
>Was there controversy about particular points, or were there decisions where
>the consensus was particularly rough?

The document was not extensively reviewed (by numbers), as the ROLL WG only
has about seven active members.  The document came from a new contributor,
and was well received and reviewed by the small community.

Consensus was not rough.

>Has anyone threatened an appeal or otherwise indicated extreme discontent? If
>so, please summarize 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 appeals or threats of appeal.

>For protocol documents, are there existing implementations of the contents of
>the document? Have a significant number of potential implementers indicated
>plans to implement? Are any existing implementations reported somewhere,
>either in the document itself (as RFC 7942 recommends) or elsewhere
>(where)?

>Additional Reviews
>Do the contents of this document closely interact with technologies in other
>IETF working groups or external organizations, and would it therefore benefit
>from their review? Have those reviews occurred? If yes, describe which
>reviews took place.

There are no specific IETF WGs that need to review.

>Describe how the document meets any required formal expert review criteria,
>such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None of these apply.

>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? If there are any resulting errors or warnings, what is
>the justification for not fixing them at this time? Does the YANG module
>comply with the Network Management Datastore Architecture (NMDA) as specified
>in RFC 8342?

No YANG module.

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

None required.

>Document Shepherd Checks
>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?

The document deals with a specific need that has been observed from field
deployments of RFC6550.  It likely has applicability to RFC8994 as well.

>Several IETF Areas have assembled lists of common issues that their
>reviewers encounter. For which areas have such issues been identified
>and addressed? For which does this still need to happen in subsequent
>reviews?

No common issues.

>What type of RFC publication is being requested on the IETF stream (Best
>Current Practice, Proposed Standard, Internet Standard,
>Informational, Experimental or Historic)? Why is this the proper type
>of RFC? Do all Datatracker state attributes correctly reflect this intent?

Experimental.

>Have reasonable efforts been made to remind all authors of the intellectual
>property rights (IPR) disclosure obligations described in BCP 79? To
>the best of your knowledge, have all required disclosures been filed? If
>not, explain why. If yes, summarize any relevant discussion, including links
>to publicly-available messages when applicable.

>Has each author, editor, and contributor shown their willingness to be
>listed as such? If the total number of authors and editors on the front page
>is greater than five, please provide a justification.

Yes.

>Document any remaining I-D nits in this document. Simply running the idnits
>tool is not enough; please review the "Content Guidelines" on
>authors.ietf.org. (Also note that the current idnits tool generates
>some incorrect warnings; a rewrite is underway.)

No nits

>Should any informative references be normative or vice-versa? See the IESG
>Statement on Normative and Informative References.

Looks good to me.

>List any normative references that are not freely available to anyone. Did
>the community have sufficient access to review any such normative
>references?

There are none.

>Are there any normative downward references (see RFC 3967 and BCP
>97) that are not already listed in the DOWNREF registry? If so,
>list them.

none.

>Are there normative references to documents that are not ready to be
>submitted to the IESG for publication or are otherwise in an unclear state?
>If so, what is the plan for their completion?

None.

> Will publication of this document change the status of any existing RFCs?

No.

> Describe the document shepherd's review of the IANA considerations section,
> especially with regard to its consistency with the body of the document.

One allocation is made, and it looks correct.

> List any new IANA registries that require Designated Expert Review for
> future allocations. Are the instructions to the Designated Expert clear?
> Please include suggestions of designated experts, if appropriate.

No new registries.