Hi Lada, We believe we've addressed your comments, including splitting out the functional capability models in the -11 version. We don't believe we need a feature for a single configuration parameter that defaults to false.
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-ls-link-infinity/ Thanks, Acee > On Sep 8, 2025, at 7:46 AM, Ladislav Lhotka via Datatracker > <[email protected]> wrote: > > Document: draft-ietf-lsr-ospf-ls-link-infinity > Title: Advertising Unreachable Links in OSPF > Reviewer: Ladislav Lhotka > Review result: Ready with Issues > > **** General comments > > I have two questions regarding the overall logic of router functional > capabilities: > > 1. The ietf-ospf-unreachable-links module defines the "functional-capability" > identity that appears to be intended as a potential base for identities other > than "unreachable-link" that may be defined elsewhere. If it is the case, it > would be better to define the base identity "functional-capability" in a > special module. > > 2. Support for interpreting LSLinkInfinity as unreachable seems to be a > feature > of a particular router implementation. Would it make sense to define a YANG > feature for it? > > **** Specific comments > > - The augment statement for "unreachable-link-advertisement" contains the > following substatement: > > when "../rt:type = 'ospf:ospfv2' or "../rt:type = 'ospf:ospfv3'" > > XPath equality check uses *literal strings*, so the above condition will fail > if another prefix is used for the "ietf-ospf" module in XML representation of > instance data, and will always fail for JSON representation where the > identityref values are "ietf-ospf:ospfv2" and "ietf-ospf:ospfv3". > > This problem was the reason for defining XPath functions derived-from() and > derived-from-or-self(), see sec. 10.4 in RFC 7950. > > - The remaining four augments use "when" statements like this: > > when "derived-from(/rt:routing/rt:control-plane-protocols/" > + "rt:control-plane-protocol/rt:type, 'ospf:ospfv2')" > > This avoids the above problem but won't work either because identity > derivation > is irreflexive (see sec. 7.18.2 in RFC 7950), so the above expression will be > false if "rt:type" is "ospf:ospfv2". In all four cases the XPath function > derived-from-or-self() has to be used rather than derived-from(). > > **** Nits > > - Section 3.1 uses "this document" and "this specification" but, as I > understand it, it means some prior OSPF spec and *not* > draft-ietf-lsr-ospf-ls-link-infinity. I would recommend to clarify this and > refer to a specific document explicitly. > > - Typos: > > * sec. 1, 2nd paragraph: s/his/This/ > > * sec. 3.1, 2nd paragraph: s/interpretaion/interpretation/ > > * sec. 3.1, 3rd paragraph: s/metic/metric/ > > > _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
