OSPFv3 Extensions for Segment Routing over IPv6 (SRv6)
draft-ietf-lsr-ospfv3-srv6-extensions-15

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-lsr-ospfv3-srv6-extensions-14

Thank you for the work put into this document. Sorry for belated ballot, as Roman cleared his DISCUSS, I just noticed today that there is one ballot missing: here it is ;-)

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

Special thanks to Acee Lindem for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS

## SRv6 or Network Programming

The name of the document and its abstract refer to SRv6 while it is rather for network programming (RFC 8986).

## Section 5

`Locators associated with algorithms 0 and 1`, I must admit that I am not familiar with OSPF/network programming, but is the reader expected to know what are "algorithms 0 and 1" ? Some short explanations are probably welcome.

## Section 6

Bits in a flag field are more often specified by their position, bit 0, rather than by their value, 0x80. But, this is a matter of taste. The same inconsistency happens in sections 13.3 (using a value) and 13.4 (using a bit position) in the IANA section.

## Section 7.1

Should the obvious be stated for the Locator field ? I.e., this field should be the shortest as possible with unused bits set to 0 ?

## Section 8

`Every SRv6-enabled OSPFv3 router SHOULD advertise` as it is not a MUST, in which case a router may deviate from the SHOULD behavior ?

[Ballot comment]
Thanks to Ketan for the constructive discussion and changes. I've updated my ballot to No Objection.
I do hope the WG will consider properly replacing or updating RFC5340, but that is not this document's problem.

NIT: IPSec -> IPsec  (no need for new draft, it can be fixed during the RFC editing cycle)

[Ballot discuss]
Hi There,

Firstly thanks for the document. 

I'd like to have a discussion about the following text in Section 7.1.

If the SRv6 Locator TLV for
  the same Locator appears in multiple SRv6 Locator LSAs that have the
  same flooding scope, the TLV in the SRv6 Locator LSA with the
  numerically smallest Link-State ID MUST be used and subsequent
  instances of the TLV MUST be ignored.

My question may be as a result of not quite understanding the nature of End.X SID's - and as such, this may be easy to resolve.  But - Reading the document, you have a limit of the size of an OSPFv3 packet of 65535 bytes (with fragmentation - which I would argue you probably don't wanna rely on).  Now, if you are stacking END.X sub-TLV's beneath a locator SID - and you require more than 4000 of them on a large device (though in reality its probably far less than this because of overhead etc - if you avoid fragmentation even on a large MTU network you're at under 500) you're going to run into a problem because you cannot split the announcement by using the same locator in subsequent LSA's (my understanding is that normally this would be accomplished by having the same locator in multiple LSA's with different LS ID's, that the router would then combine).

So - the question is - under what scenarios are END.X and END sub tlv's added to the packet and advertised - and could we run into a major length problem here on large dense devices that are, for example, terminating huge numbers of cross connects.  Further to this, is there a reason why the locator cannot be split across multiple packets with different Link State ID's to reduce the size of the OSPF packets if this does become necessary?

(I do realise that you could use multiple locators on the same router to split this up - but would argue thats going to create operational nightmares and lead to potentially big problems with admins having to figure out when they are going to hit the limit)

[Ballot comment]
Thanks for the specification.

I have one question that I would like to get a response to as I believe it will add clarity in the specification. I says -

    Sub-TLVs SHOULD be rate-limited to prevent a Denial of Service (DoS) attack (distributed or otherwise) from overloading the OSPFv3 control plane.

Is there a description on the rate-limitation that can be referenced here so that we understand it better?

[Ballot discuss]
I have a DISCUSS similar to Roman:

Existing security extensions as described in [RFC5340] and [RFC8362] apply to these SRv6 extensions. While OSPFv3 is under a single administrative domain, there can be deployments where potential attackers have access to one or more networks in the OSPFv3 routing domain. In these deployments, stronger authentication mechanisms such as those specified in [RFC4552] or [RFC7166] SHOULD be used.

RFC5340 does say to use IPsec, but because of the "group" setting, IKE could not be used (I guess it pre-dates or didn't want to use Group DOI (GDOI) RFC3547 and Group Secure Association Key Management Protocol (GSAKMP) RFC4535). But RFC 4552 is recommending IPsec with manual keying, which is no longer really possible with AEAD ciphers (eg AES-GCM, which you would want to use for performance). It does state:

  Future specifications can explore the usage of protocols like
  Kerberized Internet Negotiation of Keys/Group Secure Association Key
  Management Protocol (KINK/GSAKMP) when they are widely available.

But I don't think KINK/GSAKMP became widely available. GDOI has seen some but not much implementation.

Furthermore, RFC4535 is also a (not widely implemented) IKEv1 extension. This cannot be recommended anymore because IKEv1 itself is obsolete (see RFC9395)

Updated advise would be to use draft-ietf-ipsecme-g-ikev2 "Group Key Management using IKEv2, but again we don't know yet if this will be widely available. That puts us back at "use manual keying or this soon to hopefully be available IKEv2 RFC", except that with AEADs, we also cannot recommend manual keying anymore.

I am not sure what to recommend as text here. Removing all IKEv1 references and putting draft-ietf-ipsecme-g-ikev2 there and saying manual keying MUST NOT be used is not a good security recommendation either.

[Ballot discuss]
** Section 12.

  While OSPFv3 is under a single
  administrative domain, there can be deployments where potential
  attackers have access to one or more networks in the OSPFv3 routing
  domain.  In these deployments, stronger authentication mechanisms
  such as those specified in [RFC4552] or [RFC7166] SHOULD be used.

Please rewrite this guidance.  It appears to be saying that in networks with potential attackers stronger authentication mechanisms SHOULD be used.  With the use of the language of "_potential attacker" and "_one_ or more",  isn’t that all networks?  Is this equivalent to strong auth SHOULD be used?

[Ballot comment]
** Section 12. This document cites the applicability of RFC8362’s Security Considerations whose primary guidance appears to be:

  If there were ever a requirement to digitally sign OSPFv3 LSAs as
  described for OSPFv2 LSAs in RFC 2154 [OSPF-DIGITAL-SIGNATURE], the
  mechanisms described herein would greatly simplify the extension.

Is the signature mechanism in RFC2154 still considered viable and needed?  I note that it was published with experimental status in 1997 and supports only one signature-hash mechanism, RSA-MD5, despite having seemingly robust extensibility mechanisms via https://www.iana.org/assignments/ospf-sig-alg/ospf-sig-alg.xhtml.

[Ballot comment]
- Section 1 Introduction:

    - Second paragraph last sentence reads 'SRv6 refers to this SR instantiation on the IPv6 dataplane.' This sentence does not make much sense. Suggest change to 'An SR instantiation on the IPv6 dataplane is
      referred to as SRv6' or something along those lines.

    - Fourth paragraph reads 'This document specifies OSPFv3 extensions to support SRv6 as defined in [RFC8986].' This statement is not accurate as RFC 8986 does not define SRv6 but rather it defines SRv6
      network programming. Note further that the document provides extensions to support SRH, network programming and the O-bit so perhaps this sentence should read 'This document specifies OSPFv3 extensions
      to support SRv6 capabilities as defined in [RFC8986][RFC8754] and [RFC9259]'.

    - The text refers to 'algorithm-specific SIDs' - what are these exactly? there is no definition for this term, and I have not seen it in any other SRv6-related document. Is this a reference to the SR-
      Algorithm TLV?
   
- Section 2 SRv6 Capabilities TLV:

    - This section refers to 'LSA ID' which is not a defined term anywhere that I can find. The OSPFv3 Router Information LSA uses 'Link State ID (Instance ID)' so please correct the last sentence of the second
      paragraph to replace 'LSA ID' with 'Link State ID (Instance ID)'.

- Section 7.1 SRv6 Locator TLV:

    - The text 'Locator continued..' in Figure 5 might be confusing as perhaps it is just me but when I initially read it, I thought that multiple Locators could be carried in the TLV. This is not the case of
      course. It would be easier on the eyes if the entire 'Locator' field of Figure 5 were just a single block of 128-bits. Same comment for Figures 6, 7, and 8.

    - The 'Locator Length' field indicates the number of Locator bits used in the 'Locator' field. This will almost certainly be less than 128-bits. Should the unused bits in the 'Locator' field be set to 0?
      please specify as currently, the text is silent.

[Ballot comment]
I just realized that the document talks about "LSA ID" and as far as I can tell, this is not a term that is defined in the OSPF document set. If it is a well-defined term, can you please point me to what RFC defines it? Right now, it looks to me as though you should be talking about 'Link State ID (Instance ID)' for consistency with RFC 7770 §2.2.

[Ballot comment]
- Section 1 Introduction:
    - Second paragraph last sentence reads 'SRv6 refers to this SR instantiation on the IPv6 dataplane.' This sentence does not make much sense. Suggest change to 'An SR instantiation on the IPv6 dataplane is
      referred to as SRv6' or something along those lines.
    - Fourth paragraph reads 'This document specifies OSPFv3 extensions to support SRv6 as defined in [RFC8986].' This statement is not accurate as RFC 8986 does not define SRv6 but rather it defines SRv6
      network programming. Note further that the document provides extensions to support SRH, network programming and the O-bit so perhaps this sentence should read 'This document specifies OSPFv3 extensions to
      support SRv6 capabilities as defined in [RFC8986][RFC8754] and [RFC9259]'.
    - The text refers to 'algorithm-specific SIDs' - what are these exactly? there is no definition for this term, and I have not seen it in any other SRv6-related document. Is this a reference to the SR-
      Algorithm TLV?

- Section 2 SRv6 Capabilities TLV:

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

The IANA Functions Operator has completed its review of draft-ietf-lsr-ospfv3-srv6-extensions-11. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are ten actions which we must complete.

First, in the OSPF Router Information (RI) TLVs registry on the Open Shortest Path First (OSPF) Parameters registry page located at:

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

the temporary registration for Value 20 will be made permanent and its reference will be changed to [ RFC-to-be ].

Value: 20
TLV-Name: SRv6-Capabilities TLV
Reference: [ RFC-to-be; Section 2 ]

Second, in the OSPFv3 LSA Function Codes registry on the Open Shortest Path First v3 (OSPFv3) Parameters registry page located at:

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

the temporary registration for Value 42 will be made permanent and its reference will be changed to [ RFC-to-be ].

Value: 42
LSA Function Code Name: SRv6 Locator LSA
Reference: [ RFC-to-be; Section 7 ]

Third, in the OSPFv3 Prefix Options (8 bits) registry on the Open Shortest Path First v3 (OSPFv3) Parameters registry page located at:

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

the temporary registration for Value 0x80 will be made permanent and its reference will be changed to [ RFC-to-be ].

Value: 0x80
Description: AC-bit
Reference: [ RFC-to-be; Section 6 ]

Fourth, a new registry is to be created called the OSPFV3 SRv6 Capabilities TLV Flags registry. The new registry is to be located on the Open Shortest Path First v3 (OSPFv3) Parameters registry page located at:

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

The registration procedure for the new registry is Standards Action as defined by RFC8126. There is a single initial registration in the new registry:

Bit: 1
Description: O-flag
Reference: [ RFC-to-be; Section 2 ]

Fifth, a new registry is to be created called the OSPFv3 SRv6 End SID Sub-TLV Flags registry. The new registry is to be located on the Open Shortest Path First v3 (OSPFv3) Parameters registry page located at:

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

The registration procedure for the new registry is Standards Action as defined by RFC8126. The registry will contain registrations for eight bits for the Flags field of the OSPFv3 SRv6 End SID Sub-TLV. There are no initial registrations in the new registry.

Sixth, a new registry is to be created called the OSPFv3 SRv6 Adjacency SID Sub-TLV Flags registry. The new registry is to be located on the Open Shortest Path First v3 (OSPFv3) Parameters registry page located at:

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

The registration procedure for the new registry is Standards Action as defined by RFC8126. The registry will contain registrations for eight bits for the Flags field of the OSPFv3 SRv6 End.X SID and OSPFv3 SRv6 LAN End.X SID Sub-TLVs. There are three initial registrations in the new registry:

Bit: 0
Description: B-Flag
Reference: [ RFC-to-be; Sections 9.1 and 9.2 ]

Bit: 1
Description: S-Flag
Reference: [ RFC-to-be; Sections 9.1 and 9.2 ]

Bit: 2
Description: P-Flag
Reference: [ RFC-to-be; Sections 9.1 and 9.2 ]

Seventh, in the OSPFv3 Extended-LSA Sub-TLVs registry on the on the Open Shortest Path First v3 (OSPFv3) Parameters registry page located at:

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

three temporary registrations for will be made permanent and their references will be changed to [ RFC-to-be ]. These are:

Value: 30
Description: SRv6 SID Structure Sub-TLV
L2BM: Y
Reference: [ RFC-to-be; Section 10 ]

Value: 31
Description: SRv6 End.X SID Sub-TLV
L2BM: Y
Reference: [ RFC-to-be; Section 9.1 ]

Value: 32
Description: SRv6 LAN End.X SID Sub-TLV
L2BM: Y
Reference: [ RFC-to-be; Section 9.2 ]

Eighth, a new registry is to be created called the OSPFv3 SRv6 Locator LSA TLVs registry. The new registry is to be located on the Open Shortest Path First v3 (OSPFv3) Parameters registry page located at:

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

The registration procedure for the new registry is as follows:

Types 2-32767: IETF Review or IESG Approval
Types 32768-33023: Experimental Use
Types 33024-45055: First Come, First Served
Types 45056-65535: Reserved

There are two initial registrations in the new registry as follows:

Type: 0
Description: Reserved
Reference: [ RFC-to-be ]

Type: 1
Description: SRv6 Locator TLV
Reference: [ RFC-to-be; Section 7.1 ]

Ninth, a new registry is to be created called the OSPFv3 SRv6 Locator LSA Sub-TLVs registry. The new registry is to be located on the Open Shortest Path First v3 (OSPFv3) Parameters registry page located at:

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

A note will be added to the new registry as follows:

Note: Allocations made under this registry for any sub-TLVs that are associated with OSPFv3 SRv6 Locator TLVs MUST be also evaluated for their applicability as OSPFv3 Extended-LSA Sub-TLVs and, therefore, also requiring allocation under the "OSPFv3 Extended-LSA Sub-TLVs" registry.

The registration procedure for the new registry is as follows:

Types 6-9, 11-32767: IETF Review or IESG Approval
Types 32768-33023: Experimental Use
Types 33024-45055: First Come, First Served
Types 45056-65535: Reserved

There are seven initial registration in the new registry as follows:

Type: 0
Description: Reserved
Reference: [ RFC-to-be ]

Type: 1
Description: SRv6 End SID Sub-TLV
Reference: [ RFC-to-be; Section 8 ]

Type: 2
Description: IPv6-Forwarding-Address sub-TLV
Reference: [RFC8362][ RFC-to-be; Section 7.2 ]

Type: 3
Description: Route-Tag sub-TLV
Reference: [RFC8362][ RFC-to-be; Section 7.2 ]

Type: 4
Description: Prefix Source OSPF Router-ID sub-TLV
Reference: [RFC9084][ RFC-to-be; Section 7.2 ]

Type: 5
Description: Prefix Source Router Address sub-TLV
Reference: [RFC9084][ RFC-to-be; Section 7.2 ]

Type: 10
Description: SRv6 SID Structure Sub-TLV
Reference: [ RFC-to-be; Section 10 ]

Tenth, in the OSPFv3 Extended-LSA Sub-TLVs registry on the on the Open Shortest Path First v3 (OSPFv3) Parameters registry page located at:

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

a new note will be added to the registry with the intent to help ensure that any document requesting allocations under this registry for sub-TLVs of any of the OSPFv3 Extended Prefix TLVs checks if allocations are also applicable for the "OSPFv3 SRv6 Locator LSA Sub-TLVs" registry that is created by this document.

That note is as follows:

Note: Allocations made under this registry for any sub-TLVs that are associated with OSPFv3 Extended TLVs related to prefix advertisements MUST be also evaluated for their applicability as OSPFv3 SRv6 Locator Sub-TLVs and, therefore, also requiring allocation under the "OSPFv3 SRv6 Locator LSA Sub-TLVs" registry.

The IANA Functions Operator understands 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 Specialist

The following Last Call announcement was sent out (ends 2023-05-15):

From: The IESG
To: IETF-Announce
CC: acee@cisco.com, draft-ietf-lsr-ospfv3-srv6-extensions@ietf.org, jgs@juniper.net, lsr-chairs@ietf.org, lsr@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (OSPFv3 Extensions for SRv6) to Proposed Standard


The IESG has received a request from the Link State Routing WG (lsr) to
consider the following document: - 'OSPFv3 Extensions for SRv6'
  as Proposed Standard

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

Abstract


  The Segment Routing (SR) architecture allows a flexible definition of
  the end-to-end path by encoding it as a sequence of topological
  elements called segments.  It can be implemented over an MPLS or IPv6
  data plane.  This document describes the OSPFv3 extensions required
  to support Segment Routing over the IPv6 data plane (SRv6).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/


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

  https://datatracker.ietf.org/ipr/5785/
  https://datatracker.ietf.org/ipr/3980/

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?

  This document had broader consensus than most OSPFv3 documents with actual
  implementors from Huawei, Cisco, Juniper, Nokia, and Arrcus reviewing the
  draft or contributing to the updates during the last call period. As always,
  it would be better if there were earliar reviews and discussions.

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

  There was no real controversy although there was discussion as to whether it
  was a good idea to have a separate Link State Advertisements (LSAs) for the
  SRv6 Locators as opposed to using the existing LSAs. Unlike IS-IS, one of
  the advantages of OSPFv3 is that disjoint information can be advertised in
  separate LSAs.

  Review by OSPFv3 implementors revealed that the OSPFv3 PrefixOptions needed
  to be advertised in the SRV6 Locator TLV. This specification adds the AC-Bit
  (AnyCast Bit) which is applicable to all usages of the OSPFv3 PrefixOptions.

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 a Huawei implemenation underway but it has not been released yet and
  there is no report.

## 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 SPRING WG has been notified.

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.

  A Routing Directorate Review is in progress.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

  Not Applicable.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

  Not Appliable.

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

    Not Applicable.


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?

    Proposed Standard. This is appropriate given that the document specifies
    the protocol encodings required for interoperable SRv6 operation.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][8]? 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. Only four authors. Dean Cheng was removed as an author due to his
    retirement and disengagement from the IETF.

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

    No nits.

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

    No. All references are properly categorized.

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

    Not Applicable.

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?

    None.

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

    No changes to other documents.

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 review has been done at each phase and the codepoints have
    been allocated through the early allocation process. An additional
    request has been made to add the AC-Bit to the OSPFv3 PrefixOptions
    registry.

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.

    Assignments to the two new registries are made through IETF Review or
    IESG Approval [RFC 8126].

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?

  This document had broader consensus than most OSPFv3 documents with actual
  implementors from Huawei, Cisco, Juniper, Nokia, and Arrcus reviewing the
  draft or contributing to the updates during the last call period. As always,
  it would be better if there were earliar reviews and discussions.

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

  There was no real controversy although there was discussion as to whether it
  was a good idea to have a separate Link State Advertisements (LSAs) for the
  SRv6 Locators as opposed to using the existing LSAs. Unlike IS-IS, one of
  the advantages of OSPFv3 is that disjoint information can be advertised in
  separate LSAs.

  Review by OSPFv3 implementors revealed that the OSPFv3 PrefixOptions needed
  to be advertised in the SRV6 Locator TLV. This specification adds the AC-Bit
  (AnyCast Bit) which is applicable to all usages of the OSPFv3 PrefixOptions.

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 a Huawei implemenation underway but it has not been released yet and
  there is no report.

## 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 SPRING WG has been notified.

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.

  A Routing Directorate Review is in progress.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

  Not Applicable.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

  Not Appliable.

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

    Not Applicable.


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?

    Proposed Standard. This is appropriate given that the document specifies
    the protocol encodings required for interoperable SRv6 operation.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][8]? 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. Only four authors. Dean Cheng was removed as an author due to his
    retirement and disengagement from the IETF.

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

    No nits.

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

    No. All references are properly categorized.

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

    Not Applicable.

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?

    None.

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

    No changes to other documents.

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 review has been done at each phase and the codepoints have
    been allocated through the early allocation process. An additional
    request has been made to add the AC-Bit to the OSPFv3 PrefixOptions
    registry.

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.

    Assignments to the two new registries are made through IETF Review or
    IESG Approval [RFC 8126].
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?

  This document had broader consensus than most OSPFv3 documents with actual
  implementors from Huawei, Cisco, Juniper, Nokia, and Arrcus reviewing the
  draft or contributing to the updates during the last call period. As always,
  it would be better if there were earliar reviews and discussions.

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

  There was no real controversy although there was discussion as to whether it
  was a good idea to have a separate Link State Advertisements (LSAs) for the
  SRv6 Locators as opposed to using the existing LSAs. Unlike IS-IS, one of
  the advantages of OSPFv3 is that disjoint information can be advertised in
  separate LSAs.

  Review by OSPFv3 implementors revealed that the OSPFv3 PrefixOptions needed
  to be advertised in the SRV6 Locator TLV. This specification adds the AC-Bit
  (AnyCast Bit) which is applicable to all usages of the OSPFv3 PrefixOptions.

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 a Huawei implemenation underway but it has not been released yet and
  there is no report.

## 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 SPRING WG has been notified.

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.

  A Routing Directorate Review is in progress.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

  Not Applicable.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

  Not Appliable.

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

    Not Applicable.


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?

    Proposed Standard. This is appropriate given that the document specifies
    the protocol encodings required for interoperable SRv6 operation.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][8]? 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. Only four authors. Dean Cheng was removed as an author due to his
    retirement and disengagement from the IETF.

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

    No nits.

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

    No. All references are properly categorized.

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

    Not Applicable.

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?

    None.

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

    No changes to other documents.

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 review has been done at each phase and the codepoints have
    been allocated through the early allocation process. An additional
    request has been made to add the AC-Bit to the OSPFv3 PrefixOptions
    registry.

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.

    Assignments to the two new registries are made through IETF Review or
    IESG Approval [RFC 8126].

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?

  This document had broader consensus than most OSPFv3 documents with actual
  implementors from Huawei, Cisco, Juniper, Nokia, and Arrcus reviewing the
  draft or contributing to the updates during the last call period. As always,
  it would be better if there were earliar reviews and discussions.

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

  There was no real controversy although there was discussion as to whether it
  was a good idea to have a separate Link State Advertisements (LSAs) for the
  SRv6 Locators as opposed to using the existing LSAs. Unlike IS-IS, one of
  the advantages of OSPFv3 is that disjoint information can be advertised in
  separate LSAs.

  Review by OSPFv3 implementors revealed that the OSPFv3 PrefixOptions needed
  to be advertised in the SRV6 Locator TLV. This specification adds the AC-Bit
  (AnyCast Bit) which is applicable to all usages of the OSPFv3 PrefixOptions.

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 a Huawei implemenation underway but it has not been released yet and
  there is no report.

## 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 SPRING WG has been notified.

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.

  A Routing Directorate Review is in progress.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

  Not Applicable.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

  Not Appliable.

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

    Not Applicable.


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?

    Proposed Standard. This is appropriate given that the document specifies
    the protocol encodings required for interoperable SRv6 operation.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][8]? 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. Only four authors. Dean Cheng was removed as an author due to his
    retirement and disengagement from the IETF.

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

    No nits.

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

    No. All references are properly categorized.

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

    Not Applicable.

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?

    None.

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

    No changes to other documents.

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 review has been done at each phase and the codepoints have
    been allocated through the early allocation process. An additional
    request has been made to add the AC-Bit to the OSPFv3 PrefixOptions
    registry.

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.

    Assignments to the two new registries are made through IETF Review or
    IESG Approval [RFC 8126].
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?

  This document had broader consensus than most OSPFv3 documents with actual
  implementors from Huawei, Cisco, Juniper, Nokia, and Arrcus reviewing the
  draft or contributing to the updates during the last call period. As always,
  it would be better if there were earliar reviews and discussions.

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

  There was no real controversy although there was discussion as to whether it
  was a good idea to have a separate Link State Advertisements (LSAs) for the
  SRv6 Locators as opposed to using the existing LSAs. Unlike IS-IS, one of
  the advantages of OSPFv3 is that disjoint information can be advertised in
  separate LSAs.

  Review by OSPFv3 implementors revealed that the OSPFv3 PrefixOptions needed
  to be advertised in the SRV6 Locator TLV. This specification adds the AC-Bit
  (AnyCast Bit) which is applicable to all usages of the OSPFv3 PrefixOptions.

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 a Huawei implemenation underway but it has not been released yet and
  there is no report.

## 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 SPRING WG has been notified.

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.

  A Routing Directorate Review is in progress.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

  Not Applicable.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

  Not Appliable.

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

    Not Applicable.


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?

    Proposed Standard. This is appropriate given that the document specifies
    the protocol encodings required for interoperable SRv6 operation.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][8]? 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. Only four authors. Dean Cheng was removed as an author due to his
    retirement and disengagement from the IETF.

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

    No nits.

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

    No. All references are properly categorized.

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

    Not Applicable.

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?

    None.

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

    No changes to other documents.

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 review has been done at each phase and the codepoints have
    been allocated through the early allocation process. An additional
    request has been made to add the AC-Bit to the OSPFv3 PrefixOptions
    registry.

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.

    Assignments to the two new registries are made through IETF Review or
    IESG Approval [RFC 8126].

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?

  This document had broader consensus than most OSPFv3 documents with actual
  implementors from Huawei, Cisco, Juniper, Nokia, and Arrcus reviewing the
  draft or contributing to the updates during the last call period. As always,
  it would be better if there were earliar reviews and discussions.

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

  There was no real controversy although there was discussion as to whether it
  was a good idea to have a separate Link State Advertisements (LSAs) for the
  SRv6 Locators as opposed to using the existing LSAs. Unlike IS-IS, one of
  the advantages of OSPFv3 is that disjoint information can be advertised in
  separate LSAs.

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 a Huawei implemenation underway but it has not been released yet and
  there is no report.

## 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 SPRING WG has been notified.

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.

  A Routing Directorate Review is in progress.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

  Not Applicable.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

  Not Appliable.

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

    Not Applicable.


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?

    Proposed Standard. This is appropriate given that the document specifies
    the protocol encodings required for interoperable SRv6 operation.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][8]? 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. Only four authors. Dean Cheng was removed as an author due to his
    retirement and disengagement from the IETF.

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

    No nits.

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

    No. All references are properly categorized.

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

    Not Applicable.

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?

    None.

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

    No changes to other documents.

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 review has been done at each phase and the codepoints have
    been allocated through the early allocation process.

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.

    Assignments to the two new registries are made through IETF Review or
    IESG Approval [RFC 8126].