In general, I found this draft to be easier to follow than some.

Thanks to Christian Huitema for his security review.  I recommend that the rewrite of the Security Considerations paragraph 
outlined here:  https://mailarchive.ietf.org/arch/msg/pals/lALbFW32nmmBVVAG68K7xLRUDZ8/ be considered.

Thanks for addressing my comments!

Thank you for the work on this document and for addressing my previous DISCUSS. Good to go for me now (after IESG approval of downref to RFC3985).

Thanks for this document. Minor comments:

Section 3.1 'Terminology' - 'SRH - Segment Routing Header' is defined in RFC 8754 NOT RFC 8402.

Section 3.1 'Terminology' - 'SR-TE - Segment Routing Traffic Engineering [RFC9256]'. RFC 9256 defines Segment Routing Policy Architecture. Please use a reference that accurately reflects where you use the SR-TE term.

I support Francesca's discuss.

I support Roman's and Francesca's DISCUSS

Thank you to Joel Halpern for the GENART review.

Thank you for the detailed and thorough answers to my questions, and addressing my DISCUSS and COMMENT feedback.

Thanks for addressing my discuss and comments. This looks good now.

Thanks for addressing my previous DISCUSS for the -12 and considering my comments below (kept for archiving purposes).

The previous DISCUSS is archived at: https://mailarchive.ietf.org/arch/msg/pals/Spfarc0uyWsYjw63YB5HLytlkXA/

## COMMENTS (non-blocking) for archiving purpose only

### Added latency

Should there be some guidance about the added latency due to the packetization (could be reduced with packet size) and jitter buffer size ?

### Abstract & section 1

s/This document describes/This document specifies/ in a PS ;-)

Is `high-speed bit-streams` really part of this specification ? I.e., this technique could also be used with really slow links.

### Section 1

Suggest to expand PE at first use even if it is a knows acronym as it is expanded later in the text.

s/Ethernet connected/Ethernet-connected/ ?

What is `Synchronous Ethernet`, honestly I do not know, hence an informative reference is welcome.

Should there be an informational reference to `Fibre Channel` ?

A graphic for the SONET/SDH explanations would add to the text (even if the text is clear as it is). Just a suggestion.

`PDH` is not yet expanded at this point.

### Section 3.1

Just a suggestion for the reader, keep this section but also expand the acronyms at first use (because then they are more understandable -- few readers will read and understand a terminology section that only contains expansions without explanations).

### Section 3.2

s/The local oscillators C/The local clock C/ ?

Is it clock or frequency in `frequency synchronization available`? Because the word frequency was never used before.

A reference (more than the expansion of section 3.1) for `BITS` will be welcome.

### Section 5.1

Isn't it obvious that C-SID can be used ? => suggest removing this sentence (feel free to ignore).

Suggest to have a sub-section for the SRv6 behaviours.

s/The next header field of the SRH or last extension header/The next header field of the SRH or *the* last extension header/

s/The push of the SRH/The *insertion* of the SRH/ also add "per RFC 8986".

What is `pushed IPv6 header` ? If this is the SRH, then let's be clear (and BTW IPv6 is not MPLS, there is no "push" ;-) ).

### Section 7.2.1

Suggest to make it clear that all packets are of the same size in `fixed size PLE payloads`

### Section 10

Suggest to add (e.g., via a reference) the URI of the IANA (sub)registries.

Also, there is no `Segment Routing Parameters`, only a `Segment Routing` one ;-)

## NITS (non-blocking / cosmetic)

### Use of SVG

Suggest trying the "aasvg" tool to have nicer graphics in HTML/PDF rendering (worth a try).

### ethernet

Check that Ethernet is always capitalised.