Procedures for Standards Track Documents to Refer Normatively to Documents at a Lower Level
draft-kucherawy-bcp97bis-04

[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-kucherawy-bcp97bis-04

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points.

132   other implementations of that standard.  For documents that are
133   referenced, any document that includes key information an implementer
134   needs would be normative.  For example, if one needs to understand a

What about following rewrite proposal to make the text read easier:

"For referenced documents, any document containing essential information
required by an implementer would be considered normative."

164   There are a number of circumstances in which an IETF document may
165   need to make a normative reference to a document at a lower maturity
166   level, but such a reference conflicts with Section 4.2.4 of
167   [RFC2026].  For example:

I find that in RFC2026 the section "4.2.4  Historic". Not sure how the pieces fit together.
mostlikely due to being too much rookie AD to understand the conflict reference

162 2.  The Need for Downward References

164   There are a number of circumstances in which an IETF document may
165   need to make a normative reference to a document at a lower maturity
166   level, but such a reference conflicts with Section 4.2.4 of
167   [RFC2026].  For example:

Should it be spelled out more explicit that this list is not a limited list?

200   The term "Standards-Track document", as used in this specification,
201   is assumed to include only Standards-Track documents at any maturity
202   level, plus BCPs, but not documents with any other status.

Would this include the historical documents that were valid when RFC was
written, but became historical after few years due to technology evolution.
(i guess i may be thrown of the rails by the reference to RFC2026 section 4.2.4 from earlier in the document)

238   At the option of the author/editor, similar notes may be attached to
239   non-normative references.

is this text necessary? this seems irrelevant for normative down-refs

241   The exception to this process is the unusual case where the source
242   document is less stable than the target document, even if the target
243   document is at a lower maturity level.  In such cases, the above
244   notation is omitted.

3 lines up it was already mentioned that the annotation can be omitted. not sure if these lines can be combined instead?

246   When the document is prepared to submit to the IESG for approval, a
247   document shepherd writeup [RFC4858] is normally prepared.  This

What about following readability rewrite:
"Upon preparing a document for submission to the IESG for approval, it is customary to create a document shepherd write-up, as outlined in [RFC4858]".

271   identified.  If it elects not to do so, then any future downref to
272   the same target document is subject again to the procedures described
273   in this document.  In making this decision, the IESG should take into

I am not sure what "any future downref to the same target document" exactly means. Does this mean that once a target document is used once as normative reference, that in futire instances for other source documents it can be used without special annotation notes?

311   *  the actual reference to it (e.g., a web link) may have dubious
312       location stability;

I am not a big fan of the word 'dubious'. It implies it it obscure or malicious or something else negative.
Using the wording 'questionable' has less negative connotation. a possible rewrite option:

'The stability of the actual reference's location, such as a web link, may be questionable.'

348 6.  Downref Registry

350   The IETF has previously established a registry of downrefs to RFCs
351   that have been previously waived by the IESG in the manner described
352   in Section 4.2.  The registry includes the name of the referenced RFC

How to access this registry? (i as rookie AD has no idea how to access this or how it is instantiated

Be well,
G/

[Ballot comment]
Thanks for working on this. However I am not sure what it the final outcome of this work other than adding some notes in the references. Hence, I am supporting Warren's discuss.

[Ballot comment]
# GEN AD review of draft-kucherawy-bcp97bis-04

CC @larseggert

Thanks to Vijay Gurbani for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/5ZJZXPwzpBcB3uuIPCiJMLQ6gKU).

## Comments

I agree with most of the other Discusses, which is why I decided to
just comment on this document rather than duplicating them. Generally, I feel we
need a much more lightweight process than we currently have and that we would
have if we adopted this revision.

### Section 2, paragraph 0
```
  2.  The Need for Downward References
```
Might want to add the very common example of needing to normatively cite a
cryptographic algorithm described in a CFRG document.

### Section 3, paragraph 2
```
    A reference involves two documents, the one in which the reference is
    embedded and the document referenced.  Where needed for clarity,
    these documents are referred to as the "source document" and "target
    document", respectively.
```
But which is which? I assume the "source" is the one containing the reference,
and the "target" is being references?

### Section 4.1, paragraph 4
```
    *  A note is included in the reference text that indicates that the
        reference is to a target document of a lower maturity level, that
        some caution should be used since it may be less stable than the
        document from which it is being referenced, and, optionally,
        explaining why the downref is appropriate.
```
Is there an xml2rfc and ideally kramdown-rfc way of doing that easily?

### Section 4.1, paragraph 5
```
    There is no separate review of these references.  For example, when
    the downref is to a document of a lower maturity level that is
    understood to be stable, the annotation can be omitted.
```
Understood by whom? And what does stable mean? I think this concept needs to be
removed from the process.

### Section 4.1, paragraph 5
```
    At the option of the author/editor, similar notes may be attached to
    non-normative references.
```
That seems redundant and would make it more difficult to spot the downrefs.

### Section 4.1, paragraph 5
```
    The exception to this process is the unusual case where the source
    document is less stable than the target document, even if the target
    document is at a lower maturity level.  In such cases, the above
    notation is omitted.
```
We don't have a defined notion of document stability. (See above, I think this
concept needs to go, or it needs to be clarified.)

### Section 4.2, paragraph 1
```
    With appropriate community review, the IESG may establish procedures
    for when normative downref should delay a document and when downrefs
    should simply be noted.  Absent specific guidance, authors and
    reviewers should use their best judgment.  It is assumed that, in a
    significant majority of cases, noting a downref is preferable to
    delaying publication.
```
I think our procedure is the DOWNREF registry. Would suggest to remove this and
just merge Section 6 here.

### Section 4.2, paragraph 4
```
    understanding of the relevant technical area.  For example, the use
    of MD5 [RFC1321] and HMAC [RFC2104] is well known among
    cryptographers.  Such documents are added to the "Downref Registry"
    defined in Section 6.
```
Would suggest to replace MD5 with another example.

### Section 6, paragraph 3
```
    Note that there is currently no registry of downrefs to non-IETF
    documents.
```
Should there be? I think yes.

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 4.1, paragraph 8
```
-    When the document is prepared to submit to the IESG for approval, a
-                        ---------
+    When the document is to be submitted to the IESG for approval, a
+                          +++      +++
```

#### Section 4.1, paragraph 8
```
-    writeup should contain a description of any downrefs that appear in
-            ^^^^^^
-    the document, and should make particular note of any downref that is
-                      ^^^^^^
+    writeup SHOULD contain a description of any downrefs that appear in
+            ^^^^^^
+    the document, and SHOULD make particular note of any downref that is
+                      ^^^^^^
```

#### Section 5, paragraph 11
```
-    that captures the important parts of the intended target docuemnt.
-                                                                  -
+    that captures the important parts of the intended target document.
+                                                                +
```

### Grammar/style

#### Section 1, paragraph 5
```
ly understand or implement the subject matter in the RFC, or whose contents
                              ^^^^^^^^^^^^^^
```
This phrase is redundant. Consider using "subject" to avoid wordiness.

#### Section 5, paragraph 7
```
ing access to those documents is to be be specified in the shepherd writeup.
                                    ^^^^^
```
Possible typo: you repeated a word.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]
I support Alvaro's discuss.

Hi Murray,

Thanks for this document, I'm always up for a single new RFC that replaces 3 others.  However, I also support Alvaro's discuss.  I'm not sure that the new process, or reaffirming an existing process that nobody follows, is necessary.  Specifically, I'm not quite sure what problem we are aiming at solving?

(1) p 3, sec 2.  The Need for Downward References

  *  There are exceptional procedural or legal reasons that force the
      target of the normative reference to be an informational or
      historical RFC or to be at a lower standards level than the
      referring document.

Would it be worth including the example of "Architecture" or "Framework" documents that are quite plausibly defined as being informational, but are still reasonably likely to be normatively referenced?


(2) p 4, sec 4.1.  Authors and Editors

  When a Standards-Track or BCP document requires a normative reference
  to a document of lower maturity, the authors/editors should apply the
  following very simple procedure:

Is there any downref from a Full Internet Standard to a Draft Standard?  Is there any downref from Informational to Experimental?


(3) p 5, sec 4.2.  The IESG

  With appropriate community review, the IESG may establish procedures
  for when normative downref should delay a document and when downrefs
  should simply be noted.  Absent specific guidance, authors and
  reviewers should use their best judgment.  It is assumed that, in a
  significant majority of cases, noting a downref is preferable to
  delaying publication.

I don't understand this, why would a downref delay publication of a document?  What would it be waiting for?  Do you mean delay by reissuing the IETF last call?


(4) p 5, sec 4.2.  The IESG

  When a document is presented to the IESG for publication that
  contains a downref not called out by the author/editor(s) as
  described in the previous section, it is strongly recommended that
  the normal IETF Last Call procedure will be issued, with the need for
  the downref explicitly documented in the Last Call itself.  Any
  community comments on the appropriateness of downrefs will be
  considered by the IESG as part of its deliberations.

I think that it is probably simpler for downrefs (not in the registry) to always be called out in the last call.  Don't we have tooling that is meant to already spot this?


(5) p 6, sec 5.  Non-IETF Target Documents

  Authors and editors should try to avoid such references due to the
  challenges they present, as they affect the IETF's ability to ensure
  the quality of its output.  However, such references are not always
  avoidable.

Should "references" be replaced with "normative references"?



Nit level comments:

(6) p 3, sec 2.  The Need for Downward References

  *  A standards document may need to refer to a proprietary protocol,
      and the IETF normally documents proprietary protocols using
      informational RFCs.

Did you mean "standards track document" for "standards document" here?


(7) p 4, sec 3.  Definitions

  The term "Standards-Track document", as used in this specification,
  is assumed to include only Standards-Track documents at any maturity
  level, plus BCPs, but not documents with any other status.

Here you refer to "standards-track document", in other places it has been referred to without the hyphen and capitalization.

Regards,
Rob

[Ballot discuss]
I'm still very unclear *exactly* what problem this is intended to address; we can already normatively refer to lower level documents.

This document seems to add a *large* amount of process for the authors, the IESG, the community/WGs, and possibly the RFC Editor as well, and I'm not sure what the gain is here.

As Alvaro pointed out, we already have the "annotation" procedure in RFC4897 (published more than 15 years ago), and we don't actually use it, and nothing seems to have broken.
We also already have the "misref" bit solved - it's part of normal IETF processing.

RFC3967, RFC4897, RFC8067 are important documents, and I don't think that we should be obsoleting them without a really good reason - and I don't see that here.

[Ballot discuss]
(1) The annotation procedure in §4.1 was originally defined in rfc4897 more than 15 years ago.  I have seen plenty of downrefs, but I have yet to see this process used.  This DISCUSS point challenges the continued inclusion of this procedure as a best current practice as it seems to have never been adopted.


(2) §4.2:

  With appropriate community review, the IESG may establish procedures
  for when normative downref should delay a document and when downrefs
  should simply be noted.  Absent specific guidance, authors and
  reviewers should use their best judgment.  It is assumed that, in a
  significant majority of cases, noting a downref is preferable to
  delaying publication.


The IESG has already documented this guidance in the 2006 "IESG Statement: Normative and Informative References", where it says:

  The distinction between normative and informative references is often
  important. The IETF standards process according to RFC 2026 and RFC 3967,
  and the RFC Editor publication process, both need to know whether a
  reference to a work in progress is normative. An RFC cannot be published
  until all of the documents that it lists as normative references have been
  published. In practice, this often results in the simultaneous publication
  of a group of interrelated RFCs.

It is clear that the IESG Statement expects publication to be delayed (vs. just noting the downref).

[Ballot comment]

§6:

  Going forward, new registry entries should also record the reason the
  registry addition was made, the name of the external body owning the
  target reference, and the name of the Area Director making the new
  entry.

  Note that there is currently no registry of downrefs to non-IETF
  documents.


Unfortunately, this text (or the rest of the document) doesn't include rfc2119 keywords.

What kind of entries are expected to "record the reason the registry addition was made"?  Without additional guidance, entries such as "approved by the IESG" could be used.

Also, for the existing downref registry, there is no "external body owning the target reference".  Was this entry meant for a registry of non-IETF documents?

[Ballot discuss]
** Section 4.2

  When a document is presented to the IESG for publication that
  contains a downref not called out by the author/editor(s) as
  described in the previous section, it is strongly recommended that
  the normal IETF Last Call procedure will be issued, with the need for
  the downref explicitly documented in the Last Call itself.

In the first paragraph, what’s the more precise definition of the state in which a “document is presented to the IESG” that doesn’t call out the downref?  Is that the WG submitting it as a PubReq to the AD? Or the full IESG for telechat review?  If it’s the former (AD Review) then why can’t the document just be updated with the new style of reference with any other AD Review feedback?  If it is the latter (telechat), is this text suggesting _another_ IETF LC since the document won’t reach the full IESG without going through an initial IETF LC?  A duplicate IETF LC seems to be covered in the next paragraph.

[Ballot comment]
** Section 4.1

  *  A note is included in the reference text that indicates that the
      reference is to a target document of a lower maturity level, that
      some caution should be used since it may be less stable than the
      document from which it is being referenced, and, optionally,
      explaining why the downref is appropriate.

A process aside: are we going to hold publication until we have coordinated with the RFC Editor on how such a note would look, and “establish[ed] procedures regarding the text to use, or give guidance on this text.”

** Section 4.2
    This should only occur when the same document (and
    version)
    ...
    Such documents are added to the "Downref Registry"
    defined in Section 6.

The first phrase comes from RFC3967.  I’m wondering about the intent of the parenthetical. The DOWNREF registry only has RFCs.  What is the versioning envisioned here?  See related comments in Section 6.

** Section 6.

  Going forward, new registry entries should also record the reason the
  registry addition was made, the name of the external body owning the
  target reference, and the name of the Area Director making the new
  entry.

  Note that there is currently no registry of downrefs to non-IETF
  documents.

I’m not sure how to take the observation in the last paragraph.  Are we expanding the aperture of the downref registry?

POSSIBLE NEW TEXT (to replace the current last sentence):

Going forward, the applicability of this downref registry is expanded to include non-IETF documents.

[Ballot discuss]
Can we have a (normative) reference to the downref registry at https://datatracker.ietf.org/doc/downref ?
After reading the document I had to google "ietf downref registry" to find it :P

[Ballot comment]


  The IESG may, at its discretion, establish policies regarding
  external documents referenced normatively by Standards-Track RFCs in
  light of these challenges.  Such policies are to be developed with
  solicitation of community input.

It is as if the document is conveying a new power to the IESG here, but doesn't the IESG already have this power? Eg this sentence isn't adding anything new? In fact, this document's author is an IESG member acting on making a policy developed with solicitation of community input itself already ! Q.E.D ?

[Ballot discuss]
I acknowledge that Section 4.1 is largely inherited from RFC 4897, but I'm scratching my head over the importance of a document being "stable"... without ever defining what "stability" means, for example,

  The exception to this process is the unusual case where the source
  document is less stable than the target document, even if the target
  document is at a lower maturity level.  In such cases, the above
  notation is omitted.

If you pressed me to define document "stability" I'd first reach for whether it's a good-quality archival reference. But that can't be it, because all RFCs are good archival references, no matter their maturity level.

Because of this, I don't know how to apply the standard set out by Section 4.1. A possible fix would be to remove all the sentences and clauses that mention "stable", a different one would be to define what it means.

[Ballot comment]
## COMMENT

### Section 4.1:

I've read this a few times and I don't understand what it's telling me, sorry:

  There is no separate review of these references.  For example, when
  the downref is to a document of a lower maturity level that is
  understood to be stable, the annotation can be omitted.

It looks like the "for example" grafts the final sentence on to what was in RFC 4897, but I don't get how that sentence is an example of "there is no separate review", it just seems like an additional piece of specification. (But see also my discuss about "stable".)

### Section 4.2:

This section says that:

  In the case of a downref approved in this manner, the annotations
  described above should be added to the reference unless the IESG,
  after consideration of Last Call input, concludes it is
  inappropriate.

I've never seen one of these annotations in the wild. I went and checked the last eight references in the Downref registry (https://datatracker.ietf.org/doc/downref/) so I could see what one looked like. There aren't any.

Unless I'm confused, it appears this rule is honored mainly in the breach. As such, perhaps it doesn't make sense to propagate it forward into bcp97bis. Alternately, if we are going to keep it as a requirement, then I guess we should start doing it. I am not advocating the latter approach, but it does seem like we gotta do one or the other.

### Section 5:

I agree with Éric's comment that some more precise term than "freely available" is desirable.

### Section 6:

  The IETF has previously established a registry of downrefs to RFCs
  that have been previously waived by the IESG in the manner described

Is there a reason there isn't a reference to the Downref registry's location? (That being, https://datatracker.ietf.org/doc/downref/). Would the reference be... normative? (Also, how about dropping one of the "previously"s? Probably the first one.)

### Section 6:

The first paragraph and the second are in almost-conflict:

  Going forward, new registry entries should also record the reason the
  registry addition was made, the name of the external body owning the
  target reference, and the name of the Area Director making the new
  entry.

  Note that there is currently no registry of downrefs to non-IETF
  documents.

That is to say, the first paragraph tells us that we have to include "the name of the external body" (by the way, shouldn't there be "(if any)" appended to that?). But the second tells us there's no such animal. I guess the first paragraph implies we're going to start tracking non-IETF downrefs, and the second paragraph should be deleted?

## NITS

- s/very simple procedure/procedure/
- s/docuemnt/document/
- Why is RFC 3339 a "possible" example? Isn't it just... an example?

[Ballot comment]
- I don't understand this paragraph:

"The exception to this process is the unusual case where the source document is less stable than the target document, even if the target document is at a lower maturity level. In such cases, the above notation is omitted."

So if there's a Experimental document that normatively references an Informational reference, but the Info document is though to be "more stable", we just don't annotate anything in the references section at all? To me, that seems more confusing than just explicitly stating something in the text.

- s/docuemnt/document

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-kucherawy-bcp97bis-04
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Please note that Patrick Mevzek is the DNS directorate reviewer (at chairs' request) and you may want to consider his dns-dir reviews as well (mainly nits):
https://datatracker.ietf.org/doc/review-kucherawy-bcp97bis-03-dnsdir-lc-mevzek-2022-10-16/

Special thanks to Erik Kline for the shepherd's detailed write-up.

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS

### Section 2

Suggest not to use the (too) old MD5 as an example...

### Section 4.1

s/A note is included in the reference text/An optional note is included in the reference text/ ?

### Section 5

In `it may not be freely available` should 'freely' be more descriptive ? I.e., behind a paywall ? or restricted publication to members only ? Suggest to use 'cost free' (or any more English wording)

```
  Note that there is no requirement for a freely available copy of the
  reference beyond the publication of the draft as an RFC.
```
To be honest, I am a little puzzled with the above text: if a required/normative reference is no more available after publication, then how can the specification be implemented ? But, this depends what is meant by 'freely', if it means 'without any cost' then this is fine, if it means 'availably only to members of a 3rd party', then this is annoying to say the least.

### Section 6

How can authors find this 'downref registry'? Should it be documented/specified ? (to be honest, I have no clue as I rely on idnits...)

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-kucherawy-bcp97bis-03, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-10-17):

From: The IESG
To: IETF-Announce
CC: draft-kucherawy-bcp97bis@ietf.org, ek.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Procedures for Standards Track Documents to Refer Normatively to Documents at a Lower Level) to Best Current Practice


The IESG has received a request from an individual submitter to consider the
following document: - 'Procedures for Standards Track Documents to Refer
Normatively to
  Documents at a Lower Level'
  as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-10-17. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  IETF procedures generally require that a standards track RFC may not
  have a normative reference to another standards track document at a
  lower maturity level or to a non standards track specification (other
  than specifications from other standards bodies).  For example, a
  standards track document may not have a normative reference to an
  informational RFC.  Exceptions to this rule are sometimes needed as
  the IETF uses informational RFCs to describe non-IETF standards or
  IETF-specific modes of use of such standards.  This document defines
  the procedure used in these circumstances.

  This document merges and updates, and thus obsoletes, RFC 3967, RFC
  4897, and RFC 8067.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-kucherawy-bcp97bis/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for draft-kucherawy-bcp97bis

*This shepherd writeup version is dated 4 July 2022.*

## Document History

1. Was the document considered in any WG, and if so, why was it not adopted as a
  work item there?

It was discussed on ietf@ first:

  https://mailarchive.ietf.org/arch/browse/ietf/?q=draft-kucherawy-bcp97bis

where is was suggested to go to gendispatch.  The discussion there:

  https://mailarchive.ietf.org/arch/browse/gendispatch/?q=draft-kucherawy-bcp97bis

yielded "AD sponsorship is fine".

2. Was there controversy about particular points that caused the WG to not adopt
  the document?

No.  This being a process document the impetus was largely that it should
go through a dispatch process.

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

4. 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][3] recommends) or elsewhere
  (where)?

Not applicable.

## Additional Reviews

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

Not applicable.

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.

Not applicable.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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][5]?

Not applicable.

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.

Not applicable.  The id-nits tool reports no real issues (see also #14 below).

## Document Shepherd Checks

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.

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

- None.
- None.

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

- BCP.
- Because it is a bis and merge of 3 other documents that form BCP 97.
- Yes.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? 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.

No known IPR claims.

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

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

No nits of note.

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

No.

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

None.

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

None.

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

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

- It will obsolete RFCs 3967, 4897, and 8067.
- Noted on the title page, mentioned in the abstract and in the introduction.

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. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

Not applicable.

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

Not applicable.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

[S4.2; comment]

* The "Downref Registry" mention here could have a forward reference to S7.

[S9; question]

* Is the downref registry URL worth including?  I would assume that
  https://datatracker.ietf.org/doc/downref/ is stable enough to be referenced but
  perhaps it's not important.