The “Compressed SRv6 Segment List Encoding” draft revision 19 specifies new segment routing flavors and behaviors that enable compression of the SRv6 SID list. The draft is written largely from the perspective of editing or augmenting existing segment routing behaviors defined by RFCs 8402, 8986, and 8754. The draft reads like errata or change “pages” to these other specifications and as such may be less accessible to readers not familiar with the original specifications. Overall, the draft is well written, concise, and introduces the reader to the subject matter effectively.

In summary, the draft is: READY WITH NITS

The following list contains areas where the authors may want to give more attention:

The draft uses the FIB term extensively but doesn't list it in the terminology section where other such terms that are defined in other RFCs and used in this draft are listed.

Sections 4.1.5, 4.2.2, 4.2.3, 4.2.4, 4.2.6, 5.3 (last paragraph) appear to have a spurious newline.

Section 4.2.8 uses R20.1 to refer to a one-line change to R20. In other parts of the document a one-line change doesn't introduce a ".1" extension to the line number. Possibly, this should just be "R20"?

Section 5.1 refers to "anycast" but doesn't cite a reference.

Section 5.3 the NEXT-CSID flavor SIDs are shown in an example using the form "2001:db8:b1:10::" without introduction to what it is. Providing some introductory text may improve readability such as "The SID 2001:db8:b1:10:: is bound to ...".

Section 6.2 uses the abbreviation "AL" but doesn't describe where it is defined and doesn't directly define it.

Section 6.2 refers to HMAC which may refer to a cryptographic MAC function. The security considerations section doesn't describe the security significance of the HMAC use. HMAC / SHA-1 may not be strong enough for many use cases. Stronger SHA-256/512 may be required. The I-D doesn't describe the security implications of the protocol given there are users that require SHA-256 or higher strength.

Section 7 "S/that spans across multiple routing domains"/that spans multiple routing domains"

Section 7.2 uses the variable "J" but it isn't clear if this is the same J that is defined in Section 4.2 of [RFC8986].

Section 7.2 uses the word "learnt" which isn't found in the American English dictionary.

Security Considerations - As this RFC updates previous SR RFCs it may be appropriate to revisit assumptions made by earlier RFCs regarding the appropriateness of security strength, algorithms used, and considerations for PQC readiness.