Hi Adrian, The answers are much the same as for the OSPF flex-algo YANG (as were your comments).
> On Mar 25, 2026, at 1:45 PM, Adrian Farrel via Datatracker <[email protected]> > wrote: > > Document: draft-ietf-lsr-isis-flex-algo-yang > Title: YANG Data Model for IS-IS Application-Specific Link Attributes and > Flexible Algorithm Reviewer: Adrian Farrel Review result: Has Issues > > Hi, > > I have been selected as the Operational Directorate (opsdir) reviewer for this > Internet-Draft. > > The Operational Directorate reviews all operational and management-related > Internet-Drafts to ensure alignment with operational best practices and that > adequate operational considerations are covered. > > A complete set of "Guidelines for Considering Operations and Management in > IETF > Specifications" can be found at > https://datatracker.ietf.org/doc/draft-opsarea-rfc5706bis/. > > While these comments are primarily for the Operations and Management Area > Directors (Ops ADs), the authors should consider them alongside other feedback > received. > > Thank you for your work on this document. Please address these comments or > feel > free to contact me for clarification and/or discussion. > > Best regards, > > Adrian > > ====== > > Document: draft-ietf-lsr-isis-flex-algo-yang-05 > > Reviewer: Adrian Farrel ([email protected]) > > Review Date: 2026-03-25 > > Intended Status: Standards Track > > Summary > > This document defines YANG models for handling flex-algo and > application-specific link attributes in IS-IS. As such, it depends heavily on > the protocol work in RFC 9350 and RFC 9479. The document contains two > IANA-managed YANG modules, one new module, and one that augments the YANG > model > defined in RFC 9130. > > This document is a pair with draft-ietf-lsr-opspf-flex-algo-yang and depends > on > the two IANA-managed YANG modules defined there. It is a little disconcerting > that there is not an easy mapping between the two protocol models because of > different foundational protocol work. > > The document shepherd write-up is deficient. In answer to question 4 (For > protocol documents, are there existing implementations of the contents of the > document? ) it says "N/A". But this is a Standards Track protocol document. > YANG models are implementable and it would give significant credence to the > completeness of this specification if this question had been answered with > implementation details. (Of course, it would have been even better to see an > Implementation Status section in the document.) > > It remains up to the WG and AD whether to pursue publication of an > unimplemented YANG model. Same response as OSPF. The LSR WG doesn't require implementation. > > The comments that follow are very similar to those for the OSPF document. This > may be because the source text was block copied. > > == Management Considerations == > > Failure cases are covered by a single Notification for flex-algo not > supported. > There is no equivalent for metric not supported, although that is a less > critical issue. There are no controls available to turn the reporting on or > off, and to throttle reporting. > > == Major Issues == > > iana-igp-metric-types in the OSPF document has > > identity bandwidth-metric { > base metric-type; > description > "Bandwidth metric."; > reference > "draft-ietf-lsr-flex-algo-bw-con"; > } > > There is a set of codepoints for "user-defined metrics" and "flexible > algorithms". I see leaf algo-number, but nothing equivalent for metrics. These are ranges not explicit values. > > But I also don't understand how algo-number, metric-type, and calc-type are > used. Surely algo-number and calc-type are complementary with only one of them > having meaning at once? Don't you need a Bool to say whether to use > algo-number > or calc-type? (and similarly for metric-type or the new user-defined-metric > type) > > Further, shouldn't algo-number have a range clause? Only for configuration. I'll update the read-only nodes to include the range in the description. > > Further, the description for calc-type is surely wrong. algo-type is a base > identity not an integer. > > Lastly, in flex-algo-not-supported, the leaf algo-number is a uint8 which > clashes with the use of the identity. > > --- > > When I see a Notification defined, I expect to see some way to turn on and off > the generation of notifications, and ideally a way to control the rate of > generation. This comment is best addressed with a general solution. We don't want this done for every YANG notification uniquely. Please address this specification gap with the NETMOD WG. > > --- > > What happens if more flags are added to the SABM registry? Shouldn't you be > using an IANA-managed registry for that, too? Same response as OSPF. Then the draft that defines the bit will create the new registry. > > == Minor Issues == > > While the tree diagrams are useful, it is a shame that there is no text > describing the two OSPF models and how they are used. I guess you copied the comments from your OSPF review. There are descriptions of models. > > --- > > You have a number of imports from other modules. While your reference clauses > are clear with their pointers to the relevant RFCs, those RFCs don't appear in > the References section. What you need to do is either provide a table of > imports (as is often done - for example, section 1.3 of RFC 9731), or some > text > above each module saying "This module imports from RFCwxyz". Then you can add > the documents to the References section. I think they are all Normative > references. > > I see, at least: > RFC 6991 > RFC 8349 > RFC 8919 > RFC 8776 Will add these. > > --- > > Why does this model use a unint 16 for the interface-asla and not the > sabm-bits > identity? Will fix. > > == Nits == > > All of the copyright statements appear to be ood for document posted this > year.] Will fix. > > --- > > 2. > > This document defined a YANG module for IS-IS Application-Specific > Link Attributes as defined in [RFC9479]. > > s/defined/defines/ Will fix. > --- > > container sabm { > leaf-list sabm-bits { > type identityref { > base sabm-bit; > } > description > "SABM bits list. This list will contain > identities for the bits which are set in the > SABA bits."; > } > description > "Standard Application Identifier Bit Mask."; > } > > s/SABA/SABM/ ?? Yes - will fix. > > --- > > container isis-asla { > list interface-asla { > key "app-id"; > leaf app-id { > type uint16 { > range "0 .. 1023"; > } > description > "Application ID. > 0 - RSVP TE. 1 - Segment Routing Policy. > 2 - Loop-Free Alternate."; > } > > Would be nice to list the IDs on separate lines. Sure. The leaf type is changed as per your previous comment. Thanks, Acee > > > _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
