Re-, Please see inline.
Cheers, Med > -----Message d'origine----- > De : Acee Lindem <[email protected]> > Envoyé : vendredi 18 avril 2025 17:19 > À : BOUCADAIR Mohamed INNOV/NET <[email protected]> > Cc : The IESG <[email protected]>; [email protected]; > [email protected]; lsr <[email protected]>; Christian Hopps > <[email protected]> > Objet : Re: Mohamed Boucadair's Discuss on draft-ietf-ospf-sr-yang- > 34: (with DISCUSS and COMMENT) > > > Hi Med, > > See inline. > > > On Apr 18, 2025, at 6:59 AM, [email protected] wrote: > > > > Hi Acee, > > > > Thank you for handling the comments in a timely manner and > implementing the changes. > > > > I made a check using diff draft-ietf-ospf-sr-yang-34 vs draft- > ietf-ospf-sr-yang-46. Great to see that both ISIS/OPSF spec follow > the same approach for the sid encoding part. > > > > There are still some very few comments: > > > > (1) I don't find Inter-Area Flag in 8666: > > > > CURRENT: > > identity ia-flag { > > base extended-prefix-range-flag; > > description > > "Inter-Area flag."; > > reference > > "RFC 8665: OSPF Extensions for Segment Routing, Section 4 > > RFC 8666: OSPFv3 Extensions for Segment Routing, Section > 5"; > > } > > It is not needed for OSPFv3 since the SR extensions can be added to > the Extended-LSAs and there is are separate LSAs for inter-area > advertisement. > I'll remove the reference to RFC 8666. > [Med] OK, that confirms I had in mind. Leave it to you whether we need to mention in the description that this is for OSFPv2. > > > > > > Can you please double check? If that flag is only defined in > 8665, we may consider controlling its use with a feature. > > Let's not get carried away - this is a bit in read-only data. > Adding a feature would be ludicrous. > > > > > (2) I suggest we delete as this is not allowed with the range > statement (multiple occurrences): > > > > "Topologies range from 0-127 and return of any other value would > indicate an error." > > Sure. > [Med] ACK. > > > (3) Please complete this part with the sensitive data nodes: > > > > CURRENT: > > 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: > > Adding every data node in every LSA is just a waste of time and > space. I'll address them generically as is done in > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fd > atatracker.ietf.org%2Fdoc%2Fdraft-ietf-idr-bgp- > model%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C1432c097c0 > eb4cb6f95308dd7e8c58bf%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7 > C638805863428180944%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU > sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D% > 3D%7C0%7C%7C%7C&sdata=GIPFj%2BkLh0LjpQxqdNPeK6UUcqQYiRl%2F%2FsOGnGZ > Q15I%3D&reserved=0 > [Med] Sound good. > > > > > > (4) Please fix the references to follow this guidance from > RFC8407bis: > > > > Note: [RFC8341] (or a future RFC that replaces it) MUST be > listed as > > normative references. > > > > By default, [RFC4252], [RFC6241], [RFC8040], [RFC8446], > [RFC9000], > > and RFC AAAA (or future RFCs that replace any of them) are > listed > > as informative references unless normatively cited in other > > sections of the document that specifies the YANG module. > > RFC 8341 does have a normative reference in the current version - > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fd > atatracker.ietf.org%2Fdoc%2Fdraft-ietf-ospf-sr- > yang%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C1432c097c0e > b4cb6f95308dd7e8c58bf%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C > 638805863428194311%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs > IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3 > D%7C0%7C%7C%7C&sdata=rfTXZ3Mmn3lX1l1ZO3NhfxvBKQjxay%2FDYrVrJAoHbGE% > 3D&reserved=0 > > What do you mean? > [Med] I meant move RFC4252 and RFC9000 from normative to informative. Thanks. > Thanks, > Acee > > > > > Please let me know when a new version is available so that I can > clear my DISCUSS. > > > > Thank you. > > > > Cheers, > > Med > > > >> -----Message d'origine----- > >> De : BOUCADAIR Mohamed INNOV/NET > >> Envoyé : dimanche 30 mars 2025 15:22 > >> À : Acee Lindem <[email protected]> Cc : The IESG > <[email protected]>; > >> [email protected]; [email protected]; lsr > >> <[email protected]>; Christian Hopps <[email protected]> Objet : RE: > >> Mohamed Boucadair's Discuss on draft-ietf-ospf-sr-yang- > >> 34: (with DISCUSS and COMMENT) > >> > >> Hi Acee, > >> > >> Thanks. Will do a full check together with the IS-IS spec. > >> > >> One quick comment about the example, I confirm that it has many > >> pbs: it does not adhere at least to the following from RFC7951: > >> > >> A namespace-qualified member name MUST be used for all members > of a > >> top-level JSON object and then also whenever the namespaces of > the > >> data node and its parent node are different. In all other > cases, > >> the > >> simple form of the member name MUST be used. > >> > >> + > >> > >> An "identityref" value is represented as a string -- the name > of > >> an > >> identity. If the identity is defined in a module other than > the > >> leaf > >> node containing the identityref value, the namespace-qualified > >> form > >> (Section 4) MUST be used. Otherwise, both the simple and > >> namespace- > >> qualified forms are permitted. > >> > >> Better to validate this using tools. Noted that you will do. > >> > >> As a general note, I hope we can have this integrated as part of > >> idnits because otherwise identifying issues depends on reviewers > >> eyes ;-) > >> > >> Cheers, > >> Med > >> > >>> -----Message d'origine----- > >>> De : Acee Lindem <[email protected]> Envoyé : dimanche 30 > mars > >> 2025 > >>> 14:09 À : BOUCADAIR Mohamed INNOV/NET > >> <[email protected]> > >>> Cc : The IESG <[email protected]>; draft-ietf-ospf-sr- > [email protected]; > >> lsr- > >>> [email protected]; lsr <[email protected]>; Christian Hopps > >>> <[email protected]> Objet : Re: Mohamed Boucadair's Discuss on > >>> draft-ietf-ospf-sr-yang-34: > >>> (with DISCUSS and COMMENT) > >>> > >>> > >>> Hi Mohamed, > >>> > >>> I've addressed the non-DISCUSS level comments in -36. I've > >>> incorporated most but not all of your comments. > >>> > >>>> > >>>> > >>>> > >>>> -------------------------------------------------------------- > - > >> ----- > >>> -- > >>>> COMMENT: > >>>> -------------------------------------------------------------- > - > >> ----- > >>> -- > >>>> > >>>> # Abstract: "configure" is covered by "manage" (remember the > >> FCAPS > >>>> functions) > >>>> > >>>> OLD: > >>>> This document defines a YANG data module that can be used to > >>>> configure and manage OSPF Extensions for Segment Routing for > >> the > >>> MPLS > >>>> data plane. > >>>> > >>>> NEW : > >>>> This document defines a YANG data module that can be used to > >>>> manage OSPF Extensions for Segment Routing (SR) for the MPLS > >>>> data plane. > >>>> > >>>> # Introduction: Simplify + remove "configure" as this is > >> covered by > >>> "manage" > >>>> > >>>> OLD: > >>>> This document defines a YANG data model [RFC7950] that can be > >> used > >>> to > >>>> configure and 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]. > >>>> > >>>> NEW: > >>>> This document defines a YANG data model [RFC7950] that can be > >> used > >>> to > >>>> manage Segment Routing (SR) for OSPFv2 [RFC8665] > >>>> and OSPFv3 [RFC8666] for the MPLS data > >>>> plane. It is an augmentation to the OSPF YANG data model > >>> [RFC9129]. > >>> > >>> Fixed for both. > >>> > >>> > >>>> > >>>> # Section 2 > >>>> > >>>> ## (redundant) I would delete the following as this was stated > >> few > >>> lines above. > >>>> > >>>> CURRENT: > >>>> It is an augmentation of the OSPF base model. > >>>> > >>>> ## The module is not only for configuration, but for state > >>> retrieval. > >>>> The document says that it adheres to the NMDA ;-) > >>>> > >>>> Please update the following accordingly: > >>>> > >>>> CURRENT: > >>>> The OSPF SR YANG module requires support for the base segment > >>> routing > >>>> module [RFC9020], which defines the global segment routing > >>>> configuration independent of any specific routing protocol > >>>> configuration, and support of OSPF base model [RFC9129] which > >>> defines > >>>> basic OSPF configuration and state. > >>> > >>> Fixed to a separate section with narrative text. > >>> > >>>> > >>>> ## Long tree diagram > >>>> > >>>> Please move the full tree to an appendix but consider snippets > >> to > >>> help > >>>> readers go through the model. > >>>> > >>>> Refer to Section 3.4 of 8407bis for more guidance. > >>> > >>> Done. > >>> > >>>> > >>>> # Section 2.1: Check references > >>>> > >>>> CURRENT: > >>>> [RFC2328], [RFC4750], [RFC4915], [RFC5340], [RFC5643], > >> [RFC5838], > >>>> [RFC6991], [RFC8102], [RFC8294], [RFC8343], [RFC8476], > >> [RFC8349], > >>>> [RFC9587], and [I-D.ietf-rtgwg-segment-routing-ti-lfa] are > >>> referenced > >>>> in the YANG data model. > >>>> > >>>> For example, I failed to find where these ones are cited > >> [RFC4750], > >>>> [RFC5643], [RFC5838], [RFC8343 ], [RFC8476]. > >>> > >>> Fixed. > >>> > >>> > >>>> > >>>> # Section 2.2 > >>>> > >>>> ## Please use the template at > >>>> > >>> > >> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fd > %2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C1432c097c0eb4cb > 6f95308dd7e8c58bf%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6388 > 05863428203047%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYi > OiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C > 0%7C%7C%7C&sdata=f7gmqo%2BFQBVvZrv3CF1pmj14pRGzZrSi3XWyClbCxug%3D&r > eserved=0 > >> ata > >>>> tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-netmod-rfc8407bis- > >>> 22%23name > >>>> -template-for-ietf- > >>> modules&data=05%7C02%7Cmohamed.boucadair%40orange.c > >>>> > >>> > >> > om%7Cdd93fc8f55524169027408dd6f83b410%7C90c7a20af34b40bfbc48b9253b6 > >> f5d > >>>> > >>> > >> > 20%7C0%7C0%7C638789333642674106%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1 > >> hcG > >>>> > >>> > >> > kiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI > >> joy > >>>> > >>> > >> > fQ%3D%3D%7C0%7C%7C%7C&sdata=o1APFE%2FrerQ%2FsiTEyKAY9z9n5tXn8v4kymY > >> EDf > >>>> Iw%2FPg%3D&reserved=0 > >>>> > >>>> ## Description issues > >>>> > >>>> CURRENT: > >>>> This YANG module defines the generic configuration > >>>> and operational state for OSPF Segment Routing (SR), > >> which > >>>> is common across all of the vendor implementations. It > >> is > >>>> intended that the module will be extended by vendors to > >>>> define vendor-specific OSPF Segment Routing > >> configuration > >>>> and operational parameters for the MPLS data plane. > >>>> > >>>> * How you checked this part "is common across all of the > vendor > >>>> implementations"? > >>>> > >>>> * I would remove the last sentence. It is weird to make > >> assumption > >>>> about what proprietary extensions in a STD spec! > >>> > >>> Ok. > >>> > >>> > >>>> > >>>> ## Consistent referencing style: The module include a mix of > >> styles > >>>> for the reference statements. Please update accordingly. For > >>> example, > >>>> > >>>> OLD: "RFC 6991 - Common YANG Data Types"; > >>>> NEW: "RFC 6991: Common YANG Data Types"; > >>> > >>> Fixed > >>> > >>>> > >>>> ## Lack of references: > >>>> > >>>> For example, consider adding the following for all prefix-sid- > >> flag > >>>> > >>>> NEW: > >>>> reference > >>>> "RFC 8665: OSPF Extensions for Segment Routing, Section 5 > >>>> RFC 8666: OSPFv3 Extensions for Segment Routing, Section > >> 6"; > >>> > >>> This module already had more references than most but I've > added > >> more. > >>> > >>> > >>>> > >>>> ## Some description are copied from the base spec, while the > >>> statement > >>>> does not make sense for a given type. > >>>> > >>>> For example, the following is included for an identity, but > 'if > >> set, > >>>> ..' does not make sense for an identity. This is not a flag > >> bit. An > >>>> example is provided below (but other similar constructs are > >> included > >>>> in the module) > >>>> > >>>> OLD: > >>>> "Inter-Area flag. If set, advertisement is of > >>>> inter-area type."; > >>>> NEW: > >>>> "Inter-Area flag."; > >>> > >>> Fixed. > >>> > >>>> > >>>> ## Lack of mapping between some identities and the flag names > >> as > >>>> defined in the base spec. For example, the description for vi- > >> flag > >>>> should indicate that this corresponds to the V-Flag as there > is > >> no > >>> VI-Flag in 8665/8666: > >>> > >>> This is due to pyang not being able to disambiguate the > duplicate > >>> identities with different base identities. > >>> > >>> > >>>> > >>>> OLD: > >>>> "Value/Index flag."; > >>>> > >>>> NEW: > >>>> "Value/Index flag. Corresponds to the Adj-SID V-Flag."; > >>>> reference > >>>> "RFC 8665: OSPF Extensions for Segment Routing, Section > >> 6.1 > >>>> RFC 8666: OSPFv3 Extensions for Segment Routing, Section > >>> 7.1"; > >>>> > >>>> Idem, please indicate that lo-flag corresponds to the L-Flag > >> defined > >>>> in > >>>> 8665/8666 as there is no LO-Flag in 8665/8666. > >>>> > >>>> OLD: > >>>> "Local/Global flag."; > >>>> > >>>> NEW: > >>>> "Local/Global flag. Corresponds to the Adj-SID L-Flag."; > >>>> reference > >>>> "RFC 8665: OSPF Extensions for Segment Routing, Section > >> 6.1 > >>>> RFC 8666: OSPFv3 Extensions for Segment Routing, Section > >>> 7.1"; > >>> > >>> Fixed. > >>> > >>>> > >>>> ## No need to repeat the parent node prefix. There are many > >>>> occurrences of this in the module. > >>> > >>> I'm going to leave these as is. In these cases, the list > elements > >> are > >>> TLVs. > >>> > >>> > >>>> > >>>> OLD: list prefix-sid-sub-tlv { > >>>> NEW: list prefix-sid { > >>>> > >>>> OLD: list extended-prefix-range-tlv { > >>>> NEW: list extended-prefix-range { > >>>> > >>>> OLD: container extended-prefix-range-flags { > >>>> NEW: container flags { > >>>> > >>>> Etc. > >>>> > >>>> ## Use Singular for list/leaf-list per rfc8407bis, for > example: > >>>> > >>>> OLD: leaf-list flags { > >>>> NEW: leaf-list flag { > >>>> > >>>> There are many occurrences in the text. > >>> > >>> Fixed. > >>> > >>> > >>> > >>> > >>>> > >>>> ## Defaults: Please provide an authoritative reference where > >> the > >>>> default is defined + indicate the meaning of this default. > >>>> > >>>> For example, it is not clear for the definition the meaning of > >> this > >>> value: > >>>> > >>>> CURRENT: > >>>> leaf priority { > >>>> type uint8; > >>>> default "128"; > >>> > >>> In the context of the container, the default should be obvious. > >>> > >>> > >>>> > >>>> ## Restrict using range: restrict the range rather than having > >> this > >>> in > >>>> the description. > >>>> > >>>> CURRENT: > >>>> leaf mt-id { > >>>> type uint8; > >>>> description > >>>> "Multi-topology ID. Topologies range from 0-127 and > >>>> return of any other value would indicate an > >> error."; > >>>> > >>>> # Section 3: Security template > >>>> > >>>> Please follow the template defined in > >>>> > >>> > >> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fd > %2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C1432c097c0eb4cb > 6f95308dd7e8c58bf%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6388 > 05863428211803%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYi > OiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C > 0%7C%7C%7C&sdata=qUvEYStjLLssCL%2BMPifydnJF7mVWHqnRAs70cqZfr6g%3D&r > eserved=0 > >> ata > >>>> tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-netmod-rfc8407bis- > >>> 22%23name > >>>> -security-considerations- > >>> sect&data=05%7C02%7Cmohamed.boucadair%40orang > >>>> > >>> > >> > e.com%7Cdd93fc8f55524169027408dd6f83b410%7C90c7a20af34b40bfbc48b925 > >> 3b6 > >>>> > >>> > >> > f5d20%7C0%7C0%7C638789333642691638%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0 > >> eU1 > >>>> > >>> > >> > hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIl > >> dUI > >>>> > >>> > >> > joyfQ%3D%3D%7C0%7C%7C%7C&sdata=928yJgTF2gV2E%2BVUOkMzQ57WY0F1p3%2Fr > >> y0H > >>>> NiL533kk%3D&reserved=0 > >>> > >>> Fixed > >>> > >>>> > >>>> # Section 5: Indicate whether this is maintained by IANA or > not > >>>> > >>>> OLD: > >>>> name: ietf-ospf-sr-mpls > >>>> namespace: urn:ietf:params:xml:ns:yang:ietf-ospf-sr- > >> mpls > >>>> prefix: ospf-sr-mpls > >>>> reference: RFC XXXX > >>>> > >>>> NEW: > >>>> name: ietf-ospf-sr-mpls > >>>> namespace: urn:ietf:params:xml:ns:yang:ietf-ospf-sr- > >> mpls > >>>> prefix: ospf-sr-mpls > >>>> maintained by IANA? N > >>>> reference: RFC XXXX > >>>> > >>>> # Section 6: Issues with classifying references > >>>> > >>>> RFC6241, RFC6242, RFC8040, RFC8343, RFC8446, and RFC8476 are > >> cited > >>> as > >>>> normative, while they shouldn't. Please move those to be > listed > >> as > >>> Informative. > >>> > >>> Fixed. RFC8343 and RFC8476 were removed. > >>> > >>>> > >>>> # Appendix > >>>> > >>>> ## Redundant examples > >>>> > >>>> Do we really need to have the xml example given that the JSON > >>> encoding > >>>> for the same example is provided? > >>> > >>> I'd be glad to only have json. Leaving in -36 > >>> > >>> > >>>> > >>>> ## Broken JSON example > >>>> > >>>> Please validate the example using yanglint, etc. > >>> > >>> We'll discuss among the co-authors but I believe this was > >> validated. > >>> It looks like all you did was replace the module prefixes with > >> the > >>> module names. > >>> > >>> Thanks > >>> Acee > >>> > >>> > >>> > >>>> > >>>> OLD: > >>>> { > >>>> "routing": { > >>>> "router-id": "1.1.1.1", > >>>> "control-plane-protocols": { > >>>> "control-plane-protocol": { > >>>> "type": "ospf:ospfv2", > >>>> "name": "OSPFv2", > >>>> "ospf": { > >>>> "areas": { > >>>> "area": { > >>>> "area-id": "0.0.0.0", > >>>> "interfaces": { > >>>> "interface": { > >>>> "name": "eth0", > >>>> "segment-routing": { > >>>> "adjacency-sid": { > >>>> "adj-sids": { > >>>> "value": 3888 > >>>> } > >>>> } > >>>> } > >>>> } > >>>> } > >>>> } > >>>> }, > >>>> "segment-routing": { > >>>> "enabled": true > >>>> }, > >>>> "protocol-srgb": { > >>>> "srgb": { > >>>> "lower-bound": 4000, > >>>> "upper-bound": 5000 > >>>> } > >>>> } > >>>> } > >>>> } > >>>> } > >>>> } > >>>> } > >>>> > >>>> NEW: > >>>> { > >>>> "ietf-routing:routing": { > >>>> "router-id": "1.1.1.1", > >>>> "control-plane-protocols": { > >>>> "control-plane-protocol": { > >>>> "type": "ietf-ospf:ospfv2", > >>>> "name": "OSPFv2", > >>>> "ietf-ospf:ospf": { > >>>> "areas": { > >>>> "area": { > >>>> "area-id": "0.0.0.0", > >>>> "interfaces": { > >>>> "interface": { > >>>> "name": "eth0", > >>>> "ietf-ospf-sr-mpls:segment-routing": { > >>>> "adjacency-sid": { > >>>> "adj-sids": { > >>>> "value": 3888 > >>>> } > >>>> } > >>>> } > >>>> } > >>>> } > >>>> } > >>>> }, > >>>> "ietf-ospf-sr-mpls:segment-routing": { > >>>> "enabled": true > >>>> }, > >>>> "ietf-ospf-sr-mpls:protocol-srgb": { > >>>> "srgb": { > >>>> "lower-bound": 4000, > >>>> "upper-bound": 5000 > >>>> } > >>>> } > >>>> } > >>>> } > >>>> } > >>>> } > >>>> } > >>>> > >>>> Cheers, > >>>> Med > >>>> > >>>> > >>>> > > > > > ___________________________________________________________________ > _________________________________________ > > Ce message et ses pieces jointes peuvent contenir des > informations confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous > avez recu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, > deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or > privileged information that may be protected by law; > > they should not be distributed, used or copied without > authorisation. > > If you have received this email in error, please notify the > sender and delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that > have been modified, changed or falsified. > > Thank you. > > ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
