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. 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. 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? 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. --- What happens if more flags are added to the SABM registry? Shouldn't you be using an IANA-managed registry for that, too? == 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. --- 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 --- Why does this model use a unint 16 for the interface-asla and not the sabm-bits identity? == Nits == All of the copyright statements appear to be ood for document posted this year. --- 2. This document defined a YANG module for IS-IS Application-Specific Link Attributes as defined in [RFC9479]. s/defined/defines/ --- 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/ ?? --- 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. _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
