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. ---------------------------------------------------------------------- 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. 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. ---------------------------------------------------------------------- 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/ --- Section 5, introductory text, line 462: 462 > Additional atttributes will be included in these TLVs when s/atttributes/attributes/ --- 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/ --- 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/ --- 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/ _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
