The IPv6 Compact Routing Header (CRH)
draft-ietf-6man-comp-rtg-hdr-10

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-6man-comp-rtg-hdr and RFC 9631, changed IESG state to RFC Published)

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-6man-comp-rtg-hdr-09

Thank you for the work put into this document. I do like the idea of compressing SRH-like header. Thanks also for addressing my previous blocking DISCUSS points at:
https://mailarchive.ietf.org/arch/msg/ipv6/a_RdmiI3iYk6Sk6mamrppoLTvnc/

I have kept open non-blocking COMMENT points as I think that they would improve the document, up to the authors and the 6MAN WG of course to decide.

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

Special thanks to Bob Hinden for the shepherd's detailed write-up including the WG consensus *but* it lacks the justification of the intended status (and IMHO experimental is the right one).

I hope that this review helps to improve the document,

Regards,

-éric


# COMMENTS (non-blocking)

## Abstract

Can we really write `deployed` for an experimental I-D?


## Section 3

Any recommendation on when to do `The first CRH SID in the path can be omitted from the list.`?

What is the expected behavior of any CRH-aware router and final node(s) when `the Type- specific data field MUST be padded with zeros` is not respected ?

## Section 5

While wasting octets with too large CRH (i.e., larger than the minimum length) is a bad thing, does it deserve to discard the packet on transit ? Why not requesting the source to enforce this mimimum length?

`If the search does not return a CRH-FIB entry` is the code 0 the most suitable code ? If not, why not creating one ? Or even using ICMPv6 code 1 'destination unreachable' ?

`If Segments Left is greater than 0` this will always be the case per first bullet `If Segments Left equals 0` ;-)


## Section 6

I guess that this is linked to RFC 4302 (AH), so, please state this clearly.

## Section 9

While not a real DISCUSS criteria, I am really surprised to see an IPv4-like notation for CRH SID.

## Section 10

`The Source Address does not identify an interface on a trusted node.` is there any hint how this can be done ? How will it scale if all CRH-enabled router must know all the specific address of all trusted nodes ? The same scalability issue for `The ACL discards packets whose source address identifies an interface on a trusted node.`

## Section 11

If the Wireshark/tcpdump modifications (cited in section 9) are public, then references to code will be welcome.

`Interoperability among these implementations has not yet been demonstrated.` should rather be in section 14 'experimental results'

## Section 14

I am indeed very curious to see the experimental result of
```
Mechanism used to populate the FIB
Scale of deployment
```
even if the text states in one year after publication as an RFC, this work started back in 2019 and was adopted in 2023, do we already have some results ?

What are the possible next steps as seen by the authors / 6MAN WG is the experiment is assumed to be successful ? And what are the criteria to declare a successful experiment ?

# NITS (non-blocking / cosmetic)

## Section 12

s/This is becasue /This is because/

[Ballot discuss]
Thanks for working on this specification.  Special Thanks to Gorry Fairhurst for the TSVART review.

I have one question that I would like to discuss further to understand better -

- In the processing rules, we are seding ICMPv6 Messages so how often are we sending them? if this is not rate limited, what are the risks we are not considering here?

[Ballot discuss]
Thanks to Brian Weis for his multiple SecDir reviews.


        In this document, one node trusts another only if both nodes are operated by the same party.

Is this configured through provisioning that is out of scope? Or is there a
protocol to figure this out? It seems this is based on marking each interface
as "operated by me" or "operated by someone else". If so, why not clearly state
this?

        The CRH is compatible with end-to-end IPv6 Authentication Header
        (AH) [RFC4302] processing. This is becasue the source node MUST
        calculate the Integrity Check Value (ICV) over the packet as it
        arrives at the destination node.

I do not understand this. The source node using AH, as per Appendix A.1:

As the packet travels from S to I2:
Source Address = 2001:db8::a   
Destination Address = 2001:db8::2

So the AH header will be created based on Destination Address 2001:db8::2

As the packet travels from I2 to D:
Source Address = 2001:db8::a
Destination Address = 2001:db8::b

When D receives the packet, Destination Address is now 2001:db8::b, and
thus the AH packet signature will fail (as it should, the packet was modified!)

[Ballot comment]
I don't understand the different syntax used in Fig 1 and 2,
eg the open box and dots. It makes it look like there is
more difference than just the SIDs taking 32 or 64 bits.
Is it trying to explain padding in Fig 1 but not Fig 2?

        PING and TRACEROUTE report 16-bit CRH SIDs for CRH-16, and 32-bit CRH SIDs for CRH-32.

Is this confusing protocols with implementations? Does my
linux ping report this, or the netbsd ping, or the 1995 bebox computer's ping
support this newly defined CRH too?

[Ballot comment]
Access Control Lists (ACLs) are mentioned in the Introduction and in the Security Considerations sections and no where in between.  This draft does not explain/clarify why or how an ACL helps the security posture of this draft. 

I'm making these comments non-blocking because of the way the term 'ACL' is used here.  In the security world, an ACL usually applies to permissions given (or not given) to processes or people to establish access control, or least privilege.  If that is what is intended here, then there needs to be information given on how to construct the ACL.

[Ballot discuss]
I would like to DISCUSS Section 7 of the document as I have a few concerns and question whether the section is even necessary. The relevant text from this section is as follows:

  When a packet containing the CRH header leaves its source, it does
  not include its final destination address.  The final destination
  address is not added to the packet until the final CRH SID is
  resolved.

Jim> This first paragraph just seems to document what routing headers do - the IPv6 destination address of the packet is not the final destination as carried in the last entry in the routing header. Okay, got that but then the text jumps to talk about address transparency but this concept is nothing new in the presence of routing headers. 

  While destination address transparency enhances privacy, it prevents
  intermediate nodes from verifying transport layer checksums.

Jim> Now the text introduces the notion that address transparency somehow enhances privacy - how and why is that relevant? I think you are trying to highlight that because addresses that are not the ultimate destination are carried in the IPv6 destination address, and the routing header may have one or more other addresses (these being the 'transparent' ones), then an intermediate node might have trouble verifying transport layer checksums. If so, why not just say if you use CRH then intermediate nodes may not be able to calculate transport layer checksums unless they are CRH aware?

[Ballot comment]
A few additional comments (I have included line numbers from idnits for the latest version):

18   This document describes an experiment in which two new IPv6 Routing
19   headers are implemented and deployed.  Collectively, they are called
20   the Compact Routing Headers (CRH).  Individually, they are called
21   CRH-16 and CRH-32.

Jim> This first paragraph seems to overlap with the second paragraph with its discussion of implementation and deployment. Perhaps reword it as follows as the second paragraph is clear enough as to the purpose of the experiment.

  This document describes an experiment in which two new IPv6 Routing
  headers are defined; Collectively called the Compact Routing Headers
          (CRH).  Individually, they are called CRH-16 and CRH-32.

89 1.  Introduction

91   IPv6 [RFC8200] source nodes use Routing headers to specify the path
92   that a packet takes to its destination.  The IETF has defined several
93   Routing header types [IANA-RH].  This document defines two new

Jim> [IANA-RH] defines ‘Routing Types’ not ‘Routing header types’. It would be more precise to just say ‘Routing Types’.

107   *  Because Path MTU Discovery (PMTUD) [RFC8201] is not entirely
108       reliable, many IPv6 hosts refrain from sending packets larger than
109       the IPv6 minimum link MTU (i.e., 1280 bytes).  When packets are
110       small, the overhead imposed by large Routing Headers is excessive.

Jim> The above text is making a statement that may or may not be true dependent upon who one talks to ;-) I would suggest to say, ‘large Routing Headers may be excessive’.

207   The topological function specifies how the processing node forwards
208   the packet to the interface identified by the IPv6 address.  The
209   following are examples:

Jim> Is this an exhaustive list? If not, please specify that.

232   The above-mentoned mechanisms are not defined here and are beyond the

Jim> s/above-mentoned/above-mentioned

250   *  If L is greater than Hdr Ext Len, discard the packet and send an
251       ICMPv6 Parameter Problem, Code 0, message to the Source Address,
252       pointing to the Segments Left field.

Jim> Why would the ICMPv6 message point to the Segments Left field? Shouldn’t it point to the Hdr Ext Len field?

332 8.  Applications And SIDs

Jim> s/Applications And SIDs/Applications and SIDs

[Ballot comment]
Thank you to Elwyn Davies for the GENART review.

** Section 12.  The abstract said “another purpose is to demonstrate that the security considerations, described in this document, can be addressed with access control lists.”  Based on the text in this section it isn’t clear what the unknown (requiring an experiment) is around implementing these Security Considerations.

** Section 14.  The nature of the experiment isn’t clear in the following cases:
-- At the highest level, how do we know the experiment was a success?

-- Per “Effort required to secure”, what is the units of this effort?

-- Per “Effectiveness of risk mitigation with ACLs”, how is one expected to answer this question? 

-- Per “Effectiveness and sufficiency of OAM mechanism
      -  Did PING work?
      -  Did TRACEROUTE work?
      -  Did Wireshark work?
      -  Did TCPDUMP work?”

In what way is support in these tools an open-ended question requiring experimentation on a production network?  Can’t one check functionality/support per a given version number of these tools?

[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-6man-comp-rtg-hdr-08

Thank you for the work put into this document. I do like the idea of compressing SRH-like header, but the document has room for improvements.

Please find below some blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Bob Hinden for the shepherd's detailed write-up including the WG consensus *but* it lacks the justification of the intended status (and IMHO experimental is the right one).

I hope that this review helps to improve the document,

Regards,

-éric


# DISCUSS (blocking)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

## Section 5

`Decrement the IPv6 Hop Limit.` what do to when hop limit is 0 ? Is there a deviation from RFC 8200 section 3, else why repeating this step ?

## Section 7

It is not clear to me why this document needs to make an allowance for intermediate nodes (sic) that verify transport layer checksums. Transport layer checksums are expected to be verified by the Transport layer endpoints and not in the network. So since when the Internet architecture has changed to take care of `it prevents intermediate nodes from verifying transport layer checksums`? Actual references are required for such statement. And, explanations should be given whether this "sentence" helps RFC 7258 pervasive monitoring perhaps in the security considerations section.

## Section 11

While not a real DISCUSS criteria, I am really surprised to see an IPv4-like notation for CRH SID.

## Section 12

As AH is end-to-end, intermediate nodes do not have the shared secret, hence `The CRH is not compatibile with AH processing at intermediate nodes.` is useless and confusing. Please remove. Very similar to the DISCUSS about section 7.

[Ballot comment]

# COMMENTS (non-blocking)

## Abstract

Can we really write `deployed` for an experimental I-D?


## Section 1

s/to its destination/to its destination(s)/ (think multicast/anycast). Twice in the section ;)

Suggest to move the motivation to its own section.

## Section 3

Any recommendation on when to do `The first CRH SID in the path can be omitted from the list.`?

What is the expected behavior of any CRH-aware router and final node(s) when `the Type- specific data field MUST be padded with zeros` is not respected ?

## Section 4

Can the IPv6 address in the CRH-FIB be a link-local or multicast or can only be a unicast ? Section 5 gives some more explanations, but an early one would be better.

## Section 5

The first bullet can probably be removed as it is the normal behavior of any IPv6 node per RFC 8200.

`If Hdr Ext Len indicates that the CRH is larger than the implementation can process, ` suggest using code 6 per https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-codes-5

While wasting octets with too large CRH (i.e., larger than the minimum length) is a bad thing, does it deserve to discard the packet on transit ? Why not requesting the source to enforce this mimimum length?

`If the search does not return a CRH-FIB entry` is the code 0 the most suitable code ? If not, why not creating one ? Or even using ICMPv6 code 1 'destination unreachable' ?

`If Segments Left is greater than 0` this will always be the case per first bullet `If Segments Left equals 0` ;-)

The reader will welcome a justification of `CRH-FIB entry contains a multicast address, discard the packet and`.

## Section 6

I guess that this is linked to RFC 4302 (AH), so, please state this clearly.

## Section 7

Is it about `Destination Address Transparency` or privacy ?

## Section 8

`Each CRH SID is processed by exactly one node.` isn't it rather "Each CRH SID is processed by exactly one CRH-configured router whose one address matches the packet destination address" ?

## Section 9

The title should rather be "operational considerations"

What are the "representations described herein" in ` It is recommended that the experimental versions of PING use the text representations described herein` ? Is it about section 11 ? Then please add a forward reference.

## Section 10

This is the usual considerations about ICMP, please consider to remove this section. Or refer for section 5 of RFC 4443.

## Section 11

Beside the above semi-DISCUSS, please state that hexadecimal should be in lower case.

## Section 12

`The Source Address does not identify an interface on a trusted node.` is there any hint how this can be done ? How will it scale if all CRH-enabled router must know all the specific address of all trusted nodes ? The same scalability issue for `The ACL discards packets whose source address identifies an interface on a trusted node.`

## Section 13

If the Wireshark/tcpdump modifications (cited in section 9) are public, then references to code will be welcome.

`Interoperability among these implementations has not yet been demonstrated.` should rather be in section 14 'experimental results'

## Section 14

I am indeed very curious to see the experimental result of
```
Mechanism used to populate the FIB
Scale of deployment
```
even if the text states in one year after publication as an RFC, this work started back in 2019 and was adopted in 2023, do we already have some results ?

What are the possible next steps as seen by the authors / 6MAN WG is the experiment is assumed to be successful ? And what are the criteria to declare a successful experiment ?

# NITS (non-blocking / cosmetic)

## Section 12

s/This is becasue /This is because/

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

IANA has completed its review of draft-ietf-6man-comp-rtg-hdr-05. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there is a single action which we must complete.

In the Routing Types registry in the Internet Protocol Version 6 (IPv6) Parameters registry group located at:

https://www.iana.org/assignments/ipv6-parameters/

two temporary registrations will be made permanent and their references changed to [ RFC-to-be ] as follows:

Value: 5
Description: CRH-16
Reference: [ RFC-to-be ]

Value: 6
Description: CRH-32
Reference: [ RFC-to-be ]

We understand that this is the only action required to be completed upon approval of this document.

NOTE: The action 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 action 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 2024-04-29):

From: The IESG
To: IETF-Announce
CC: 6man-chairs@ietf.org, bob.hinden@gmail.com, draft-ietf-6man-comp-rtg-hdr@ietf.org, ek.ietf@gmail.com, furry13@gmail.com, ipv6@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (The IPv6 Compact Routing Header (CRH)) to Experimental RFC


The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document: - 'The IPv6 Compact Routing Header (CRH)'
  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 2024-04-29. 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


  This document describes an experiment in which two new IPv6 Routing
  headers are implemented and deployed.  Collectively, they are called
  the Compact Routing Headers (CRH).  Individually, they are called
  CRH-16 and CRH-32.

  One purpose of this experiment is to demonstrate that the CRH can be
  implemented and deployed in a production network.  Another purpose is
  to demonstrate that the security considerations, described in this
  document, can be addressed with access control lists.  Finally, this
  document encourages replication of the experiment.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-6man-comp-rtg-hdr/


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

  https://datatracker.ietf.org/ipr/3465/

# Internet AD comments for draft-ietf-6man-comp-rtg-hdr-04
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

## Comments

### S4

* To be clear here, w.r.t. the list of ways by which the CRH-FIB may be
  populated, should this say the these mechanisms are not defined here and
  are out of scope of this document?

### S5

* Is it fair to say, explicitly, at the end of this first bullet:

  "The IPv6 address in the IPv6 Header's Destination Address field is
  that of the ultimate recipient."

  or something?

* With respect to ICMP generation, should there be the usual "subject to
  rate limitations" text (for protecting the router's control plane)?

### S11

* Maybe I just haven't slept enough, but I found the wording of this section
  to be very confusing.

  Why should a packet be dropped if it's destined to an interface on the
  local node?  Shouldn't the processing node (the local node, I presume)
  process packets for it when it's the ultimate destination?

  Is this section meant to be written from the perspective of the first
  encapsulating node, and therefore aimed at describing about the CRH
  administrative domain boundary can be securely enforced?  If so, a few
  clarifying words to that effect would certainly help me.

### S13

* "Did you deploy two inter-operable implementations?" ->
  "Did you deploy two (or more) inter-operable implementations?"

### Appendix A

* These example sections left me with the impression that only loopback
  addresses appear in the CRH-FIB.  Is this true?  I assume not, since
  section 4 refers to "he interface identified by the IPv6 address" (without
  restricting them to loopbacks), but I think my confusion from the security
  section text has got my tiny brain all turned around.

## Nits

### S3

* "See Appendix A an example" ->
  "See Appendix A for an example"

The IPv6 Compact Routing Header (CRH)
draft-ietf-6man-comp-rtg-hdr-04

Document Shephard:  Bob Hinden

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

There was strong support for publishing this document as an Experimental
RFC.  Some questions were raised about open source implementations, but
that wasn't required to be published as an Experimental RFC.

Several issues with the document were identified during the w.g. last
call, these were all resolved in the current version of the document.

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

No, there was a consensus to publish as an Experimental RFC.

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

Current implementations are documented in Section 12. "Implementation and
Deployment Status":

  Juniper Networks has produced experimental implementations of the CRH
  on the MX-series (ASIC-based) router

  Liquid Telecom has produced experimental implementations of the CRH
  on software based routers.

  The CRH has carried non-production traffic in CERNET and Liquid
  Telecom.

Also, given the intended status of Experimental, Section 13 "Experimental
Results" provides topics that experimenters should evaluate.


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

The document describes a new type of IPv6 Routing header.  There were
good reviews in the 6MAN w.g., and several people from the SPRING
w.g. expressed support.

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.

N/A


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

N/A, no Yang model.

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 RFC.  The Datatracker shows this intended status.


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, all of the authors have confirmed IPR requirements.


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, all authors confirmed this.

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

There were a few minor ID nits in the -03 draft , the shepherd asked the authors to fix
them, they are fixed in the -04 draft.

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

References are appropriate.

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

All references are stable and accessable.


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?

All references point to RFCs or other stable document.  No references to IDs.

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.

This does not change the status of any existing RFCs.

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 IANA considerations section makes permanent two temporary assignments Routing
Types that were assinged earlier.

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.

None.

[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://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/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/

The IPv6 Compact Routing Header (CRH)
draft-ietf-6man-comp-rtg-hdr-04

Document Shephard:  Bob Hinden

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

There was strong support for publishing this document as an Experimental
RFC.  Some questions were raised about open source implementations, but
that wasn't required to be published as an Experimental RFC.

Several issues with the document were identified during the w.g. last
call, these were all resolved in the current version of the document.

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

No, there was a consensus to publish as an Experimental RFC.

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

Current implementations are documented in Section 12. "Implementation and
Deployment Status":

  Juniper Networks has produced experimental implementations of the CRH
  on the MX-series (ASIC-based) router

  Liquid Telecom has produced experimental implementations of the CRH
  on software based routers.

  The CRH has carried non-production traffic in CERNET and Liquid
  Telecom.

Also, given the intended status of Experimental, Section 13 "Experimental
Results" provides topics that experimenters should evaluate.


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

The document describes a new type of IPv6 Routing header.  There were
good reviews in the 6MAN w.g., and several people from the SPRING
w.g. expressed support.

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.

N/A


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

N/A, no Yang model.

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 RFC.  The Datatracker shows this intended status.


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, all of the authors have confirmed IPR requirements.


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, all authors confirmed this.

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

There were a few minor ID nits in the -03 draft , the shepherd asked the authors to fix
them, they are fixed in the -04 draft.

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

References are appropriate.

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

All references are stable and accessable.


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?

All references point to RFCs or other stable document.  No references to IDs.

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.

This does not change the status of any existing RFCs.

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 IANA considerations section makes permanent two temporary assignments Routing
Types that were assinged earlier.

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.

None.

[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://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/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/

The IPv6 Compact Routing Header (CRH)
draft-ietf-6man-comp-rtg-hdr-04

Document Shephard:  Bob Hinden

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

There was strong support for publishing this document as an Experimental
RFC.  Some questions were raised about open source implementations, but
that wasn't required to be published as an Experimental RFC.

Several issues with the document were identified during the w.g. last
call, these were all resolved in the current version of the document.

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

No, the consensus was strong.

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

Current implementations are documented in Section 12. "Implementation and
Deployment Status":

  Juniper Networks has produced experimental implementations of the CRH
  on the MX-series (ASIC-based) router

  Liquid Telecom has produced experimental implementations of the CRH
  on software based routers.

  The CRH has carried non-production traffic in CERNET and Liquid
  Telecom.

Also, given the intended status of Experimental, Section 13 "Experimental
Results" provides topics that experimenters should evaluate.


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

The document describes a new type of IPv6 Routing header.  There were
good reviews in the 6MAN w.g., and several people from the SPRING
w.g. expressed support.

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.

N/A


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

N/A, no Yang model.

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 RFC.  The Datatracker shows this intended status.


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, all of the authors have confirmed IPR requirements.


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, all authors confirmed this.

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

There were a few minor ID nits in the -03 draft , the shephard asked the authors to fix
them, they are fixed in the -04 draft.

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

References are appropriate.

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

All references are stable and accessable.


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?

All references point to RFCs or other stable document.  No references to IDs.

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.

This does not change the status of any existing RFCs.

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 IANA considerations makes permeant two temporary assignments Routing
Types.

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.

None.

[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://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/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/

The IPv6 Compact Routing Header (CRH)
draft-ietf-6man-comp-rtg-hdr-04

Document Shephard:  Bob Hinden

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

There was strong support for publishing this document as an Experimental
RFC.  Some questions were raised about open source implementations, but
that wasn't required to be published as an Experimental RFC.

Several issues with the document were identified during the w.g. last
call, these were all resolved in the current version of the document.

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

No, the consensus was strong.

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

Current implementations are documented in Section 12. "Implementation and
Deployment Status":

  Juniper Networks has produced experimental implementations of the CRH
  on the MX-series (ASIC-based) router

  Liquid Telecom has produced experimental implementations of the CRH
  on software based routers.

  The CRH has carried non-production traffic in CERNET and Liquid
  Telecom.

Also, given the intended status of Experimental, Section 13 "Experimental
Results" provides topics that experimenters should evaluate.


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

The document describes a new type of IPv6 Routing header.  There were
good reviews in the 6MAN w.g., and several people from the SPRING
w.g. expressed support.

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.

N/A


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

N/A, no Yang model.

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 RFC.  The Datatracker shows this intended status.


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, all of the authors have confirmed IPR requirements.


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, all authors confirmed this.

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

There were a few minior ID nits in the -03 draft , the shephard asked the authors to fix
them, they are fixed in the -04 draft.

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

References are appropriate.

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

All references are stable and accessable.


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?

All references point to RFCs or other stable document.  No references to IDs.

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.

This does not change the status of any existing RFCs.

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 IANA considerations makes permeant two temporary assignments Routing
Types.

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.

None.

[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://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/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/

The IPv6 Compact Routing Header (CRH)
draft-ietf-6man-comp-rtg-hdr-03

Document Shephard:  Bob Hinden

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

There was strong support for publishing this document as an Experimental
RFC.  Some questions were raised about open source implementations, but
that wasn't required to be published as an Experimental RFC.

Several issues with the document were identified during the w.g. last
call, these were all resolved in the current version of the document.

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

No, the consensus was strong.

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

Current implementations are documented in Section 12. "Implementation and
Deployment Status":

  Juniper Networks has produced experimental implementations of the CRH
  on the MX-series (ASIC-based) router

  Liquid Telecom has produced experimental implementations of the CRH
  on software based routers.

  The CRH has carried non-production traffic in CERNET and Liquid
  Telecom.

Also, given the intended status of Experimental, Section 13 "Experimental
Results" provides topics that experimenters should evaluate.


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

The document describes a new type of IPv6 Routing header.  There were
good reviews in the 6MAN w.g., and several people from the SPRING
w.g. expressed support.

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.

N/A


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

N/A, no Yang model.

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 RFC.  The Datatracker shows this intended status.


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, all of the authors have confirmed IPR requirements.


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, all authors confirmed this.

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

A few minior ID nits were found, the shephard asked the authors to fix
them.

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

References are appropriate.

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

All references are stable and accessable.


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?

All references point to RFCs or other stable document.  No references to IDs.

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.

This does not change the status of any existing RFCs.

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 IANA considerations makes permeant two temporary assignments Routing
Types.

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.

None.

[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://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/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/