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]>; [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. _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
