IThe ID submission tool includes the same error.
Yang Validation for draft-ietf-ospf-sr-yang-38
draft-ietf-ospf-sr-yang-38.txt:
xym 0.9.0:
Extracting 'ietf-ospf-sr-mpls'
Removed 0 empty lines
ietf-ospf-sr-m...@2025-04-02.yang:
pyang 2.6.1: pyang --verbose --ietf -p {libs} {model}:
# module search path:
/tmp/tmp75xd40_l:/a/www/ietf-ftp/yang/rfcmod/:/a/www/ietf-ftp/yang/draftmod/:/a/www/ietf-ftp/yang/ianamod/:/a/www/ietf-ftp/yang/catalogmod/:.:/usr/local/share/yang/modules
# read /tmp/tmp75xd40_l/ietf-ospf-sr-m...@2025-04-02.yang (CL)
# read /usr/local/share/yang/modules/ietf/ietf-inet-types.yang
# read /a/www/ietf-ftp/yang/draftmod/ietf-inet-ty...@2024-10-21.yang
# read /usr/local/share/yang/modules/ietf/ietf-routing-types.yang
# read /a/www/ietf-ftp/yang/rfcmod/ietf-routing-ty...@2017-12-04.yang
# read /usr/local/share/yang/modules/ietf/ietf-yang-types.yang
# read /a/www/ietf-ftp/yang/draftmod/ietf-yang-ty...@2024-10-21.yang
# read /usr/local/share/yang/modules/iana/iana-routing-types.yang
# read /a/www/ietf-ftp/yang/ianamod/iana-routing-ty...@2025-02-18.yang
# read /usr/local/share/yang/modules/ietf/ietf-routing.yang
# read /a/www/ietf-ftp/yang/rfcmod/ietf-rout...@2018-03-13.yang
# read /usr/local/share/yang/modules/ietf/ietf-interfaces.yang
# read /a/www/ietf-ftp/yang/rfcmod/ietf-interfa...@2018-02-20.yang
# read /a/www/ietf-ftp/yang/rfcmod/ietf-segment-routing-com...@2021-05-26.yang
# read /a/www/ietf-ftp/yang/rfcmod/ietf-segment-routing-m...@2021-05-26.yang
# read /a/www/ietf-ftp/yang/rfcmod/ietf-segment-rout...@2021-05-26.yang
# read /a/www/ietf-ftp/yang/rfcmod/ietf-o...@2022-10-19.yang
# read /usr/local/share/yang/modules/ietf/ietf-key-chain.yang
# read /a/www/ietf-ftp/yang/rfcmod/ietf-key-ch...@2017-06-15.yang
# read /usr/local/share/yang/modules/ietf/ietf-netconf-acm.yang
# read /a/www/ietf-ftp/yang/rfcmod/ietf-netconf-...@2018-02-14.yang
# read /a/www/ietf-ftp/yang/rfcmod/ietf-bfd-ty...@2022-09-22.yang
# read /a/www/ietf-ftp/yang/draftmod/iana-bfd-ty...@2025-03-02.yang
# read /a/www/ietf-ftp/yang/rfcmod/ietf-ospfv3-extended-...@2024-06-07.yang
/tmp/tmp75xd40_l/ietf-ospf-sr-m...@2025-04-02.yang:89: warning: RFC 8407:
Appendix B: The text about which RFC this module is part of seems to be missing
or is not correct (see pyang --ietf-help for details).
yanglint SO 1.10.17: yanglint --verbose -p {tmplib} -p {rfclib} -p {draftlib}
-p {ianalib} -p {cataloglib} {model} -i:
No validation errors
> On Apr 2, 2025, at 7:16 AM, mohamed.boucad...@orange.com wrote:
>
> Re-,
>
> Not sure which change you made. FWIW, you can seen the output of compiling
> your file with that statement removed at:
>
> https://github.com/boucadair/dummy-misc/actions/runs/14218233724/job/39839769040:
> no error/warning.
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : Acee Lindem <acee.i...@gmail.com>
>> Envoyé : mercredi 2 avril 2025 13:04
>> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>
>> Cc : Mahesh Jethanandani <mjethanand...@gmail.com>; The IESG
>> <i...@ietf.org>; draft-ietf-ospf-sr-y...@ietf.org; lsr-
>> cha...@ietf.org; lsr <lsr@ietf.org>; Christian Hopps
>> <cho...@chopps.org>
>> Objet : Re: Mahesh Jethanandani's No Objection on draft-ietf-ospf-
>> sr-yang-37: (with COMMENT)
>>
>> Removing causes errors with the current version of pyang
>>
>> MacBook-Pro:ietf-ospf-yang acee$ pyang --ietf-help ietf-ospf-sr-
>> mpls.yang
>>
>> Validates the module or submodule according to the IETF rules
>> found in RFC 8407.
>>
>> The module's or submodule's description statement must contain the
>> following text:
>>
>> Copyright (c) <year> IETF Trust and the persons identified as
>> authors of the code. All rights reserved.
>>
>> Redistribution and use in source and binary forms, with or
>> without modification, is permitted pursuant to, and subject
>> to
>> the license terms contained in, the Revised BSD License set
>> forth in Section 4.c of the IETF Trust's Legal Provisions
>> Relating to IETF Documents
>>
>> (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
>> Ftrustee.ietf.org%2Flicense-
>> info&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cea1e040250114
>> 3ac31cb08dd71d630b3%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6
>> 38791886944953016%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs
>> IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%
>> 3D%7C0%7C%7C%7C&sdata=MvrhPifUFesmVGGmZRVcNx79aBOAw879kQPBPEloWUY%
>> 3D&reserved=0).
>>
>> An IETF module (but not an IANA module) must also contain the
>> following text:
>>
>> This version of this YANG module is part of RFC XXXX
>>
>> (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
>> Fwww.rfc-
>> editor.org%2Finfo%2FrfcXXXX&data=05%7C02%7Cmohamed.boucadair%40ora
>> nge.com%7Cea1e0402501143ac31cb08dd71d630b3%7C90c7a20af34b40bfbc48b
>> 9253b6f5d20%7C0%7C0%7C638791886944970690%7CUnknown%7CTWFpbGZsb3d8e
>> yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo
>> iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=2YiChBAbw80lmahuDKmb4
>> eajtMQDcRleJrtTe7%2FVa9U%3D&reserved=0); see the RFC itself
>> for full legal notices.
>>
>> If any description statement in the module or submodule contains
>> RFC 2119 key words, the module's or submodule's description
>> statement must contain the following text:
>>
>> 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.
>>
>>
>>> On Apr 2, 2025, at 6:08 AM, Acee Lindem <acee.i...@gmail.com>
>> wrote:
>>>
>>> Ok - I'll remove it.
>>>
>>> Thanks,
>>> Acee
>>>
>>>> On Apr 2, 2025, at 2:08 AM, mohamed.boucad...@orange.com wrote:
>>>>
>>>> Hi Acee,
>>>>
>>>> One quick comment on this part:
>>>>
>>>>>>
>>>>>> Section 3, paragraph 9
>>>>>>> This version of this YANG module is part of RFC XXXX;
>>>>> see
>>>>>>> the RFC itself for full legal notices.
>>>>>>
>>>>>> BTW, is there an instruction for the RFC Editor on what to do
>>>>> with RFC XXXX?
>>>>>
>>>>> This is present is other YANG modules. For example, ietf-
>> ospf.yang
>>>>> in RFC 9129.
>>>>>
>>>>
>>>> That's not a reason to have it :-)
>>>>
>>>> I know that some raised comments about this in the past (Tom
>> Petch, if I'm not mistaken). Also, I don' think this mention
>> brings much as what is important with the one under the revision.
>>>>
>>>> I suggest to remove that part and align with the template at:
>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>> datatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-netmod-rfc8407bis-
>> 22%23name-template-for-ietf-
>> modules&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cea1e040250
>> 1143ac31cb08dd71d630b3%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%
>> 7C638791886944979541%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd
>> WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%
>> 3D%3D%7C0%7C%7C%7C&sdata=t5LA3Sfn7K4phWjp52xAalFQ9J42AkA%2FWcW6v2a
>> Dasc%3D&reserved=0.
>>
>> Removing causes errors with pyang (maybe I need an update):
>>
>> MacBook-Pro:ietf-ospf-yang acee$ pyang --ietf-help ietf-ospf-sr-
>> mpls.yang
>>
>> Validates the module or submodule according to the IETF rules
>> found in RFC 8407.
>>
>> The module's or submodule's description statement must contain the
>> following text:
>>
>> Copyright (c) <year> IETF Trust and the persons identified as
>> authors of the code. All rights reserved.
>>
>> Redistribution and use in source and binary forms, with or
>> without modification, is permitted pursuant to, and subject
>> to
>> the license terms contained in, the Revised BSD License set
>> forth in Section 4.c of the IETF Trust's Legal Provisions
>> Relating to IETF Documents
>>
>> (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
>> Ftrustee.ietf.org%2Flicense-
>> info&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cea1e040250114
>> 3ac31cb08dd71d630b3%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6
>> 38791886944988482%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs
>> IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%
>> 3D%7C0%7C%7C%7C&sdata=IR4WQ6bwoXw1Q1ZnhYMBSUOsGKoPY2fnUoFEmGPQPoo%
>> 3D&reserved=0).
>>
>> An IETF module (but not an IANA module) must also contain the
>> following text:
>>
>> This version of this YANG module is part of RFC XXXX
>>
>> (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
>> Fwww.rfc-
>> editor.org%2Finfo%2FrfcXXXX&data=05%7C02%7Cmohamed.boucadair%40ora
>> nge.com%7Cea1e0402501143ac31cb08dd71d630b3%7C90c7a20af34b40bfbc48b
>> 9253b6f5d20%7C0%7C0%7C638791886944997706%7CUnknown%7CTWFpbGZsb3d8e
>> yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo
>> iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=MKtf8tt1Nuixk6xpM7PwH
>> kEzzeIb6ADtHUid8GNOcEY%3D&reserved=0); see the RFC itself
>> for full legal notices.
>>
>> If any description statement in the module or submodule contains
>> RFC 2119 key words, the module's or submodule's description
>> statement must contain the following text:
>>
>> 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.
>>
>> I've left it out.
>>
>> Thanks,
>> Acee
>>
>>
>>
>>
>>
>>
>>>>
>>>> Thank you.
>>>>
>>>> Cheers,
>>>> Med
>>>>
>>>>> -----Message d'origine-----
>>>>> De : Acee Lindem <acee.i...@gmail.com> Envoyé : mardi 1 avril
>> 2025
>>>>> 23:40 À : Mahesh Jethanandani <mjethanand...@gmail.com> Cc :
>> The
>>>>> IESG <i...@ietf.org>; draft-ietf-ospf-sr-y...@ietf.org;
>>>>> lsr-cha...@ietf.org; lsr <lsr@ietf.org>; Christian Hopps
>>>>> <cho...@chopps.org> Objet : Re: Mahesh Jethanandani's No
>> Objection
>>>>> on draft-ietf-ospf-
>>>>> sr-yang-37: (with COMMENT)
>>>>>
>>>>>
>>>>> 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.)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -------------------------------------------------------------
>> ---
>>>>> ------
>>>>>> 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.
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Section 3, paragraph 9
>>>>>>> This version of this YANG module is part of RFC XXXX;
>>>>> see
>>>>>>> the RFC itself for full legal notices.
>>>>>>
>>>>>> BTW, is there an instruction for the RFC Editor on what to do
>>>>> with RFC XXXX?
>>>>>
>>>>> This is present is other YANG modules. For example, ietf-
>> ospf.yang
>>>>> in RFC 9129.
>>>>>
>>>>>
>>>>>>
>>>>>> Section 3, paragraph 28
>>>>>>> grouping sid-tlv-encoding {
>>>>>>> description
>>>>>>> "SID TLV Encoding - 20-bit label or 32-bit SID whose
>>>>>>> interpretation is dependent on the TLV length (3 for
>> an
>>>>>>> MPLS label or 4 for a 32-bit value) or the TLV V-Flag
>>>>> and
>>>>>>> L-Flag settings:
>>>>>>>
>>>>>>> If the V-Flag is set to 0 and L-Flag is set to 0:
>>>>>>> The SID/Index/Label field is a 4-octet index
>> defining
>>>>>>> the offset in the SID/Label space advertised by this
>>>>>>> router.
>>>>>>>
>>>>>>> If V-Flag is set to 1 and L-Flag is set to 1: The
>>>>>>> ID/Index/Label field is a 3-octet local label where
>>>>> the
>>>>>>> 20 rightmost bits are used for encoding the label
>>>>> value.";
>>>>>>> reference
>>>>>>> "RFC 8665: OSPF Extensions for Segment Routing,
>> Section
>>>>> 5
>>>>>>> RFC 8666: OSPFv3 Extensions for Segment Routing,
>>>>> Section 3";
>>>>>>> leaf sid-raw {
>>>>>>> type uint32;
>>>>>>> description
>>>>>>> "Raw SID value - labels are in the rightmost 20 bits
>>>>> of
>>>>>>> the value";
>>>>>>> }
>>>>>>> choice sid-value {
>>>>>>> case label-sid {
>>>>>>> leaf label-value {
>>>>>>> type uint32 {
>>>>>>> range "0 .. 1048575";
>>>>>>> }
>>>>>>> description
>>>>>>> "A 20-bit MPLS Label";
>>>>>>> }
>>>>>>> }
>>>>>>> case offset-sid {
>>>>>>> leaf offset-value {
>>>>>>> type uint32;
>>>>>>> description
>>>>>>> "Offset into a label space advertised by this
>>>>> router.";
>>>>>>> }
>>>>>>> }
>>>>>>> description
>>>>>>> "Choice of either a 20-bit MPLS lable or 32-bit
>>>>> offset into
>>>>>>> an advertised label space.";
>>>>>>> }
>>>>>>> }
>>>>>>
>>>>>> I might be completely off, but what is the relationship
>> between
>>>>>> 'sid-raw' and the choice statement of 'sid-value'? Is the
>> choice
>>>>>> statement being used to determine what value 'sid-raw' will
>>>>> carry? If
>>>>>> that is the case, YANG is being used to model a particular
>> wire
>>>>>> format. Tell me that is not what is happening here. I will
>> note
>>>>> that
>>>>>> Med has pointed out something similar as part of his DISCUSS
>> in
>>>>> other parts of the model.
>>>>>
>>>>> This the same value although the choice is the interpreted
>> value and
>>>>> the raw-sid is the value from the TLV without any
>> interpretation. I
>>>>> was thinking both could be useful but adamantly opposed to
>> removing
>>>>> it.
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Section 4, paragraph 9
>>>>>>> Some of the readable data nodes in this YANG module may be
>>>>> considered
>>>>>>> sensitive or vulnerable in some network environments. It is
>>>>> thus
>>>>>>> important to control read access (e.g., via get, get-config,
>>>>> or
>>>>>>> notification) to these data nodes. Specifically, the
>>>>> following
>>>>>>> subtrees and data nodes have particular sensitivities/
>>>>>>> vulnerabilities:
>>>>>>
>>>>>> The paragraph seems to imply that specific subtrees and data
>>>>> nodes
>>>>>> will be identified for vulnerability. Instead, what I see is
>> a
>>>>>> paragraph with some generic description. Did the authors
>> forget
>>>>> to
>>>>>> identify particular nodes or subtrees?
>>>>>
>>>>>
>>>>>>
>>>>>> No reference entries found for these items, which were
>> mentioned
>>>>> in the text:
>>>>>> [draft-ietf-rtgwg-segment-routing-ti-lfa].
>>>>>
>>>>> What do you mean? It references the read-only Link State
>> Database
>>>>> augmentations. Are you asking me to resist every LSA?
>>>>>
>>>>>
>>>>> The module ietf-ospf-sr-mpls augments base OSPF module Link
>> State
>>>>> Database (LSDB) with various TLVs. Knowledge of these data
>> nodes
>>>>> can be used to attack other routers in the OSPF domain.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> -------------------------------------------------------------
>> ---
>>>>> ------
>>>>>> ---------
>>>>>> NIT
>>>>>> -------------------------------------------------------------
>> ---
>>>>> ------
>>>>>> ---------
>>>>>>
>>>>>> All comments below are about very minor potential issues that
>>>>> you may
>>>>>> choose to address in some way - or ignore - as you see fit.
>> Some
>>>>> were
>>>>>> flagged by automated tools (via
>>>>>>
>>>>>
>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>> gith
>>>>>> ub.com%2Flarseggert%2Fietf-
>>>>>
>> reviewtool&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cc52bc89
>>>>>
>> 4a0484bb229f408dd7165db15%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7
>>>>>
>> C0%7C638791404462869141%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn
>>>>>
>> RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy
>>>>>
>> fQ%3D%3D%7C0%7C%7C%7C&sdata=k9wKjyoZj0KdSmuzHGFdXRx314Er2rqWFvYUnZ
>>>>> d54BA%3D&reserved=0), so there will likely be some false
>> positives.
>>>>> There is no need to let me know what you did with these
>> suggestions.
>>>>>>
>>>>>> Section 3, paragraph 10
>>>>>>> reference
>>>>>>> "RFC XXXX";
>>>>>>
>>>>>> s/RFC XXXX/RFC XXXX: A YANG Data Model for OSPF Segment
>> Routing
>>>>> for
>>>>>> the MPLS Data Plane/
>>>>>
>>>>> Will fix.
>>>>>
>>>>> Thanks,
>>>>> Acee
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>> __________________________________________________________________
>> ___
>>>> _______________________________________
>>>> 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 -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org
