Area Proxy for IS-IS
draft-ietf-lsr-isis-area-proxy-12

[Ballot discuss]
** Section 4.3.  Do all the candidates need the Area Proxy System Identifier TLVs need the same system identifier?

-- Section 4.2 says “For consistency, all Area Leader candidates SHOULD be configured with the same Proxy System ID, Proxy Hostname, and any other information that may be inserted into the Proxy LSP.”

-- Section 4.3.1 says: “All candidates advertising the Area Proxy System Identifier TLV MUST be advertising the same system identifier.”

The first statement suggests that consistency might not always be required, but the second statement is clear that it always must be the same identifier.

Per our discussion on https://mailarchive.ietf.org/arch/msg/lsr/HbpEgfX4p7rSMr490kylMyy5pFA, I believe the agreed resolution is to s/MUST/SHOULD/ in Section 4.3.1.

[Ballot comment]
Thank you to Alexey Melnikov for the SECDIR review.

** Section 8.

8.  Security Considerations

  This document introduces no new security issues.  Security of routing
  within a domain is already addressed as part of the routing protocols
  themselves.  This document proposes no changes to those security
  architectures.

-- What are the relevant pointers to IS-IS security considerations?

Per https://mailarchive.ietf.org/arch/msg/lsr/HbpEgfX4p7rSMr490kylMyy5pFA/, please consider adding references to RFC 5304 and 5310.

[Ballot comment]
Section 7 creates a registry whose policy is partly Expert Review, but doesn't give any particular guidance to the Designated Experts about what qualifying criteria might be.  Are there any that should be included?  I also suggest removing the names of proposed designated experts; that's appropriate for the shepherd writeup or an email and doesn't need to be in the document directly.

The SHOULD in Section 4.2 is bare.  When might an implementer or operator deviate from that advice?  If there's no legitimate condition, maybe it should be a MUST, or if it really doesn't matter, a MAY.

I actually have the same question about most of the 30+ SHOULDs in this document.  I wasn't able to tell just from the text in many cases what damage to interoperability I might trigger if I deviate from the advice.  And in the aggregate, as an implementer, I could do none of them and still claim I'm implementing this specification.  Is that intentional?

[Ballot discuss]
I have a few minor discusses, which could be just because I'm not an ISIS expert. Please bear with me :)

        Multiple proxy system identifiers in a single area is a misconfiguration and each unique occurrence SHOULD be logged.

This does not really answer what systems should do in this case? Use none
of them? What would the implication be? Use the one advertised by most nodes?
What would the risk be with that? The answers would be great additions to the
Security Considerations :)

        The Area Leader and other candidates for Area Leader MAY withdraw
        the Area Proxy System Identifier when one or more Inside Routers
        are not advertising the Area Proxy Router Capability. This will
        disable Area Proxy functionality.

Wouldn't this allow a malicious Inside Router to completely disable the Area Proxy
functionality? Could this be part of an attack? Can this be mitigated somehow? Is
there something to say about this for the Security Considerations?




    0                  1                  2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |      Type    |    Length    |        Proxy System ID        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              Proxy System Identifier continued              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This diagram seems incorrect. It shows 4 fields instead of 3.
I suggest using:


    0                  1                  2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |      Type    |    Length    |                              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    Proxy System Identifier  |
  |                                                              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

[Ballot discuss]
** Section 4.3.  Do all the candidates need the Area Proxy System Identifier TLVs need the same system identifier?

-- Section 4.2 says “For consistency, all Area Leader candidates SHOULD be configured with the same Proxy System ID, Proxy Hostname, and any other information that may be inserted into the Proxy LSP.”

-- Section 4.3.1 says: “All candidates advertising the Area Proxy System Identifier TLV MUST be advertising the same system identifier.”

The first statement suggests that consistency might not always be required, but the second statement is clear that it always must be the same identifier.

** Section 8.  The following statement doesn’t appear to be accurate.

8.  Security Considerations

  This document introduces no new security issues.  Security of routing
  within a domain is already addressed as part of the routing protocols
  themselves.  This document proposes no changes to those security
  architectures.

-- Aren’t a few the filtering activities described in Section 5.2 security-related?

-- What are the relevant pointers to IS-IS security considerations?

[Ballot comment]
Thank you to Alexey Melnikov for the SECDIR review.

** Section 4.3.1
  However, before withdrawing the Area Proxy
  System Identifier, an implementation SHOULD protect against
  unnecessary churn from transients by delaying the withdrawal.  The
  amount of delay is implementation-dependent.

Are there any guidelines on how the delay period should be computed?

** Section 4.4.4.
  An entry for a neighbor in both the IS Neighbors TLV and the Extended
  IS Neighbors would be functionally redundant, so the Area Leader
  SHOULD NOT do this.

Under what circumstances would this advice be ignored (i.e., why not a MUST)?

** Section 4.4.5 and 4.4.6 describe various behavior where fields “SHOULD” be copied.  What governs the choice of not copying these fields?  Would operators be impacted in troubleshooting or even operations if different implementations applied this advice differently?  Would it be up to local configuration?
Later sections in 4.4.* also have “SHOULD” behavior as well where the reason for not following the behavior is not clear.

[Ballot comment]
Hi,

Thanks for this document.

I'm not a routing expert, but it does feel that this is somewhat pushing IS-IS beyond its core competency.  However, this is obviously just an experimental draft and may be a pragmatic engineering solution to the problem, hence the no obj ballot.

Regards,
Rob

Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Peter Yee. Sent review to list. Submission of review completed at an earlier date.

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

IANA has completed its review of draft-ietf-lsr-isis-area-proxy-10. If any part of this review is inaccurate, please let us know.

IANA has questions about both of the actions requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are two actions which we must complete.

First, in the IS-IS Top-Level TLV Codepoints registry in the IS-IS TLV Codepoints registry group located at:

https://www.iana.org/assignments/isis-tlv-codepoints/

the existing temporary registration for value 20:

Name: Area Proxy
IIH: n
LSP: y
SNP: n
Purge: n

will be made permanent and its reference changed to [ RFC-to-be ].

IANA Question -> The current temporary registration is listed as "Area Proxy"; should we update this to "Area Proxy TLV", as listed in the current I-D?

Second, a new registry is to be created called the Sub-TLVs for TLV 20 (Area Proxy TLV).

This new registry is to be located in the IS-IS TLV Codepoints registry group located at:

https://www.iana.org/assignments/isis-tlv-codepoints/

The registration policy for the new registry is RFC Required and Expert Review.

IANA Question --> The proposed registry name is "Sub-TLVs for TLV 20 (Area Proxy TLV)." A couple of years ago, the IS-IS experts (with AD approval) changed all of the registry names that were formatted in this way and added a "Description" field for the registry itself that provided the numeric value(s) for the TLVs or sub-TLVs the registry applied to. Could the authors check with the experts (particularly Les Ginsberg) and ask whether this registry should be renamed and have a description field added to conform with the other registries in the IS-IS TLV Codepoints registry group?

There are initial registrations in the new registry as follows:

Value Name Reference
-----+-----+-----------
1 Area Proxy System Identifier [ RFC-to-be ]
2 Area SID [ RFC-to-be ]

IANA Question --> Is the value 0 unassigned or reserved?

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

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

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2023-12-22):

From: The IESG
To: IETF-Announce
CC: Christian Hopps , chopps@chopps.org, draft-ietf-lsr-isis-area-proxy@ietf.org, jgs@juniper.net, lsr-chairs@ietf.org, lsr@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Area Proxy for IS-IS) to Experimental RFC


The IESG has received a request from the Link State Routing WG (lsr) to
consider the following document: - 'Area Proxy for IS-IS'
  as Experimental RFC

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 2023-12-22. 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


  Link state routing protocols have hierarchical abstraction already
  built into them.  However, when lower levels are used for transit,
  they must expose their internal topologies to each other, leading to
  scale issues.

  To avoid this, this document discusses extensions to the IS-IS
  routing protocol that allow level 1 areas to provide transit, yet
  only inject an abstraction of the level 1 topology into level 2.
  Each level 1 area is represented as a single level 2 node, thereby
  enabling greater scale.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/4016/
  https://datatracker.ietf.org/ipr/3357/
  https://datatracker.ietf.org/ipr/3221/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

    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?

A broad agreement in the WG.

    2. Was there controversy about particular points, or were there decisions
      where the consensus was particularly rough?

No controversy.

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

There is one known shipped implementation. It has not been reported per RFC7942
or elsewhere officially.

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

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 extra 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][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]?

No YANG.

    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.

N/A.

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

N/A.

    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?

Experimental. The WG and authors agreed that this document should begin on the
experimental track.

    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.

Yes.

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

References need to be updated during LC process.

    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?

The base IS-IS specification is an ISO standard.

    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.

No.

    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?

No.

    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.

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

The shepherd has reviewed

    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.

    [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/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

    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?

    2. Was there controversy about particular points, or were there decisions
      where the consensus was particularly rough?

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

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

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

    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.

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

    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.

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

    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?

    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?

    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.

    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.

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

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

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

    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.

    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?

    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.

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

    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.

    [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/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

    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?

    2. Was there controversy about particular points, or were there decisions
      where the consensus was particularly rough?

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

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

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

    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.

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

    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.

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

    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?

    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?

    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.

    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.

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

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

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

    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.

    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?

    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.

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

    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.

    [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/