Hi Med, We've published version -10 of draft-ietf-lsr-ospf-flex-algo-yang, which includes the IANA-maintained modules. Can you please review those modules and the "IANA Considerations" section?
Specifically, we received the following comments from Amanada: " Also, for future reference: the template text provided in RFC 9907, Sections 4.30.3.1 and 4.30.3.2 has been simplified. The "description" and "reference" substatement instructions need to be included only when they override the default actions described in that document's Section 5.3.2. " We've removed the text regarding description and reference for "revision". Please let us know if more changes are needed. Thanks, Yingzhen On Wed, Jul 1, 2026 at 3:55 AM Acee Lindem <[email protected]> wrote: > Hi Med, > > > On Jul 1, 2026, at 3:02 AM, [email protected] wrote: > > > > Hi Acee, > > > > Thank you for the changes. I think I'm fine with -17. > > > Thanks > > > > One nitty thing, please double check the second module as I think this > change is needed: > > > > OLD: > > the RFC itself for full legal notices. > > > > The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL > > NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', > > 'MAY', and 'OPTIONAL' in this document are to be interpreted as > > described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, > > they appear in all capitals, as shown here."; > > > > NEW: > > the RFC itself for full legal notices."; > > Right - there is no normative language in ietf-isis-flex-algo.yang. > > Fixed in -18. > > Thanks, > Acee > > > > > > Cheers, > > Med > > > >> -----Message d'origine----- > >> De : Acee Lindem <[email protected]> > >> Envoyé : vendredi 26 juin 2026 19:23 > >> À : BOUCADAIR Mohamed INNOV/NET <[email protected]> > >> Cc : The IESG <[email protected]>; Christian Hopps > >> <[email protected]>; [email protected]; > >> [email protected]; lsr <[email protected]> > >> Objet : Re: Mohamed Boucadair's Discuss on draft-ietf-lsr-isis- > >> flex-algo-yang-08: (with DISCUSS and COMMENT) > >> > >> > >> Hi Med, > >> > >>> On Jun 26, 2026, at 2:15 AM, [email protected] wrote: > >>> > >>> Hi Acee, > >>> > >>> Thanks for the follow-up. > >>> > >>> I also checked the diff 08 vs 11. I think that almost all is > >> there. Appreciated. > >>> > >>> For this one: > >>> > >>>> Mostly, though we should avoid validation of read-only data > >> received > >>>> in IS-IS TLVs and sub-TLVs. > >>> > >>> I wasn't actually asking for adding validation. That would be > >> against > >>> this party from RFC 9907 :-) > >>> > >>> From > >>> that perspective, it is RECOMMENDED to avoid defining > >> constraints on > >>> state data that would hinder the detection by a management > >> system of > >>> abnormal behaviors of a managed entity. > >>> > >>> I'm approaching this with an OPS eye and was hoping to see some > >> cautions in the descriptions to help identify what can be > >> considered as an anomaly. > >> > >> Against my better judgment, I added some of these in the > >> descriptions. Also, simplified the Flex Algo config to not be > >> dependent on ietf-te.yang (only item-te-types.yang now). > >> > >> Thanks, > >> Acee > >> > >> > >>> > >>> Cheers, > >>> Med > >>> > >>>> -----Message d'origine----- > >>>> De : Acee Lindem <[email protected]> > >>>> Envoyé : jeudi 25 juin 2026 20:27 > >>>> À : BOUCADAIR Mohamed INNOV/NET <[email protected]> > >>>> Cc : The IESG <[email protected]>; Christian Hopps > >>>> <[email protected]>; draft-ietf-lsr-isis-flex-algo- > >> [email protected]; > >>>> [email protected]; lsr <[email protected]> > >>>> Objet : Re: Mohamed Boucadair's Discuss on draft-ietf-lsr-isis- > >>>> flex-algo-yang-08: (with DISCUSS and COMMENT) > >>>> > >>>> > >>>> Hi Med, > >>>> > >>>> Please see updates in -99 version. > >>>> > >>>>> On Jun 23, 2026, at 4:51 AM, Mohamed Boucadair via Datatracker > >>>> <[email protected]> wrote: > >>>>> > >>>>> Mohamed Boucadair has entered the following ballot position > >> for > >>>>> draft-ietf-lsr-isis-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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >>>> www. > >>>>> ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling- > >> ballot- > >>>> positi > >>>>> > >>>> > >> ons%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cea4d618efe2 > >>>> 04c1 > >>>>> > >>>> > >> e21ac08ded2e75e71%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639 > >>>> 1800 > >>>>> > >>>> > >> 88329430960%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOi > >>>> IwLj > >>>>> > >>>> > >> AuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C% > >>>> 7C%7 > >>>>> > >>>> > >> C&sdata=GO7p8E2JHW1L4%2BO0uWsMCly2O6JqnNDj%2F5GT7HvpsO8%3D&reserve > >>>> d=0 > >>>>> for more information about how to handle DISCUSS and COMMENT > >>>> positions. > >>>>> > >>>>> > >>>>> The document, along with other ballot positions, can be found > >>>> here: > >>>>> > >>>> > >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >>>> data > >>>>> tracker.ietf.org%2Fdoc%2Fdraft-ietf-lsr-isis-flex-algo- > >>>> yang%2F&data=05 > >>>>> > >>>> > >> %7C02%7Cmohamed.boucadair%40orange.com%7Cea4d618efe204c1e21ac08ded > >>>> 2e75 > >>>>> > >>>> > >> e71%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63918008832945035 > >>>> 4%7C > >>>>> > >>>> > >> Unknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIs > >>>> IlAi > >>>>> > >>>> > >> OiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=yj > >>>> uCqv > >>>>> eLd2aUyGb4MVvAFNTz1pz0Ixs4pwEPxAJnWRY%3D&reserved=0 > >>>>> > >>>>> > >>>>> > >>>>> -------------------------------------------------------------- > >> -- > >>>> ------ > >>>>> DISCUSS: > >>>>> -------------------------------------------------------------- > >> -- > >>>> ------ > >>>>> > >>>>> Hi Yingzhen, Acee, and Madhavi, > >>>>> > >>>>> Thank you for the effort put into this specification. > >>>>> > >>>>> Please find some comments and suggestions. These are easy-to- > >>>> fix. Let > >>>>> me know if any clarification is needed. > >>>>> > >>>>> # Lack or narrative text > >>>>> > >>>>> RFC9907 says: > >>>>> The narrative sections MUST include an overview section that > >>>>> describes the scope and field of application of the data > >>>> model(s) > >>>>> defined by the specification and that specifies the > >>>> relationship (if > >>>>> any) of these data models to other standards, particularly to > >>>>> standards containing other YANG data models. The narrative > >>>> part > >>>>> SHOULD include one or more sections to briefly describe the > >>>> structure > >>>>> of the data models defined in the specification. > >>>>> > >>>>> At least an overview is needed (MUST part above). > >>>>> > >>>>> I remember that we had the same comment for RFC9903. Having > >>>> something > >>>>> similar to the text you added in “Design of the YANG Module > >> for > >>>> OSPF > >>>>> MPLS Segment Routing” of RFC9903 would be great. Thanks. > >>>> > >>>> Description added. > >>>> > >>>>> > >>>>> # te-metric > >>>>> > >>>>> CURRENT: > >>>>> leaf te-metric { > >>>>> type uint32; > >>>>> description > >>>>> "TE default metric."; > >>>>> reference > >>>>> "RFC 5305: IS-IS Extensions for Traffic Engineering, > >>>>> Section 3.7"; > >>>>> > >>>>> Why not using this type from draft-ietf-teas-rfc8776-update > >>>>> > >>>>> typedef te-metric { > >>>>> type uint32; > >>>>> description > >>>>> "Traffic Engineering (TE) metric."; > >>>>> reference > >>>>> "RFC 3630: Traffic Engineering (TE) Extensions to OSPF > >>>>> Version 2, Section 2.5.5 > >>>>> RFC 5305: IS-IS Extensions for Traffic Engineering, > >>>>> Section 3.7"; > >>>>> } > >>>>> > >>>>> # admin-group > >>>>> > >>>>> CURRENT: > >>>>> leaf admin-group { > >>>>> type uint32; > >>>>> description > >>>>> "Administrative Group / Resource Class/Color."; > >>>>> reference > >>>>> "RFC 5305: IS-IS Extensions for Traffic Engineering, > >>>>> Section 3.1"; > >>>>> } > >>>>> > >>>>> This definition deviates from the one in draft-ietf-teas- > >>>> rfc8776-update: > >>>>> > >>>>> typedef admin-group { > >>>>> type yang:hex-string { > >>>>> /* 01:02:03:04 */ > >>>>> length "1..11"; > >>>>> } > >>>>> description > >>>>> "Administrative group / resource class / color > >>>> representation > >>>>> in 'hex-string' type. > >>>>> > >>>>> The most significant byte in the hex-string is the > >>>> farthest > >>>>> to the left in the byte sequence. > >>>>> > >>>>> Leading zero bytes in the configured value may be > >>>> omitted > >>>>> for brevity."; > >>>>> reference > >>>>> "RFC 3630: Traffic Engineering (TE) Extensions to OSPF > >>>>> Version 2 > >>>>> RFC 5305: IS-IS Extensions for Traffic Engineering > >>>>> RFC 7308: Extended Administrative Groups in MPLS > >>>> Traffic > >>>>> Engineering (MPLS-TE)"; > >>>>> } > >>>>> > >>>>> Unless there is a valid reason, I recommend to reuse the type > >>>> defined in 8776. > >>>> > >>>> The reason would be that the original IS-IS (and OSPF) TE > >>>> attributes didn't use these types. > >>>> However, the ASLA attributes are used more frequently, However, > >>>> there is no reason to use the RFC 8776 BIS draft and introduce > >> a > >>>> dependency on this document. > >>>> > >>>> It is really unfortunate how long documents are sitting on the > >> RFC > >>>> queue these days and, at 162 pages, RFC 8776 has the potential > >> to > >>>> sit for a long time. > >>>> > >>>> > >>>> > >>>> > >>>>> > >>>>> # Priority Unicity > >>>>> > >>>>> CURRENT: > >>>>> list unreserved-bandwidth { > >>>>> leaf priority { > >>>>> type uint8 { > >>>>> range "0 .. 7"; > >>>>> } > >>>>> description > >>>>> "Priority from 0 to 7."; > >>>>> } > >>>>> leaf unreserved-bandwidth { > >>>>> type rt-types:bandwidth-ieee-float32; > >>>>> description > >>>>> "Unreserved bandwidth."; > >>>>> } > >>>>> description > >>>>> "List of unreserved bandwidths for different > >>>>> priorities."; > >>>>> } > >>>>> > >>>>> Do we allow to repeat the same priority? How to ensure > >> unicity? > >>>> At > >>>>> least for ro, this should be flagged as an anomaly. A > >> discussion > >>>> in an > >>>>> OPS Considerations Section would be helpful here. > >>>> > >>>> This is the contents of the received LSP sub-TLVs. There > >> shouldn't > >>>> be duplicate priorities but we don't normally try and enforce > >> list > >>>> unicity on read-only data. > >>>> > >>>> > >>>>> > >>>>> ## Idem for > >>>>> > >>>>> CURRENT: > >>>>> list fad-tlv { > >>>>> leaf algo-number { > >>>>> type uint8; > >>>>> description > >>>>> "Flex-algo number - A value not in the inclusive > >>>> range > >>>>> of 128-255 is an invalid FAD TLV > >> specification."; > >>>>> } > >>>>> leaf metric-type { > >>>>> type identityref { > >>>>> base iana-metric-type:metric-type; > >>>>> } > >>>>> description > >>>>> "Type of metric to be used during the > >>>> calculation."; > >>>>> } > >>>>> leaf calc-type { > >>>>> type identityref { > >>>>> base iana-algo-types:algo-type; > >>>>> } > >>>>> description > >>>>> "IGP algorithm types, value from 0 to 127 as > >>>>> defined under 'Interior Gateway Protocol (IGP) > >>>>> Parameter' by IANA."; > >>>>> } > >>>>> leaf priority { > >>>>> type uint8; > >>>>> description > >>>>> "Priority of the advertisement."; > >>>>> } > >>>>> > >>>> > >>>> Same response as above. > >>>> > >>>> > >>>> > >>>>> # Deviate from RFC 9479 > >>>>> > >>>>> CURRENT: > >>>>> leaf l-flag { > >>>>> type boolean; > >>>>> description > >>>>> "Legacy Flag. When set, all of the applications > >>>>> specified in the bit mask MUST use the legacy > >>>>> advertisements."; > >>>>> } > >>>>> > >>>>> RFC9479: > >>>>> When the SABM Length or UDABM Length is non-zero and the L- > >>>> flag is > >>>>> NOT set, all applications specified in the bit mask MUST use > >>>> the link > >>>>> attribute advertisements in the sub-TLV. > >>>>> > >>>>> ## The description does not mirror exactly the behavior in RFC > >>>> 9479. > >>>>> > >>>>> ## An easy fix is to remove the normative language and update > >>>> the > >>>>> description to focus on the leaf itself (management) not the > >> on- > >>>> wire spec. > >>>> > >>>> Done. > >>>> > >>>> > >>>>> > >>>>> # Length fields: Intended use > >>>>> > >>>>> CURRENT: > >>>>> > >>>>> leaf sabm-length { > >>>>> type uint8; > >>>>> description > >>>>> "Standard Application Identifier Bit Mask Length in > >>>>> octets."; > >>>>> } > >>>>> leaf udabm-length { > >>>>> type uint8; > >>>>> description > >>>>> "User Defined Application Identifier Bit Mask Length > >>>>> in octets."; > >>>>> } > >>>>> > >>>>> … > >>>>> > >>>>> leaf length-of-sub-tlvs { > >>>>> type uint8; > >>>>> description > >>>>> "Length of sub-tlvs."; > >>>>> } > >>>>> > >>>>> ## I understand this is needed for the protocol, but why do we > >>>> need > >>>>> these for managing an implem? > >>>> > >>>> It was thought that the ASLA encodings were complex and this > >> could > >>>> be helpful if there were problems. However, I can remove them. > >>>> > >>>> > >>>>> > >>>>> ## If these are maintained (which I don’t see why), then you > >>>> need to > >>>>> update the module to have a constraint for sabm per: > >>>>> > >>>>> RFC 9479: > >>>>> This field is omitted if SABM Length is 0. > >>>>> > >>>>> # Provision for future augmentations, but without guidance > >>>>> > >>>>> CURRENT: > >>>>> container udabm { > >>>>> description > >>>>> "User Defined Application Identifier Bit Mask. > >>>>> This container is to be augmented by user defined > >>>>> applications."; > >>>>> } > >>>>> > >>>>> The intended use/guidance should be defined in the main > >>>> document. > >>>>> Please add some text to set the expectations for authors for > >>>> future augmentations. > >>>> > >>>> User defined applications will not have IETF modules and this > >> is > >>>> an anchor point for user defined augmentations. What more is > >>>> necessary? > >>>> Please suggest example text... > >>>> > >>>> > >>>> > >>>>> > >>>>> # Abnormal configuration > >>>>> > >>>>> CURRENT: > >>>>> | +--ro ipv4-interface-addr > >>>>> | | +--ro ipv4-int-addr? inet:ipv4-address > >>>>> | +--ro ipv4-neighbor-addr > >>>>> | | +--ro ipv4-neighbor-addr? inet:ipv4-address > >>>>> | +--ro ipv6-interface-addr > >>>>> | | +--ro ipv6-int-addr? inet:ipv6-address > >>>>> | +--ro ipv6-neighbor-addr > >>>>> | +--ro ipv6-neighbor-addr? inet:ipv6-address > >>>>> > >>>>> The module/document does not include any discussion about > >> checks > >>>> to > >>>>> detect abnormal behaviors with regards to address family > >>>> mismatch. Can > >>>>> we please gave some text? > >>>> > >>>> These are read-only fields containing the contexts of IS-IS > >> sub- > >>>> tlvs. > >>>> > >>>> > >>>> > >>>> > >>>>> > >>>>> # srlg > >>>>> > >>>>> CURRENT: > >>>>> leaf-list srlg { > >>>>> type uint32; > >>>>> description > >>>>> "SRLG value of the link."; > >>>>> } > >>>>> > >>>>> Why no reusing this type from draft-ietf-teas-rfc8776-update? > >>>>> > >>>>> typedef srlg { > >>>>> type uint32; > >>>>> description > >>>>> "Shared Risk Link Group (SRLG) type."; > >>>>> reference > >>>>> "RFC 4203: OSPF Extensions in Support of Generalized > >>>>> Multi-Protocol Label Switching (GMPLS) > >>>>> RFC 5307: IS-IS Extensions in Support of Generalized > >>>>> Multi-Protocol Label Switching (GMPLS)"; > >>>>> } > >>>>> > >>>>> # Update to draft-ietf-teas-rfc8776-update > >>>> > >>>> Ok. > >>>> > >>>> > >>>>> > >>>>> CURRENT: > >>>>> import ietf-te-types { > >>>>> prefix te-types; > >>>>> reference > >>>>> "RFC8776: Common YANG Data Types for Traffic > >>>> Engineering."; > >>>>> } > >>>>> > >>>>> # missing normative import > >>>>> > >>>>> CURRENT: > >>>>> import ietf-te { > >>>>> prefix te; > >>>>> reference > >>>>> "RFC XXXX: A YANG Data Model for Traffic Engineering > >>>>> Tunnels, Label Switched Paths, and > >>>> Interfaces"; > >>>>> } > >>>>> > >>>> > >>>> Both imports are needed. > >>>> > >>>> > >>>> > >>>> > >>>>> RFC9907: > >>>>> > >>>>> For every "import" or "include" statement that appears in a > >>>> module > >>>>> contained in the specification that identifies a module in a > >>>> separate > >>>>> document, a corresponding normative reference to that > >> document > >>>> MUST > >>>>> appear in the Normative References section. > >>>> > >>>> Noted. > >>>> > >>>> > >>>>> > >>>>> # Consistency with RFC 9350 > >>>>> > >>>>> CURRENT: > >>>>> identity m-bit { > >>>>> base fad-flags; > >>>>> description > >>>>> "M bit, when set, the flex-algo specific prefix and > >> ASBR > >>>>> metric MUST be used for inter-area and external prefix > >>>>> calculation."; > >>>>> } > >>>>> > >>>>> ## RFC 9350 has M-flag. If we refer to the same object, then > >>>> please > >>>>> update to be consistent with 9350. > >>>>> > >>>>> ## This is an identity, not a Boolean. I don’t understand what > >>>> is > >>>>> meant by set here. > >>>> > >>>> Fixed. > >>>> > >>>> > >>>> > >>>> > >>>>> > >>>>> ## (almost) Duplicate RFC 9350 behavior, but more importantly > >>>> lack of > >>>>> management object description > >>>>> > >>>>> M-flag: when set, the Flex-Algorithm-specific prefix > >>>> metric > >>>>> MUST be used for inter-area and external prefix > >>>> calculation. > >>>>> This flag is not applicable to prefixes advertised > >> as > >>>> SRv6 > >>>>> locators. > >>>>> > >>>>> Note also the exception part in the RFC 9350. > >>>>> > >>>>> Please update the description to focus on the intended use of > >>>> the > >>>>> management object. > >>>> > >>>> Fixed. > >>>> > >>>> > >>>> > >>>>> > >>>>> # extended-admin-group > >>>>> > >>>>> CURRENT: > >>>>> leaf-list extended-admin-groups { > >>>>> type uint64; > >>>>> description > >>>>> "Extended administrative group as defined in RFC > >>>> 7308."; > >>>>> } > >>>>> > >>>>> Any reason why we can’t use extended-admin-group from > >>>>> draft-ietf-teas-rfc8776-update? > >>>>> > >>>>> As I’m there, please s/ extended-admin-groups/ extended-admin- > >>>> group > >>>>> > >>>>> # Valid Examples > >>>>> > >>>>> RFC9907 says: > >>>>> Examples that are meant to illustrate a valid > >>>>> data instance MUST be validated (Section 3.10). > >>>>> > >>>>> The JSON Example in Appendix B is not valid (at least modules > >>>> prefixes > >>>>> are needed). Please run yangson or yanglint for all the > >>>> examples. > >>>>> > >>>>> > >>>>> -------------------------------------------------------------- > >> -- > >>>> ------ > >>>>> COMMENT: > >>>>> -------------------------------------------------------------- > >> -- > >>>> ------ > >>>>> > >>>>> # Title > >>>>> > >>>>> OLD: > >>>>> YANG Data Model for IS-IS Application-Specific Link > >> Attributes > >>>> and > >>>>> Flexible Algorithm > >>>>> > >>>>> NEW: > >>>>> A YANG Data Model for IS-IS Application-Specific Link > >>>> Attributes and > >>>>> Flexible Algorithm > >>>> > >>>> Changed. > >>>> > >>>>> > >>>>> Please update the modules accordingly. > >>>>> > >>>>> # Module, model, etc. > >>>>> > >>>>> Per > >>>>> > >>>> > >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >>>> data > >>>>> tracker.ietf.org%2Fdoc%2Fhtml%2Frfc9907%23section- > >>>> 2.5&data=05%7C02%7Cm > >>>>> > >>>> > >> ohamed.boucadair%40orange.com%7Cea4d618efe204c1e21ac08ded2e75e71%7 > >>>> C90c > >>>>> > >>>> > >> 7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639180088329462098%7CUnkno > >>>> wn%7 > >>>>> > >>>> > >> CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXa > >>>> W4zM > >>>>> > >>>> > >> iIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=N1lQxb3Nihy > >>>> %2BF > >>>>> u4ejxmzCYfEWy6tOXJE2hbY6dEaYx8%3D&reserved=0, > >>>>> > >>>>> Note that the term "YANG model" is sometimes used as an > >>>> abbreviation > >>>>> of "YANG data model". However, that term should be avoided > >> in > >>>> favor > >>>>> of "YANG data model". Likewise, "YANG data module" has no > >>>> meaning > >>>>> and must be avoided. > >>>>> > >>>>> OLD: This document defines two YANG [RFC7950] data modules. > >>>>> NEW: This document defines a YANG [RFC7950] data model, which > >> is > >>>>> composed to two YANG modules. > >>>> > >>>> Fixed. > >>>> > >>>> > >>>>> > >>>>> OLD: Algorithm in JSON format using the YANG model > >>>>> NEW: Algorithm in JSON format using the YANG module > >>>> > >>>> Fixed. > >>>> > >>>>> > >>>>> # Tree diagrams > >>>>> > >>>>> RFC9907: > >>>>> If YANG tree diagrams are used, then an informative reference > >>>> to the > >>>>> YANG tree diagrams specification MUST be included in the > >>>> document. > >>>>> > >>>>> Please update 1.1 with the following: > >>>>> > >>>>> NEW: > >>>>> The meanings of the symbols in the YANG tree diagrams are > >>>> defined in > >>>>> [RFC8340]. > >>>> > >>>> Fixed. > >>>> > >>>> > >>>> > >>>>> > >>>>> # RFC9911 > >>>>> > >>>>> CURRENT: > >>>>> import ietf-inet-types { > >>>>> prefix inet; > >>>>> reference > >>>>> "RFC 6991: Common YANG Data Types"; > >>>>> } > >>>>> > >>>>> Please update to 9911. > >>>>> > >>>>> # IANA-Maintained Modules > >>>>> > >>>>> CURRENT: > >>>>> import iana-igp-link-attr-apps { > >>>>> prefix iana-link-attr-apps; > >>>>> reference > >>>>> "RFC XXXX: YANG Data Model for OSPF Application- > >> Specific > >>>>> Link Attributes and Flexible Algorithm"; > >>>>> } > >>>>> > >>>>> … > >>>>> > >>>>> import iana-igp-algo-types { > >>>>> prefix iana-algo-types; > >>>>> reference > >>>>> "RFC XXXX: YANG Data Model for OSPF Application- > >> Specific > >>>>> Link Attributes and Flexible Algorithm"; > >>>>> } > >>>>> import iana-igp-metric-types { > >>>>> prefix iana-metric-type; > >>>>> reference > >>>>> "RFC XXXX: YANG Data Model for OSPF Application- > >> Specific > >>>>> Link Attributes and Flexible Algorithm"; > >>>>> } > >>>>> > >>>>> The import applies, not only for the initial version. Please > >>>> consider > >>>>> updating the reference to follow this part from 9907: > >>>>> > >>>>> RFC9907: > >>>>> If an IANA-maintained YANG module is imported by another > >>>> module, a > >>>>> normative reference with the IANA URL from which to retrieve > >>>> the > >>>>> IANA-maintained YANG module SHOULD be included. Although not > >>>>> encouraged, referencing the RFC that defines the initial > >>>> version of > >>>>> the IANA module is acceptable in specific cases (e.g., the > >>>> imported > >>>>> version is specifically the initial version, the RFC includes > >>>> useful > >>>>> description about the usage of the module). > >>>>> > >>>>> # RFC XXXX is ambiguous as it refers to distinct docs > >>>>> > >>>>> CURRENT: > >>>>> reference > >>>>> "RFC XXXX: YANG Data Model for OSPF Application- > >> Specific > >>>>> Link Attributes and Flexible Algorithm"; > >>>>> > >>>>> "RFC XXXX: A YANG Data Model for Traffic Engineering > >>>>> Tunnels, Label Switched Paths, and > >>>> Interfaces"; > >>>>> > >>>>> # Only NMDA exceptions are needed to be called out > >>>>> > >>>>> CURRENT: > >>>>> This YANG model conforms to the Network Management > >>>>> Datastore Architecture (NMDA) as described in RFC 8342. > >>>>> > >>>>> Consider delete that statement. > >>>>> > >>>>> # Follow IETF Template > >>>>> > >>>>> OLD: > >>>>> > >>>>> This version of this YANG module is part of RFC XXXX; > >>>>> see the RFC itself for full legal notices. > >>>>> > >>>>> NEW: > >>>>> > >>>>> All revisions of IETF and IANA published modules can be > >>>> found > >>>>> at the YANG Parameters registry group > >>>>> > >>>> > >> (https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > >>>> Fwww.iana.org%2Fassignments%2Fyang- > >>>> > >> parameters&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cea4d618 > >>>> > >> efe204c1e21ac08ded2e75e71%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7 > >>>> > >> C0%7C639180088329472201%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > >>>> > >> RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy > >>>> > >> fQ%3D%3D%7C0%7C%7C%7C&sdata=z2BK%2Bft%2Fn2wsnlSFzMgn6ySEUoLIAXwVU8 > >>>> FsA3unCWo%3D&reserved=0). > >>>>> > >>>>> This version of this YANG module is part of RFC XXXX; > >> see > >>>>> the RFC itself for full legal notices. > >>>>> > >>>>> # Consider adding a reference statement to rfc9479 for > >>>>> application-identifier-bit-mask grouping > >>>>> > >>>>> # l-flag: can be set to true or false > >>>>> > >>>>> OLD: > >>>>> leaf l-flag { > >>>>> type boolean; > >>>>> description > >>>>> "Legacy Flag. When set, … > >>>>> } > >>>>> > >>>>> NEW: > >>>>> leaf l-flag { > >>>>> type boolean; > >>>>> description > >>>>> "Legacy Flag. When set to true, … > >>>>> } > >>>>> > >>>>> # Missing units statements > >>>>> > >>>>> CURRENT: > >>>>> leaf sabm-length { > >>>>> type uint8; > >>>>> description > >>>>> "Standard Application Identifier Bit Mask Length in > >>>>> octets."; > >>>>> } > >>>>> leaf udabm-length { > >>>>> type uint8; > >>>>> description > >>>>> "User Defined Application Identifier Bit Mask Length > >>>>> in octets."; > >>>>> } > >>>>> > >>>>> Consider adding a units statement rather than having this in > >> the > >>>> description. > >>>>> > >>>>> # Lists and leaf-lists > >>>>> > >>>>> CURRENT: > >>>>> leaf-list sabm-bits { > >>>>> type identityref { > >>>>> base iana-link-attr-apps:igp-link-attr-app; > >>>>> } > >>>>> description > >>>>> "SABM bits list. This list will contain > >>>>> identities for the bits which are set in the > >>>>> SABM bits."; > >>>>> } > >>>>> > >>>>> RFC 9907 says: > >>>>> > >>>>> List identifiers SHOULD be singular with the surrounding > >>>> container > >>>>> name plural. Similarly, "leaf-list" identifiers SHOULD be > >>>> singular. > >>>>> > >>>>> NEW: > >>>>> leaf-list sabm-bit { > >>>>> type identityref { > >>>>> base iana-link-attr-apps:igp-link-attr-app; > >>>>> } > >>>>> description > >>>>> "SABM bits list. This list will contain > >>>>> identities for the bits which are set to 1 in the > >>>>> SABM bits."; > >>>>> } > >>>>> > >>>>> ## (also fixed s/set/set to 1) > >>>> > >>>> > >>>> Fixed. > >>>> > >>>>> > >>>>> ## There are several such constructs that need to be fixed. > >> I’m > >>>> not > >>>>> listing all these, but please check. > >>>>> > >>>>> # Not only configuration, but also for retrieval > >>>>> > >>>>> CURRENT: > >>>>> /* Configuration */ > >>>>> > >>>>> Please update to “Management” or something similar. > >>>> > >>>> Fixed. > >>>> > >>>>> > >>>>> ## Idem > >>>>> > >>>>> OLD: This augments IS-IS protocol configuration > >>>>> NEW: This augments IS-IS protocol management > >>>>> > >>>>> ## Idem > >>>>> > >>>>> OLD: This augments IS-IS interface configuration > >>>>> NEW: This augments IS-IS interface management > >>>>> > >>>>> # m-bit > >>>>> > >>>>> CURRENT: > >>>>> identity m-bit { > >>>>> base fad-flags; > >>>>> description > >>>>> "M bit, when set, the flex-algo specific prefix and > >> ASBR > >>>>> metric MUST be used for inter-area and external prefix > >>>>> calculation."; > >>>>> } > >>>>> > >>>>> Same comments as l-flag > >>>> > >>>> Fixed. > >>>> > >>>> > >>>> > >>>>> > >>>>> # Embedded references in the description > >>>>> > >>>>> CURRENT: > >>>>> description > >>>>> "Extended administrative group as defined in RFC > >>>> 7308."; > >>>>> } > >>>>> > >>>>> Please use a reference statement for this (and similar) > >>>> > >>>> Fixed. > >>>> > >>>> > >>>>> > >>>>> # Applies when enabled to true > >>>>> > >>>>> OLD: > >>>>> leaf advertise-definition { > >>>>> type boolean; > >>>>> default "true"; > >>>>> description > >>>>> "Enable to advertise the flex-algo definition."; > >>>>> } > >>>>> > >>>>> NEW/ > >>>>> leaf advertise-definition { > >>>>> type boolean; > >>>>> default "true"; > >>>>> description > >>>>> "When set to true, enables to advertise the flex- > >>>> algo > >>>>> definition."; > >>>>> } > >>>> > >>>> Fixed. > >>>> > >>>>> > >>>>> # Specification? > >>>>> > >>>>> CURRENT: > >>>>> "Flex-algo identifier which is not supported by the > >>>> IS-IS > >>>>> instance. A value not in the inclusive range of 128- > >>>> 255 > >>>>> is indicative of an invalid FAD algorithm > >>>> specification."; > >>>>> > >>>>> Which specification? > >>>>> > >>>>> # Update Security considerations to cover the notifications > >>>>> > >>>>> # Two modules > >>>>> > >>>>> OLD: This document registers a URI in the IETF XML registry > >>>>> NEW: This document registers two URIs in the IETF XML registry > >>>>> > >>>>> OLD: This document registers the YANG module > >>>>> NEW: This document registers the YANG modules > >>>> > >>>> Fixed. > >>>> > >>>>> > >>>>> # This dependency can be avoided as the normative source of > >> the > >>>>> IANA-maintained module is the IANA registry itself. > >>>>> > >>>>> CURRENT: > >>>>> 7.1. Normative References > >>>>> > >>>>> [I-D.ietf-lsr-ospf-flex-algo-yang] > >>>>> Qu, Y. and A. Lindem, "YANG Data Model for OSPF > >>>>> Application-Specific Link Attributes and Flexible > >>>>> Algorithm", Work in Progress, Internet-Draft, > >>>> draft-ietf- > >>>>> lsr-ospf-flex-algo-yang-07, 30 March 2026, > >>>>> > >>>> > >> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > >>>> Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lsr- > >>>> > >> &data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cea4d618efe204c1e2 > >>>> > >> 1ac08ded2e75e71%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63918 > >>>> > >> 0088329489010%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYi > >>>> > >> OiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7 > >>>> > >> C0%7C%7C%7C&sdata=PN6UWp8HCtlyv7ATByNiBl5z%2B7jkI7satDSjYYa5gWw%3D > >>>> &reserved=0 > >>>>> ospf-flex-algo-yang-07>. > >>>>> > >>>>> # Not Normative: Please move the following to Informative > >>>>> > >>>>> CURRENT: > >>>>> 7.1. Normative References > >>>>> > >>>>> [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell > >>>> (SSH) > >>>>> Authentication Protocol", RFC 4252, DOI > >>>> 10.17487/RFC4252, > >>>>> January 2006, > >>>> > >> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > >>>> Fwww.rfc- > >>>> > >> editor.org%2Finfo%2Frfc4252&data=05%7C02%7Cmohamed.boucadair%40ora > >>>> > >> nge.com%7Cea4d618efe204c1e21ac08ded2e75e71%7C90c7a20af34b40bfbc48b > >>>> > >> 9253b6f5d20%7C0%7C0%7C639180088329505352%7CUnknown%7CTWFpbGZsb3d8e > >>>> > >> yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo > >>>> > >> iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=zG%2BiE9LUUYlf1YSPrWI > >>>> LfPp4JmgHhzbL%2BUdVDEnvMCo%3D&reserved=0>. > >>>>> > >>>>> [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, > >>>> J., Ed., > >>>>> and A. Bierman, Ed., "Network Configuration > >>>> Protocol > >>>>> (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June > >>>> 2011, > >>>>> > >>>> > >> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > >>>> Fwww.rfc- > >>>> > >> editor.org%2Finfo%2Frfc6241&data=05%7C02%7Cmohamed.boucadair%40ora > >>>> > >> nge.com%7Cea4d618efe204c1e21ac08ded2e75e71%7C90c7a20af34b40bfbc48b > >>>> > >> 9253b6f5d20%7C0%7C0%7C639180088329516872%7CUnknown%7CTWFpbGZsb3d8e > >>>> > >> yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo > >>>> > >> iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=OpYbR9B%2BNhmzyMcz0Nb > >>>> QSi01%2F1Ztk7kC5h%2FJh%2FOC%2BaY%3D&reserved=0>. > >>>>> > >>>>> [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, > >>>> "RESTCONF > >>>>> Protocol", RFC 8040, DOI 10.17487/RFC8040, January > >>>> 2017, > >>>>> > >>>> > >> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > >>>> Fwww.rfc- > >>>> > >> editor.org%2Finfo%2Frfc8040&data=05%7C02%7Cmohamed.boucadair%40ora > >>>> > >> nge.com%7Cea4d618efe204c1e21ac08ded2e75e71%7C90c7a20af34b40bfbc48b > >>>> > >> 9253b6f5d20%7C0%7C0%7C639180088329527043%7CUnknown%7CTWFpbGZsb3d8e > >>>> > >> yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo > >>>> > >> iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=b7FbdAhd3cLgVZ%2FDTsA > >>>> jyiaxfmWgzu8kvUGUYj9dbAo%3D&reserved=0>. > >>>>> > >>>>> [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) > >>>> Protocol > >>>>> Version 1.3", RFC 8446, DOI 10.17487/RFC8446, > >>>> August 2018, > >>>>> > >>>> > >> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > >>>> Fwww.rfc- > >>>> > >> editor.org%2Finfo%2Frfc8446&data=05%7C02%7Cmohamed.boucadair%40ora > >>>> > >> nge.com%7Cea4d618efe204c1e21ac08ded2e75e71%7C90c7a20af34b40bfbc48b > >>>> > >> 9253b6f5d20%7C0%7C0%7C639180088329537054%7CUnknown%7CTWFpbGZsb3d8e > >>>> > >> yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo > >>>> > >> iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=aXKO0twCPf5ooRMM%2BAN > >>>> KgJpUs63UxIj%2BXGMnVPVE5Dg%3D&reserved=0>. > >>>>> > >>>>> [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A > >> UDP- > >>>> Based > >>>>> Multiplexed and Secure Transport", RFC 9000, > >>>>> DOI 10.17487/RFC9000, May 2021, > >>>>> > >>>> > >> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > >>>> Fwww.rfc- > >>>> > >> editor.org%2Finfo%2Frfc9000&data=05%7C02%7Cmohamed.boucadair%40ora > >>>> > >> nge.com%7Cea4d618efe204c1e21ac08ded2e75e71%7C90c7a20af34b40bfbc48b > >>>> > >> 9253b6f5d20%7C0%7C0%7C639180088329546983%7CUnknown%7CTWFpbGZsb3d8e > >>>> > >> yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo > >>>> > >> iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=y9ZPFZmW77XJts3NbMGiy > >>>> %2FAFhslca3mQdzyR3QdXWi4%3D&reserved=0>. > >>>> > >>>> Fixed. > >>>> > >>>> > >>>>> > >>>>> Hope this helps. > >>>> > >>>> Mostly, though we should avoid validation of read-only data > >>>> received in IS-IS TLVs and sub-TLVs. > >>>> > >>>> Thanks, > >>>> Acee > >>>> > >>>> > >>>> > >>>>> > >>>>> Cheers, > >>>>> Med > >>>>> > >>>>> > >>>>> > >>> > >>> > >> __________________________________________________________________ > >> __________________________________________ > >>> Ce message et ses pieces jointes peuvent contenir des > >> informations confidentielles ou privilegiees et ne doivent donc > >>> pas etre diffuses, exploites ou copies sans autorisation. Si > >> vous avez recu ce message par erreur, veuillez le signaler > >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les > >> messages electroniques etant susceptibles d'alteration, > >>> Orange decline toute responsabilite si ce message a ete altere, > >> deforme ou falsifie. Merci. > >>> > >>> This message and its attachments may contain confidential or > >> privileged information that may be protected by law; > >>> they should not be distributed, used or copied without > >> authorisation. > >>> If you have received this email in error, please notify the > >> sender and delete this message and its attachments. > >>> As emails may be altered, Orange is not liable for messages that > >> have been modified, changed or falsified. > >>> Thank you. > > > > > ____________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme > ou falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and > delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > > Thank you. > > >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
