Main comments
=============

- Please add lots of references in the YANG. There are many (most/all?) nodes e.g. m-bit, protocol-srgb etc etc, and probably types, which need references to the relevant sections in corresponding RFCs.
- The document needs a least 1, probably more, examples.
- The abstract mentions OSPF, the overview mentions OSPFv2 only and the YANG module has OSPFv2 and OSPFv3.
- sr-algorithm should be a leafref to an algorithm somewhere, right now it's a uint8.
- No need to redefine uint24, it's already define in RFC8294.
- Leaf preference, no need for range 0..255 since it's a uint8
- Looking at RFC9020, I see that container segment-routing, in grouping sr-control-plane, is non-presence and leaf receive has default value true, meaning receive is true by default even if the container hasn’t been created. Is that the intention? And is it the desired behaviour in OSPF? If no, you can add a refine statement.
My guess though is that is a mistake in RFC9020.
 
Questions
=========

- extended-prefix-range-tlvs is used only for ospfv2. Is that on purpose. Since there's an "af" node in the grouping, I assumed it'd be used for ospfv3 also. BTW 'af' is defined as uint8, there's an address-family type in RFC6991 and that should be used instead.
- Is uint16 sufficient for range-size?
- I see augment ospf:ospfv2 when rt:type = ospfv2, is the when-stmt needed? The ospfv2 container should only exist for ospfv2?
- Leaf sid is a uint32. In SR models, is the Sid always represented as a uint32 or is there a type defined. And should it be a choice for 20-bit label v/s 32-bit SID.
- List lan-adj-sid-sub-tlv in container lan-adj-sid-sub-tlvs, no need for a key?

Regards,
Reshad.