Hi Mahesh, Thanks for the review. See version -10.
> On Jun 29, 2026, at 11:45 PM, Mahesh Jethanandani via Datatracker > <[email protected]> wrote: > > Mahesh Jethanandani has entered the following ballot position for > draft-ietf-lsr-ospf-flex-algo-yang-08: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-flex-algo-yang/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I have reviewed the existing ballot positions from Ketan Talaulikar and > Mohamed Boucadair: the comments below do not repeat issues already > raised there, except where I note agreement with additional detail. > Needless to say, I support their position. > > ---------------------------------------------------------------------- > DISCUSS > ---------------------------------------------------------------------- > > Section 5, ietf-ospf-link-attr module, interface ASLA augment, when > condition: > > 720 > augment "/rt:routing/rt:control-plane-protocols/" > 721 > + "rt:control-plane-protocol/ospf:ospf/" > 722 > + "ospf:areas/ospf:area/ospf:interfaces/ospf:interface" { > 723 > when "derived-from(/rt:routing/rt:control-plane-protocols/" > 724 > + "rt:control-plane-protocol/rt:type, 'ospf:ospfv2') or " > 725 > + "derived-from(/rt:routing/rt:control-plane-protocols/" > 726 > + "rt:control-plane-protocol/rt:type, 'ospf:ospfv2')" { > > In my view, this is a copy-paste error: both arms of the Boolean > `or` evaluate to 'ospf:ospfv2'. As written, the `ospf-asla` container > — including `interface-asla` with `te-metric` and `admin-group` > per-application configuration — is active only for OSPFv2 instances. > An OSPFv3 management client will find the container absent from the > schema, and cannot configure per-application link attributes for > OSPFv3. > > I believe the second 'ospf:ospfv2' should be 'ospf:ospfv3'. If the > restriction to OSPFv2 is in fact intentional — perhaps because the > OSPFv3 link-attribute attributes are handled differently — then I > would ask the authors to explain the design rationale, update the > tree diagram to reflect the restriction, and add a sentence in Section > 5 clarifying that OSPFv3 ASLA interface configuration is out of scope. Fixed. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 1. Wrong references in the IANA-maintained iana-igp-link-attr-apps > module > > I agree with and wish to add specificity to the point already raised in > Boucadair's DISCUSS regarding IANA-maintained modules not mirroring the > registry content accurately. > > Section 4, iana-igp-link-attr-apps module, rsvp-te-app identity: > > 404 > identity rsvp-te-app { > ... > 411 > reference > 412 > "RFC 3630: Traffic Engineering (TE) for OSPFv2 > 413 > RFC 5329: Traffic Engineering Extensions to OSPFv3"; > 414 > } > > RFC 9479 ("IS-IS Application-Specific Link Attributes") established > this registry (Section 10 of RFC 9479). However, the identities in the > module cite the OSPF or LFA protocol documents that USE these bits, > not the RFC that registered them. > > Section 4, iana-igp-link-attr-apps module, sr-policy-app identity: > > 415 > identity sr-policy-app { > ... > 422 > reference > 423 > "RFC 8665: OSPF Extensions for Segment Routing > 424 > RFC 8666: OSPFv3 Extensions for Segment Routing"; > 425 > } > > Same issue. RFC 8665 and RFC 8666 define OSPF SR extensions; the IANA > registration for Bit 1 cites RFC 9479. > > Section 4, iana-igp-link-attr-apps module, lfa-app identity: > > 426 > identity lfa-app { > ... > 433 > reference > 434 > "RFC 8102: Remote-LFA Node Protection and Manageability > 435 > RFC 9855: Topology Independent Fast Reroute Using > 436 > Segment Routing"; > 437 > } > > RFC 8102 covers Remote-LFA specifically; RFC 9855 covers TI-LFA. Bit 2 > is defined to cover "Loop-Free Alternate (includes all LFA types)," and > the IANA registration source is RFC 9479. The references cited are > specific LFA variants that use the F-bit, not the RFC that registered > it. > > The base identity also has a reference issue: > > 397 > identity igp-link-attr-app { > ... > 401 > reference > 402 > "RFC 9492: OSPF Application-Specific Link Attributes"; > 403 > } > > The "Link Attribute Application Identifiers" registry was created by > RFC 9479, not RFC 9492. The base identity reference should point to the > document that established the registry. > > In contrast, the `flex-algo-app` identity correctly cites RFC 9350, > Section 12, matching the registry entry. > > I would suggest updating `rsvp-te-app`, `sr-policy-app`, and `lfa-app` > to cite RFC 9479 as the primary registry reference, with the > OSPF-specific protocol documents retained as informative or secondary > citations if desired for reader context. Fixed. > > 2. YANG Module Names registration: inconsistent module name in > Section 8.1 > > 1852 > name: iana-igp-link-attr-app > 1853 > Maintained by IANA? Y > 1854 > namespace: urn:ietf:params:xml:ns:yang:iana-igp-link-attr-apps > 1855 > prefix: iana-link-attr-app > 1856 > reference: RFC XXXX > > The `name` field says `iana-igp-link-attr-app` (singular), but the > module is defined (Section 4, line 340) as `iana-igp-link-attr-apps` > (plural), and the namespace also uses the plural form. Please address. Fixed. > > ---------------------------------------------------------------------- > NIT > ---------------------------------------------------------------------- > > All comments below are about very minor potential issues that you may > choose to address in some way - or ignore - as you see fit. Some were > flagged by automated tools (via > https://github.com/larseggert/ietf-reviewtool), so there will likely > be some false positives. There is no need to let me know what you did > with these suggestions. > > Section 5, introductory text, line 459: > > 459 > As far as whether or not an application-specific link atttribute is > > s/atttribute/attribute/ Fixed. > > --- > > Section 5, introductory text, line 462: > > 462 > Additional atttributes will be included in these TLVs when > > s/atttributes/attributes/ Fixed. > > --- > > Section 3, iana-igp-metric-types module, min-unidirectional-link-delay > description: > > 288 > description > 289 > "Min Unidirectional Link Delay as defined in RFC 8570 > 290 > and Section 4.2 and RFC 7471 Section 4.2."; > > s/as defined in RFC 8570 and Section 4.2 and RFC 7471 Section 4.2/ > as defined in RFC 8570 Section 4.2 and RFC 7471 Section 4.2/ Fixed. > > --- > > Section 6, ietf-ospf-flex-algo module, calc-type leaf description: > > 1453 > description > 1454 > "Calcuation-type. Value from 0-127 inclusive from the > > s/Calcuation-type/Calculation-type/ Fixed. > > --- > > Section 4, iana-igp-link-attr-apps module, lfa-app description: > > 428 > description > 429 > "Loop-Free Alternative (LFA) Application - This > > The IANA registry and RFC 9492 both use "Loop-Free Alternate" (not > "Alternative"). Suggest aligning with the registry terminology. > > s/Loop-Free Alternative/Loop-Free Alternate/ Fixed. Thanks, Acee > > > _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
