Algorithm Implementation Requirements and Usage Guidance for DNSSEC
draft-ietf-dnsop-algorithm-update-10

[Ballot comment]
(1) Abstract.  Nit.  There is a reference, [RFC6944], in the abstract which isn’t permitted.

(2) Section 1.2, Per “This document only provides recommendations with respect to mandatory-to-implement algorithms or algorithms so weak that recommendation cannot be recommended”

** Editorial:
s/algorithms so weak that recommendation cannot be recommended/
algorithms so weak that they cannot be recommended/

** The first part of the sentence doesn’t appear to be consistent with the RFC2119 words in the Section 3.1 Table which also includes RECOMMENDED/MAY (which is neither MTI or NOT RECOMMENDED)

(3) Section 1.3, Typo, s/from from/from/

(4) Section 3.1, Typo, s/cryptographics/cryptographic/

(5) Section 3.1, ED448 appears to be the only algorithm that doesn’t have treatment in even briefly describing its designated implementation recommendation.

(6) Section 3.1, The sentence “It is expected that ED25519 will become the future RECOMMENDED default algorithm …” is clear on the future.  However, looking back at the table in this section, it wasn’t clear what the current default algorithm is. 

(7) Section 3.2, The sentence “Operation recommendation for new and existing deployments.” Seems to stand alone or is missing some words.  Should it be something along the lines of “This section provides operational recommendations …”

(8) Section 3.2, Typo, s/is RECOMMENDED/is the RECOMMENDED/

(9) Section 3.4, Editorial, s/The SHA-256/SHA-256/

(10) Section 4, Typo, s/seciton/section/

(11) Section 5, Editorial, s/for the use of DNSSEC/for use in DNSSEC/

[Ballot comment]
(1) Abstract.  Nit.  There is a reference, [RFC6944], in the abstract which isn’t permitted.

(2) Section 1.2, Per “This document only provides recommendations with respect to mandatory-to-implement algorithms or algorithms so weak that recommendation cannot be recommended”

** Editorial:
s/algorithms so weak that recommendation cannot be recommended/
algorithms so weak that they cannot be recommended/

** The first part of the sentence doesn’t appear to be consistent with the RFC2119 words in the Section 3.1 Table which also includes RECOMMENDED/MAY (which neither MTI or NOT RECOMMENDED)

(3) Section 1.3, Typo, s/from from/from/

(4) Section 3.1, Typo, s/cryptographics/cryptographic/

(5) Section 3.1, ED448 appears to be the only algorithm that doesn’t have treatment in even briefly describing its designated implementation recommendation.

(6) Section 3.1, The sentence “It is expected that ED25519 will become the future RECOMMENDED default algorithm …” is clear on the future.  However, looking back at the table in this section, it wasn’t clear what the current default algorithm is. 

(7) Section 3.2, The sentence “Operation recommendation for new and existing deployments.” Seems to stand alone or is missing some words.  Should it be something along the lines of “This section provides operational recommendations …”

(8) Section 3.2, Typo, s/is RECOMMENDED/is the RECOMMENDED/

(9) Section 3.4, Editorial, s/The SHA-256/SHA-256/

(10) Section 4, Typo, s/seciton/section/

(11) Section 5, Editorial, s/for the use of DNSSEC/for use in DNSSEC/

[Ballot comment]
(1) Abstract.  Nit.  There is a reference, [RFC6944], in the abstract which isn’t permitted.

(2) Section 1.2, Per “This document only provides recommendations with respect to mandatory-to-implement algorithms or algorithms so weak that recommendation cannot be recommended”
** Editorial:
s/algorithms so weak that recommendation cannot be recommended/
algorithms so weak that they cannot be recommended/

** The first part of the sentence doesn’t appear to be consistent with the RFC2119 words in the Section 3.1 Table which also includes RECOMMENDED/MAY (which neither MTI or NOT RECOMMENDED)

(3) Section 1.3, Typo, s/from from/from/

(4) Section 3.1, Typo, s/cryptographics/cryptographic/

(5) Section 3.1, ED448 appears to be the only algorithm that doesn’t have treatment in even briefly describing its designated implementation recommendation.

(6) Section 3.1, The sentence “It is expected that ED25519 will become the future RECOMMENDED default algorithm …” is clear on the future.  However, looking back at the table in this section, it wasn’t clear what the current default algorithm is. 

(7) Section 3.2, The sentence “Operation recommendation for new and existing deployments.” Seems to stand alone or is missing some words.  Should it be something along the lines of “This section provides operational recommendations …”

(8) Section 3.2, Typo, s/is RECOMMENDED/is the RECOMMENDED/

(9) Section 3.4, Editorial, s/The SHA-256/SHA-256/

(10) Section 4, Typo, s/seciton/section/

(11) Section 5, Editorial, s/for the use of DNSSEC/for use in DNSSEC/

[Ballot comment]
Thanks to everyone who worked on this document. I agree with Benjamin's comments
regarding the need to move any reference that pertains to a normative statement
in this document -- including the normative language in the §3.1 and §3.3 tables
-- into the "Normative References" section.

---------------------------------------------------------------------------

§1.1:

>  New, stronger
>  algorithms appear and existing algorithms are found to be less secure
>  then originally thought.

Nit: "...than originally thought..."
          ^

Nit 2: This text describes the diminished desirability of older algorithms
only in the context of hardware advancements, which are usually incremental
and can be seen coming (although progress on large quantum computers might
change this). It should probably also mention the possibility of
newly-discovered vulnerabilities that can render algorithms undesirable
instantaneously (see, e.g., the MD5 Verisign root cert exploit demonstrated by
Sotirov et al in 2008), as this serves as a far more compelling motivation to
get the new algorithms in the field before they're strictly needed.

---------------------------------------------------------------------------

>  RSASHA1 and RSASHA1-NSEC3-SHA1 are widely deployed, although zones
>  deploying it

Nit: "...deploying them..."

[Ballot comment]
Please respond to the Gen-ART review.

In line with Mirja's comment, if the WG or someone in it were planning on maintaining the 4.1 comparison table somewhere less stable than an RFC, that seems like it could be useful and could be linked to from the WG datatracker page.

[Ballot comment]
— Section 1.2 —

  This document only provides recommendations with respect to
  mandatory-to-implement algorithms or algorithms so weak that
  recommendation cannot be recommended.

“...so weak that their use cannot [or perhaps can no longer] be recommended.”

[Ballot comment]
I'm a little surprised that this is going for PS rather than BCP,
which seems like it would reflect the recognized need for recurring
updates to the guidance given.

In a similar vein, if we stay at PS, a lot of the references seem like
they would need to move from Informative to Normative, since to
implement the various MUST-level algorithms you have to follow those
references.

Section 1.1


  The field of cryptography evolves continuously.  New stronger
  algorithms appear and existing algorithms are found to be less secure
  then originally thought.  [...]

I'd suggest also noting that attacks previously thought to be
computationally infeasible become more accessible as the available
computational resources increase.

Section 1.2

                                  For clarification and consistency, an
  algorithm will be specified as MAY in this document only when it has
  been downgraded.

Does "downgraded" mean that it was formerly mandatory but has been
rotated out of the mandatory role?  Perhaps explicitly saying
"downgraded from " would aid clarity.

Section 3.3


  SHA-384 shares the same properties as SHA-256, but offers a modest
  security advantage over SHA-384 (384-bits of strength versus

nit: SHA-384 has an advantage over ... SHA-384?

  recommended for DS and CDS records.  While it is unlikely for a
  DNSSEC use case requiring 384-bit security strength to arise, SHA-384
  is provided for such applications and it MAY be used for generating
  DS and CDS records in these cases.

My understanding is that generally we refer to SHA-384 as providing
192-bit security, though of course that's a vague/generic statement and
more specific ones are possible.

Section 8

  We wish to thank Michael Sinatra, Roland van Rijswijk-Deij, Olafur
  Gudmundsson, Paul Hoffman and Evan Hunt for their imminent feedback.

IIRC a directorate reviewer noted that "imminent" means "expected to
arrive in the near future but not yet present"; such text does not seem
appropriate for final publication since review after that point would
not be helpful.

[Ballot comment]
I wonder if it makes sense to keep section "4.1.  DNSKEY Algorithms" with the table in the document. Of course this is only a current snapshot but probably gives readers also in future a good indication with tools to look at.

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

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

While it is the case that the IANA Functions Operator understands that upon approval of this document, there are no IANA Actions that need completion, IANA does have a question about the requirement level tables in the current document.

IANA Question --> Are the requirements tables in Sections 3.1 and 3.3 of the current draft candidates for a registry on the IANA Protocol Registry pages located at https://www.iana.org/protocols ?

The IANA Functions Operator requests that the IANA Considerations section of the document remain in place upon publication.

Thank you,

Amanda Baber
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-02-27):

From: The IESG
To: IETF-Announce
CC: tjw.ietf@gmail.com, dnsop-chairs@ietf.org, dnsop@ietf.org, Tim Wicinski , draft-ietf-dnsop-algorithm-update@ietf.org, warren@kumari.net
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Algorithm Implementation Requirements and Usage Guidance for DNSSEC) to Proposed Standard


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'Algorithm Implementation
Requirements and Usage Guidance for DNSSEC'
  as Proposed Standard

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
ietf@ietf.org mailing lists by 2019-02-27. 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


  The DNSSEC protocol makes use of various cryptographic algorithms in
  order to provide authentication of DNS data and proof of non-
  existence.  To ensure interoperability between DNS resolvers and DNS
  authoritative servers, it is necessary to specify a set of algorithm
  implementation requirements and usage guidelines to ensure that there
  is at least one algorithm that all implementations support.  This
  document defines the current algorithm implementation requirements
  and usage guidance for DNSSEC.  This document obsoletes [RFC6944].




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update/ballot/


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

draft-ietf-dnsop-algorithm-update

(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?

RFC is Standards Track, which is listed and we feel is correct.

Technical Summary

  The DNSSEC protocol makes use of various cryptographic algorithms in
  order to provide authentication of DNS data and proof of non-
  existence.  To ensure interoperability between DNS resolvers and DNS
  authoritative servers, it is necessary to specify a set of algorithm
  implementation requirements and usage guidelines to ensure that there
  is at least one algorithm that all implementations support.  This
  document defines the current algorithm implementation requirements
  and usage guidance for DNSSEC.  This document obsoletes

Working Group Summary

The Working Group did not have any controvesery on this document.
There was discussion around the 2119 Normative terms as this draft
uses RECOMMENDED/NOT RECOMMENDED instead of SHOULD/SHOULD NOT.
This did not cause any probelms gaining consensus

Document Quality

Document is very concise and informative as it updates the
list of recommendations for DNSKEY algorithms.

Personnel

  Document Shepherd? Tim Wicinski
  Responsible Area Director?  Warren Kumari

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

Document Shepherd performed a review for content as well as editorial
review, and found the document ready for publication. 

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No Concerns.

(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 additional Reviews

(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? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No Issues

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

(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? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Consensus is solid

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise 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 threatened

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

The abstract references RFC6944, but also includes a reference, which it
should not. Also, 'NOT RECOMMENDED' is not in the list of 2119 key words
though it is used.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal reviews

(13) Have all references within this document been identified as
either normative or informative?

All references have been identified.

(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?

No

(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

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

This draft will obsolete 6944

(17) 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 protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No IANA considerations

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

draft-ietf-dnsop-algorithm-update

(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?

RFC is Standards Track, which is listed and we feel is correct.

(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

  The DNSSEC protocol makes use of various cryptographic algorithms in
  order to provide authentication of DNS data and proof of non-
  existence.  To ensure interoperability between DNS resolvers and DNS
  authoritative servers, it is necessary to specify a set of algorithm
  implementation requirements and usage guidelines to ensure that there
  is at least one algorithm that all implementations support.  This
  document defines the current algorithm implementation requirements
  and usage guidance for DNSSEC.  This document obsoletes

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

Personnel

  Document Shepherd? Tim Wicinski
  Responsible Area Director?  Warren Kumari

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

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No Concerns.

(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 additional Reviews

(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? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No Issues

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

(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? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Consensus is solid

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise 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 threatened

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No outstanding Nits

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal reviews

(13) Have all references within this document been identified as
either normative or informative?

All references have been identified.

(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?

No

(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

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

This draft will obsolete 6944

(17) 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 protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No IANA considerations

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

draft-ietf-dnsop-algorithm-update

(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?

RFC is Standards Track, which is listed and we feel is correct.

(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

  The DNSSEC protocol makes use of various cryptographic algorithms in
  order to provide authentication of DNS data and proof of non-
  existence.  To ensure interoperability between DNS resolvers and DNS
  authoritative servers, it is necessary to specify a set of algorithm
  implementation requirements and usage guidelines to ensure that there
  is at least one algorithm that all implementations support.  This
  document defines the current algorithm implementation requirements
  and usage guidance for DNSSEC.  This document obsoletes

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

Personnel

  Document Shepherd? Tim Wicinski
  Responsible Area Director?  Warren Kumari

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

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No Concerns.

(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 additional Reviews

(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? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No Issues

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

(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? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Consensus is solid

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise 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 threatened

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No outstanding Nits

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal reviews

(13) Have all references within this document been identified as
either normative or informative?

All references have been identified.

(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?

No

(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

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

This draft will obsolete 6944

(17) 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 protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No IANA considerations

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