Hi Med, Can you please check the and clear your hopefully clear your DISCUSS.
Thanks, Acee > On Jul 2, 2026, at 2:29 AM, [email protected] wrote: > > Hi Yingzhen, > Thanks for taking of the comments. I checked the diff 08 vs. 11. We are > almost there. > Please find below the pending comments: > # YANG Validation indicates a warning. Please check. > # Now that we add a new name column, we need to add an update tag RFC8665, > RFC9350, and RFC 9843 (+ usual mention in the abstract). > # Some narrative text is needed to help digest the structures of the IETF > modules. No need to be lengthy, though. > # We are still missing notes to ask removal of the IANA-maintained modules > from the final version of the RFC. Please add these. > ## To simplify RFC Editor work, I suggest that you move all these IANA > modules to appendixes and add notes to remove them from the final. > ## To be consistent with that actions, I suggest that you also make this > change in the abstract > OLD: It also specifies the initial version of IANA-maintained YANG modules > for … > NEW: It also creates the initial version of IANA-maintained YANG modules for > … > # IANA IGP Link Attribute Applications Module > ## The description does not mirror what is in the registry. Please update > the description to echo what is under the name of the registry. > ## There is no description in the link registry. We need at least these > changes in the IANA actions > (1) > OLD: > The name of the "identity" is a > lowercase version of the application description as provided in the > registry with spaces replaced with hyphens, i.e., "-"s. and ending > with "-app". In order to form the YANG "identity", the name of the > application is taken from the beginning the registry description, not > including text in parenthesis. > NEW: > The name of the "identity" is a > lowercase version of the application description as provided in the > Name field of the registry with spaces replaced with hyphens, i.e., "-"s, > and ending > with "-app". In order to form the YANG "identity", the name of the > application is taken from the beginning the name, not > including text in parenthesis. > (2) > OLD: > "description": Replicates the description text when a new value > is added. > NEW: > "description": Replicates the Name text when a new value > is added. > # OSPF TLVs: rfc9350#section-12 points to rfc8920#section-5, but there is > not provision in the module to cover the link sub attributes. Can you please > clarify? > # Please delete the following in Section 5 > CURRENT: > This YANG model conforms to the Network Management > Datastore Architecture (NMDA) as described in RFC 8342. > # Update this part of the IETF description > 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://www.iana.org/assignments/yang-parameters). > This version of this YANG module is part of RFC XXXX; see > the RFC itself for full legal notices. > # Security cons section > Please add the following right before your current first paragraph of > Section 7 > NEW: > This section is modeled after the template described in Section 3.7.1 > of [RFC9907]. > # I would move the action to update existing registries to separate > subsections and position those before YANG actions. > CURRENT: > IANA is requested to add a "Name" column to the "IGP Algorithm Types" > registry. The values for the "Name" column for existing Algorithm > Types are: > … > and > CURRENT: > IANA is requested to add a "Name" column to the "IGP Metric-Type" > registry. The values for the "Name" column for existing Algorithm > Types are: > .. > # Table 2: Although this won’t be mirrored in the YANG module, the table > should provide a name for these assignment: > 128-255 Reserved for User-Defined Metric [RFC9843] Yes > # Fix broken references > OLD: > | When this registry is modified, the YANG module "iana-igp-algo- > | types" Section 2 must be updated as defined in RFC XXXX. > NEW: > | When this registry is modified, the YANG module "iana-igp-algo- > | types" [IANA-YANG-PARAMETERS] must be updated as defined in RFC XXXX. > OLD: > | When this registry is modified, the YANG module "iana-metric- > | types" Section 3 must be updated as defined in RFC XXXX. > NEW: > | When this registry is modified, the YANG module "iana-metric- > | types" [IANA-YANG-PARAMETERS] must be updated as defined in RFC XXXX. > OLD: > | When this registry is modified, the YANG module "iana-igp-link- > | attr-apps" must be updated as defined in RFC XXXX Section 4 . > NEW: > | When this registry is modified, the YANG module "iana-igp-link- > | attr-apps" [IANA-YANG-PARAMETERS] must be updated as defined in RFC > XXXX. > # The example in Appendix B is broken (several issues). Please use yanglint > or yangson to validate against the data model. > # I’m not listing very minor things such using singular for lists and > leaf-lists. > Cheers, > Med > De : Yingzhen Qu <[email protected]> > Envoyé : jeudi 2 juillet 2026 04:29 > À : Acee Lindem <[email protected]> > Cc : BOUCADAIR Mohamed INNOV/NET <[email protected]>; 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, > 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]: > >>> > >>> 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. > > ____________________________________________________________________________________________________________ > 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]
