Early Review of draft-ietf-ospf-sr-yang-20
review-ietf-ospf-sr-yang-20-yangdoctors-early-rahman-2023-04-03-00

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.