Hi Med, Great! Hopefully, this will be the beginning of consistent terminology.
I've also incorporated some comments on the telechat updates that I've incorporated. we'll work on the IS-IS draft this weekend. Thanks, Acee > On Apr 4, 2025, at 8:59 AM, mohamed.boucad...@orange.com wrote: > > Acee, > > I think that you have this right, IMO. > > Cheers, > Med > > PS: Not reviewing in detail as I still need to do a full check to update by > DISCUSS ballot. Thanks. > >> -----Message d'origine----- >> De : Acee Lindem <acee.i...@gmail.com> >> Envoyé : vendredi 4 avril 2025 14:04 >> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> >> Cc : Mahesh Jethanandani <mjethanand...@gmail.com>; >> netmod@ietf.org; The IESG <i...@ietf.org> >> Objet : Re: data model vs module Again (RE: Mahesh Jethanandani's >> No Objection on draft-ietf-ospf-sr-yang-37: (with COMMENT)) >> >> >> At the risk of needing to change it again, I've applied the >> guidance in the -42 version of the OSPF SR MPLS YANG Data Model: >> >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F >> datatracker.ietf.org%2Fdoc%2Fdraft-ietf-ospf-sr- >> yang%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C513ecab78d >> 8c4b9f219908dd7370ec6e%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0% >> 7C638793651014584155%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd >> WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ% >> 3D%3D%7C0%7C%7C%7C&sdata=%2B46C4Ro9XlYbt9XDegsqy62rmFnEF%2F2wrgpJM >> 7ELON4%3D&reserved=0 >> >> I hope we are done. >> >> Thanks, >> Acee >> >>> On Apr 4, 2025, at 7:32 AM, Acee Lindem <acee.i...@gmail.com> >> wrote: >>> >>> Hi Med, Mahesh, >>> >>> Given the definitions in your draft, referring the "YANG Data >> Model" as a whole should be in draft title, abstract, and high- >> level statements. >>> >>> You have deprecated the term "YANG data module" in favor of >> "YANG module" and this should be used when referring to a specific >> self-contained module. >>> >>> Does everyone agree with this guidance? I'm ok with it and would >> like to put an end, once and for all, blanket comments to change >> all instances of "YANG Data Model" to "YANG Data Module" with no >> clear understanding of the semantics of the two terms. I've added >> the IESG back to the cc: list so we can get some consistency here. >>> >>> Other than, changing "YANG data module" to "YANG module", what >> are you suggesting for >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F >> datatracker.ietf.org%2Fdoc%2Fdraft-ietf-ospf-sr- >> yang%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C513ecab78d >> 8c4b9f219908dd7370ec6e%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0% >> 7C638793651014599279%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd >> WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ% >> 3D%3D%7C0%7C%7C%7C&sdata=2VntMk%2BaAi65wp3kk%2B4pPTsMqayGBnfoBfPR1 >> 79xt1E%3D&reserved=0? >>> >>> >>> Thanks, >>> Acee >>> >>>> On Apr 4, 2025, at 1:28 AM, mohamed.boucad...@orange.com wrote: >>>> >>>> Hi Acee, all, >>>> (moving this discussion to netmod, hence cci everyone else) >>>> >>>> The guidance so far was to avoid "data module" and "YANG >> model". Benoît has more context on this when he was OPS AD. >>>> >>>> Let's us use this discussion to converge on some clear guidance >> for every one. >>>> >>>> Here is a first draft of guidance I suggest we add to 8407bis. >> This inspires from the guidance I shared earlier in this thread: >>>> >>>> >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F >> aut >>>> hor- >> tools.ietf.org%2Fapi%2Fiddiff%3Furl_1%3Dhttps%3A%2F%2Fnetmod-wg.g >>>> ithub.io%2Frfc8407bis%2Fdraft-ietf-netmod- >> rfc8407bis.txt%26url_2%3Dht >>>> tps%3A%2F%2Fnetmod-wg.github.io%2Frfc8407bis%2Fmodel-vs- >> module%2Fdraf >>>> t-ietf-netmod- >> rfc8407bis.txt&data=05%7C02%7Cmohamed.boucadair%40orang >>>> >> e.com%7C513ecab78d8c4b9f219908dd7370ec6e%7C90c7a20af34b40bfbc48b92 >> 53b >>>> >> 6f5d20%7C0%7C0%7C638793651014607501%7CUnknown%7CTWFpbGZsb3d8eyJFbX >> B0e >>>> >> U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCI >> sIl >>>> >> dUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=tTRCn82BitJLUgs3b1NIhuBBWaVYBbTp >> uk6 >>>> 7L6zf9xA%3D&reserved=0 >>>> >>>> Do we need to say more/less? Is this still confusing? >> Obviously, text >>>> is welcome and makes the editor happy ;-) >>>> >>>> Cheers, >>>> Med >>>> >>>>> -----Message d'origine----- >>>>> De : Acee Lindem <acee.i...@gmail.com> Envoyé : jeudi 3 avril >> 2025 >>>>> 23:13 À : Mahesh Jethanandani <mjethanand...@gmail.com> Cc : >> The >>>>> IESG <i...@ietf.org>; draft-ietf-ospf-sr-y...@ietf.org; lsr- >> chairs >>>>> <lsr-cha...@ietf.org>; lsr <l...@ietf.org>; Christian Hopps >>>>> <cho...@chopps.org> Objet : Re: Mahesh Jethanandani's No >> Objection >>>>> on draft-ietf-ospf- >>>>> sr-yang-37: (with COMMENT) >>>>> >>>>> >>>>> Here what ChatGTP says (so it has to be right 😎): >>>>> >>>>> The difference between a YANG data model and a YANG data >> module lies >>>>> in their scope and usage: >>>>> • YANG Data Model: >>>>> • A data model defines the structure and constraints of >>>>> configuration and state data for a specific system or >> protocol. >>>>> • It provides an abstract representation of how data >> should be >>>>> organized, regardless of its implementation. >>>>> • It can consist of multiple modules and submodules that >>>>> together describe a network configuration or operational >> state. >>>>> • YANG Data Module: >>>>> • A module is a self-contained YANG file that defines a >>>>> specific part of a data model. >>>>> • It includes definitions of data nodes (like >> containers, >>>>> lists, and leaf nodes), RPCs, notifications, and >> augmentations. >>>>> • A module may import or include other modules or >> submodules >>>>> to extend its functionality. >>>>> Example: >>>>> • YANG Data Model: The entire OpenConfig BGP model, which >> consists >>>>> of multiple modules defining BGP configuration and operational >>>>> state. >>>>> • YANG Data Module: The openconfig-bgp.yang file, which >>>>> specifically defines BGP-related configurations. >>>>> In short, a YANG data model is the broader concept, while a >> YANG >>>>> module is an actual implementation unit within a model. >>>>> >>>>> >>>>> I believe I have made this distinction in the latest version >> of the >>>>> draft: >>>>> >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>>> datatracker.ietf.org%2Fdoc%2Fdraft-ietf-ospf-sr- >>>>> >> yang%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ce269fce709 >>>>> >> 84491ee6ab08dd72f496bb%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0% >>>>> >> 7C638793117023476441%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd >>>>> >> WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ% >>>>> >> 3D%3D%7C0%7C%7C%7C&sdata=o72AnR17w9EHpADb4TbAaecH0TtTERka%2Bc%2BTZ >>>>> Anof80%3D&reserved=0 as I refer to the "YANG data model" when >>>>> referring to the YANG model as a whole and "YANG data module" >> when >>>>> referring to the ietf-ospf-sr-mpls data module. >>>>> >>>>> The only change I might make is: >>>>> >>>>> OLD: >>>>> The defined YANG data model is an augmentation to the OSPF >> YANG >>>>> data model [RFC9129]. >>>>> >>>>> NEW: >>>>> The defined ospf-sr-mpls data module provides augmentations >> to >>>>> ietf-ospf data module defined in "YANG Data Model for the >> OSPF >>>>> Protocol" >>>>> [RFC9129]. >>>>> >>>>> I also feel there are people (not mentioning any names) >> providing >>>>> guidance on this distinction with no clear semantics other >> than >>>>> replace "data model" with "data module". >>>>> >>>>> Thanks, >>>>> Acee >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> On Apr 3, 2025, at 4:43 PM, Acee Lindem <acee.i...@gmail.com> >>>>> wrote: >>>>>> >>>>>> Hi Mahesh, et al, >>>>>> >>>>>>> On Apr 3, 2025, at 4:08 PM, Acee Lindem >> <acee.i...@gmail.com> >>>>> wrote: >>>>>>> >>>>>>> Hi Mahesh, >>>>>>> >>>>>>>> On Apr 3, 2025, at 3:54 PM, Mahesh Jethanandani >>>>> <mjethanand...@gmail.com> wrote: >>>>>>>> >>>>>>>> Hi Acee, >>>>>>>> >>>>>>>>> On Apr 1, 2025, at 2:40 PM, Acee Lindem >> <acee.i...@gmail.com> >>>>> wrote: >>>>>>>>> >>>>>>>>> Hi Mahesh, >>>>>>>>> >>>>>>>>>> On Apr 1, 2025, at 5:14 PM, Mahesh Jethanandani via >>>>> Datatracker <nore...@ietf.org> wrote: >>>>>>>>>> >>>>>>>>>> Mahesh Jethanandani has entered the following ballot >>>>> position for >>>>>>>>>> draft-ietf-ospf-sr-yang-37: No Objection >>>>>>>>>> >>>>>>>>>> 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>>>>>>>> >>>>> >> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw >> ww >>>>> >> .ietf.org%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C513ec >> ab >>>>> >> 78d8c4b9f219908dd7370ec6e%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7 >> C0 >>>>> >> %7C638793651014620677%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRy >> dW >>>>> >> UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3 >> D% >>>>> >> 3D%7C0%7C%7C%7C&sdata=mXJysPx%2FpzQ3%2Fw67yEn%2FVbKYVr20qXcYin%2FJ >> kV >>>>> >> boPBI%3D&reserved=0%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandlin >> g- >>>>> ballo >>>>>>>>>> t- >>>>> >> positions%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ce26 >>>>>>>>>> >>>>> >> 9fce70984491ee6ab08dd72f496bb%7C90c7a20af34b40bfbc48b9253b6f5d20%7 >>>>>>>>>> >>>>> >> C0%7C0%7C638793117023493729%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcG >>>>>>>>>> >>>>> >> kiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldU >>>>>>>>>> >>>>> >> IjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=TvgQkJLD8Jk%2B3RXO4gZSFd6uHeGmKgpD >>>>>>>>>> sWK%2Fw3uBKr4%3D&reserved=0 for more information about >> how >>>>> to >>>>>>>>>> handle DISCUSS and COMMENT positions. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The document, along with other ballot positions, can be >>>>> found here: >>>>>>>>>> >>>>> >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>>>>>>>> datatracker.ietf.org%2Fdoc%2Fdraft-ietf-ospf-sr- >>>>> yang%2F&data=05%7C >>>>>>>>>> >>>>> >> 02%7Cmohamed.boucadair%40orange.com%7Ce269fce70984491ee6ab08dd72f4 >>>>>>>>>> >>>>> >> 96bb%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6387931170235024 >>>>>>>>>> >>>>> >> 46%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA >>>>>>>>>> >>>>> >> wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C >>>>>>>>>> >>>>> >> &sdata=Yn5qKrO4%2FddFJRx6L%2FeIm1fSnJXKmEyoh%2BUMRvbwt7M%3D&reserv >>>>>>>>>> ed=0 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> --------------------------------------------------------- >> --- >>>>> ------ >>>>>>>>>> ---- >>>>>>>>>> COMMENT: >>>>>>>>>> --------------------------------------------------------- >> --- >>>>> ------ >>>>>>>>>> ---- >>>>>>>>>> >>>>>>>>>> Section 1, paragraph 0 >>>>>>>>>>> This document defines a YANG data model [RFC7950] that >> can >>>>> be >>>>>>>>>>> used to manage OSPFv2 extensions for Segment Routing >>>>> [RFC8665] >>>>>>>>>>> and OSPFv3 extensions for Segment Routing [RFC8666] for >> the >>>>> MPLS >>>>>>>>>>> data plane. It is an augmentation to the OSPF YANG data >>>>> model [RFC9129]. >>>>>>>>>> >>>>>>>>>> This is a similar comment to the YANG module for SR on >> ISIS. >>>>> There >>>>>>>>>> seems to be some confusion on the use of the terms "YANG >>>>> module" >>>>>>>>>> and "YANG data model" in this document. A "YANG data >> model" >>>>> refers >>>>>>>>>> to a collection of YANG modules and submodules that >> together >>>>>>>>>> define a structured representation configuration, >>>>> operational >>>>>>>>>> data, notifications, and RPCs for a given system or >>>>> protocol, >>>>>>>>>> while a "YANG module" refers to a specific YANG file >> (.yang) >>>>> defining a set of nodes (container, list, leaf, etc.) that >> represent >>>>> configuration or state data. >>>>>>>>>> Moreover, a YANG module can be independent and augment >> other >>>>> modules. >>>>>>>>>> >>>>>>>>>> Based on that definition, what you seem to be defining is >> a >>>>> YANG >>>>>>>>>> module more than a YANG data model. Can that be reflected >>>>> consistently in this document? >>>>>>>>> >>>>>>>>> I'll fix this. >>>>>>>> >>>>>>>> I was referring to this comment which you agreed to fix, >> not >>>>> just in this document but presumably in the ISIS document as >> well. >>>>> Looking at the -41 version of the document, I did not see any >>>>> changes to reflect this change, unless I am missing something. >>>>>>> >>>>>>> >>>>>>> I removed raw-sid from the sid-tlv-encoding based on your >>>>> comments. Are you referring to "YANG model" vs "YANG data >> module"? >>>>> I went back and forth on these a number of time based on >> definition >>>>> Med provided - please send me a diff of which ones need to be >>>>> changed. >>>>>>> >>>>>>> Note that the title of the draft is "A YANG Data Model for >> OSPF >>>>> Segment Routing over the MPLS Data Plane". >>>>>> >>>>>> >>>>>> And if I look through the references, we already have these >> data >>>>> models: >>>>>> >>>>>> >>>>>> [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data >> Model >>>>> for >>>>>> Routing Management (NMDA Version)", RFC 8349, DOI >>>>> 10.17487/RFC8349, >>>>>> March 2018, >>>>>> >>>>> >> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 >>>>> Fwww.rfc- >>>>> >> editor.org%2Finfo%2Frfc8349&data=05%7C02%7Cmohamed.boucadair%40ora >>>>> >> nge.com%7Ce269fce70984491ee6ab08dd72f496bb%7C90c7a20af34b40bfbc48b >>>>> >> 9253b6f5d20%7C0%7C0%7C638793117023510793%7CUnknown%7CTWFpbGZsb3d8e >>>>> >> yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo >>>>> >> iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=oZTIGsOtVZ802TBNdM3H% >>>>> 2FkMjgy9ZkJrlL%2BLsqLBed6Y%3D&reserved=0>. >>>>>> >>>>>> [RFC9020] Litkowski, S., Qu, Y., Lindem, A., Sarkar, P., and >> J. >>>>>> Tantsura, "YANG Data Model for Segment Routing", RFC 9020, >> DOI >>>>>> 10.17487/RFC9020, May 2021, >>>>>> >>>>> >> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 >>>>> Fwww.rfc- >>>>> >> editor.org%2Finfo%2Frfc9020&data=05%7C02%7Cmohamed.boucadair%40ora >>>>> >> nge.com%7Ce269fce70984491ee6ab08dd72f496bb%7C90c7a20af34b40bfbc48b >>>>> >> 9253b6f5d20%7C0%7C0%7C638793117023519210%7CUnknown%7CTWFpbGZsb3d8e >>>>> >> yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo >>>>> >> iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=UY%2FmHYHL46l4f2X7Ouj >>>>> F8m1GdojqhKlXCUyUNWCLVB8%3D&reserved=0>. >>>>>> >>>>>> [RFC9129] Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. >> Lindem, >>>>> "YANG >>>>>> Data Model for the OSPF Protocol", RFC 9129, DOI >>>>> 10.17487/RFC9129, >>>>>> October 2022, >>>>>> >>>>> >> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 >>>>> Fwww.rfc- >>>>> >> editor.org%2Finfo%2Frfc9129&data=05%7C02%7Cmohamed.boucadair%40ora >>>>> >> nge.com%7Ce269fce70984491ee6ab08dd72f496bb%7C90c7a20af34b40bfbc48b >>>>> >> 9253b6f5d20%7C0%7C0%7C638793117023527378%7CUnknown%7CTWFpbGZsb3d8e >>>>> >> yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo >>>>> >> iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=500%2B%2Bh8Phdc3fa9Ai >>>>> l%2FP8OU2mxfwyFQmPAkg9WCh4Vg%3D&reserved=0>. >>>>>> >>>>>> >>>>>> [RFC9587] Lindem, A., Palani, S., and Y. Qu, "YANG Data Model >>>>> for >>>>>> OSPFv3 Extended Link State Advertisements (LSAs)", RFC 9587, >> DOI >>>>>> 10.17487/RFC9587, June 2024, >>>>>> >>>>> >> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 >>>>> Fwww.rfc- >>>>> >> editor.org%2Finfo%2Frfc9587&data=05%7C02%7Cmohamed.boucadair%40ora >>>>> >> nge.com%7Ce269fce70984491ee6ab08dd72f496bb%7C90c7a20af34b40bfbc48b >>>>> >> 9253b6f5d20%7C0%7C0%7C638793117023535417%7CUnknown%7CTWFpbGZsb3d8e >>>>> >> yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo >>>>> >> iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=NwTQvTjDbf72YT7e8my0L >>>>> jr%2F28SVc6L1R4EbpxYYKUA%3D&reserved=0>. >>>>>> >>>>>> >>>>>> My take was that we should refer the "YANG Data Model" when >>>>> referring to the model as a whole and "YANG Data Module" when >>>>> specifically referring to the ietf-ospf-sr-mpls.yang data >> module. >>>>> This is what has been done the -41 version. >>>>>> >>>>>> Like I said in a previous E-mail, the guidance given is >>>>> especially ambiguous when there is a single data module in the >> data >>>>> model. >>>>>> >>>>>> Thanks, >>>>>> Acee >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> I'm not an author on the IS-IS SR YANG model but Yingzhen >> and I >>>>> have been in communication since the start and we will sync up >> IS- >>>>> IS to the IESG comments and changes made for OSPF. >>>>>>> >>>>>>> Thanks, >>>>>>> Acee >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>> Mahesh Jethanandani >>>>>>>> mjethanand...@gmail.com >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >>>> >> __________________________________________________________________ >> ___ >>>> _______________________________________ >>>> 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. _______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
