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]
