[Teas] Re: New Version Notification for draft-ietf-teas-rfc8776-update-14.txt

Italo Busi <Italo.Busi@huawei.com> Tue, 12 November 2024 13:01 UTC

Return-Path: <Italo.Busi@huawei.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2153DC15108B for <teas@ietfa.amsl.com>; Tue, 12 Nov 2024 05:01:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Level:
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1z8wYhRgC_i for <teas@ietfa.amsl.com>; Tue, 12 Nov 2024 05:01:10 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37943C14F707 for <teas@ietf.org>; Tue, 12 Nov 2024 05:01:09 -0800 (PST)
Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4XnmhJ1lf3z6K9FW; Tue, 12 Nov 2024 20:59:12 +0800 (CST)
Received: from frapeml500005.china.huawei.com (unknown [7.182.85.13]) by mail.maildlp.com (Postfix) with ESMTPS id 9F437140B2A; Tue, 12 Nov 2024 21:01:06 +0800 (CST)
Received: from frapeml500007.china.huawei.com (7.182.85.172) by frapeml500005.china.huawei.com (7.182.85.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Tue, 12 Nov 2024 14:01:06 +0100
Received: from frapeml500007.china.huawei.com ([7.182.85.172]) by frapeml500007.china.huawei.com ([7.182.85.172]) with mapi id 15.01.2507.039; Tue, 12 Nov 2024 14:01:06 +0100
From: Italo Busi <Italo.Busi@huawei.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "teas@ietf.org" <teas@ietf.org>
Thread-Topic: New Version Notification for draft-ietf-teas-rfc8776-update-14.txt
Thread-Index: AQHbLxZYEBEQaMg4sE6hE+et65nVP7Knz4iQgAUkvQCAAc8MQIAEryKwgAAa4rA=
Date: Tue, 12 Nov 2024 13:01:06 +0000
Message-ID: <23f5ea96e57649609502f3214177d393@huawei.com>
References: <173076507638.238.14305891068967673938@dt-datatracker-5f77bcf4bd-vglkb> <6d839c14e925479599b671b6e0e35b03@huawei.com> <DU2PR02MB101609235F1FABEE0507FB419885D2@DU2PR02MB10160.eurprd02.prod.outlook.com> <57e9f1c643ad4019abb08a61ac7be6a6@huawei.com> <DU2PR02MB10160B03E377B253CF7DD7F2888592@DU2PR02MB10160.eurprd02.prod.outlook.com>
In-Reply-To: <DU2PR02MB10160B03E377B253CF7DD7F2888592@DU2PR02MB10160.eurprd02.prod.outlook.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Method=Standard;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=dbc7b6a1-fb23-4f2f-8d20-03a5a3e19f71;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2024-11-12T09:54:41Z;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20;
x-originating-ip: [10.203.246.202]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Message-ID-Hash: Y3V2ADE52ODTBQIKWJUBVKAXYSU3E56T
X-Message-ID-Hash: Y3V2ADE52ODTBQIKWJUBVKAXYSU3E56T
X-MailFrom: Italo.Busi@huawei.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-teas.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Teas] Re: New Version Notification for draft-ietf-teas-rfc8776-update-14.txt
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/WxUDALj-1LHXWi_Zd_rEFSqshIw>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Owner: <mailto:teas-owner@ietf.org>
List-Post: <mailto:teas@ietf.org>
List-Subscribe: <mailto:teas-join@ietf.org>
List-Unsubscribe: <mailto:teas-leave@ietf.org>

Hi Med,

What about adding the following sentence?

"For example, for the number of hops metric for which a measurement unit is not applicable"

Thanks, Italo

> -----Original Message-----
> From: mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>
> Sent: martedì 12 novembre 2024 10:57
> To: Italo Busi <Italo.Busi@huawei.com>; teas@ietf.org
> Subject: RE: New Version Notification for draft-ietf-teas-rfc8776-update-14.txt
> 
> Hi Italo,
> 
> Thanks for taking care of the comments.
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Italo Busi <Italo.Busi@huawei.com> Envoyé : samedi 9 novembre
> > 2024 12:13 À : BOUCADAIR Mohamed INNOV/NET
> > <mohamed.boucadair@orange.com>; teas@ietf.org Objet : RE: New Version
> > Notification for draft-ietf-teas-rfc8776- update-14.txt
> >
> >
> > Thanks Med
> >
> > I have updated the draft in github to address most of your comments.
> > You can check the diff at:
> >
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > Fauthor-tools.ietf.org%2Fdiff%3Fdoc_1%3Ddraft-ietf-teas-rfc8776-
> > update-
> > 14%26url_2%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Ftsaad-
> > dev%2Fte%2Frefs%2Fheads%2Fmaster%2Fdrafts%2Fte-types-
> > update%2Fdraft-ietf-teas-rfc8776-
> >
> update.txt&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C35f03
> 7
> >
> 43b5324ccf4fbd08dd00af9341%7C90c7a20af34b40bfbc48b9253b6f5d20%7C
> 0
> > %7C0%7C638667476300995946%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0
> eU1hcGk
> > iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldU
> >
> IjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=fJlu8LBEMlX9Vh6MB2FOfqajgBtRa3e
> X3
> > 4NJeGMz38o%3D&reserved=0
> >
> > These are the comments for which I would need more input from the TEAS
> > WG:
> >
> > > * " The derived identities SHOULD describe the ..": I wouldn't
> > > surprised if you receive a comment about why this is not a
> > MUST. You
> > > may explain an exception in the text if you have one in mind.
> >
> > An exception is the number of hops which do not have a measurement
> > unit, so it cannot be a MUST. Spelling out the exception is not future
> > proof: we do not wish to precluding future definitions of other
> > identities similar which do not have measurement units.
> >
> 
> [Med] I'm afraid you misread my comment. This is not about listing every
> exception but indicating an example of when the SHOULD can be ignored.
> Listing the # of hops as an example would be great.
> 
> As a reminder, RFC2119 says the following:
> 
> 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>    may exist valid reasons in particular circumstances to ignore a
>    particular item, but the full implications must be understood and
>    carefully weighed before choosing a different course.
> 
> > > * I like this text, but is this used by other standard models
> > outside IETF?
> > >
> > > CURRENT:
> > >          The container has been renamed as 'explicit-route-
> > objects'.
> > >          This change is not affecting any IETF standard YANG
> > models
> > >          since this grouping has not yet been used by any YANG
> > model
> > >          defined in existing IETF RFCs.
> > >
> >
> > The text reflects the decision based on the discussion on the
> > list:
> >
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > Fmailarchive.ietf.org%2Farch%2Fmsg%2Fteas%2Fcmf7KsRBxFQZ6oaf-
> >
> mzWTdZxAYQ%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%
> 7C35f
> >
> 03743b5324ccf4fbd08dd00af9341%7C90c7a20af34b40bfbc48b9253b6f5d20%
> >
> 7C0%7C0%7C638667476301021706%7CUnknown%7CTWFpbGZsb3d8eyJFbXB
> 0eU1h
> > cGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsI
> >
> ldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=yy0Y10Irdm9SFG8vuVzgotO1cEN
> NHj
> > y%2FD7XVyJ84Uow%3D&reserved=0
> >
> > IMHO, it is quite unlikely that other SDOs are importing this grouping
> > from RFC 8776 but I do not think we can write anything about this in
> > an IETF draft/RFC so better to keep silent on this point
> 
> [Med] I wasn't asking for any change here but interested to hear if this was
> used outside. Thanks
> 
> >
> > > * I still find identifiers such as "
> > > path-computation-error-destination-unknown-
> > > in-domain" to be toooooo long, but...
> >
> > At this stage, there is nothing I can do.
> >
> 
> [Med] :-)
> 
> > Just a side comment:
> >
> > > * "revision  2024-10-30" and file name should be consistent.
> > Fix the date.
> >
> > This is another example of why I do not like duplicated information to
> > be manually kept updated: this duplicated information quickly gets out
> > of synch if authors or reviewers are not carefully enough to double
> > check it
> >
> > An automatic tool to automatically keep this text in synch or, at
> > least, flag the nit before submission would be very useful
> >
> 
> [Med] Agree.
> 
> > Italo
> >
> > > -----Original Message-----
> > > From: mohamed.boucadair@orange.com
> > <mohamed.boucadair@orange.com>
> > > Sent: venerdì 8 novembre 2024 08:18
> > > To: Italo Busi <Italo.Busi@huawei.com>; teas@ietf.org
> > > Subject: RE: New Version Notification for
> > > draft-ietf-teas-rfc8776-update-14.txt
> > >
> > > Hi Italo,
> > >
> > > Many thanks for the effort put in this document.
> > >
> > > I used a diff vs the original RFC to do a final check:
> > https://author-
> > > tools.ietf.org/diff?doc_1=rfc8776&doc_2=draft-ietf-teas-
> > rfc8776-update
> > > -
> > > 14&wdiff=1
> > >
> > > For the record, I consider the comments I raised as closed.
> > >
> > > FWIW, find below some nits/comments that you can consider for a
> > future
> > > iteration when you will have other reviews:
> > >
> > > * I would invert the ordering of 1.2/1.3 so that mapping with
> > 8776 is
> > > preserved
> > > * Introduction: s/ YANG models and obsoletes/ YANG modules and
> > > obsoletes (or YANG data models and obsoletes)
> > > * Section 3.1: To ease referring by future documents, you may
> > convert
> > > the text starting with " The "xxx" module contains the
> > following "
> > > into subsections
> > > * Idem as previous comment for Section 3.2
> > > * Section 3.1: s/No standard LPS provisioning/No standard LP
> > > provisioning
> > > * " The derived identities SHOULD describe the ..": I wouldn't
> > > surprised if you receive a comment about why this is not a
> > MUST. You
> > > may explain an exception in the text if you have one in mind.
> > > * Don't be restrictive in how this will be used:
> > >
> > > OLD:
> > >    path-computation-error-reason:  A base YANG identity for
> > reporting
> > >       path computation error reasons as defined in Section
> > 3.1.1.
> > >
> > > NEW:
> > >    path-computation-error-reason:  A base YANG identity for
> > indicating
> > >       path computation error reasons as defined in Section
> > 3.1.1.
> > >
> > > (idem in the wording in 3.1.1)
> > >
> > > * These entries are listed as identities, while these are
> > groupings.
> > > Please fix
> > > that:
> > >
> > > CURRENT:
> > >
> > >    The "ietf-te-types" module contains the following YANG
> > reusable
> > >    identities:
> > >    ...
> > >    explicit-route-hop:  A YANG grouping that defines supported
> > explicit
> > >       routes as defined in [RFC3209] and [RFC3477].
> > >    ...
> > >
> > >    encoding-and-switching-type:  This is a common grouping to
> > define the
> > >       LSP encoding and switching types.
> > >
> > > * Explicit this is to clarify what an IANA module is not used
> > here
> > >
> > > OLD:
> > >    The derived identities are defined in the "ietf-te-types"
> > module
> > >    because there are error reasons which are:
> > >
> > > NEW:
> > >    The derived identities are defined in the "ietf-te-types"
> > module
> > >    instead of an IANA-maintained module because there are error
> > > reasons which are:
> > >
> > > * Section 3.2: I would split the identities vs groupings
> > > * I like this text, but is this used by other standard models
> > outside IETF?
> > >
> > > CURRENT:
> > >          The container has been renamed as 'explicit-route-
> > objects'.
> > >          This change is not affecting any IETF standard YANG
> > models
> > >          since this grouping has not yet been used by any YANG
> > model
> > >          defined in existing IETF RFCs.
> > >
> > > * "revision  2024-10-30" and file name should be consistent.
> > Fix the date.
> > > * I still find identifiers such as "
> > > path-computation-error-destination-unknown-
> > > in-domain" to be toooooo long, but...
> > > * " "At least one node identifier MUST be present.";  I don't
> > think
> > > you need the normative language here as you already have a must
> > statement.
> > > * Idem in
> > >
> > > "                 "At least one node identifier and at least
> > one Link
> > >                  Termination Point (LTP) identifier MUST be
> > present."; "
> > >
> > >
> > > Cheers,
> > > Med
> > >
> > >
> > > Orange Restricted
> > >
> > > > -----Message d'origine-----
> > > > De : Italo Busi <Italo.Busi=40huawei.com@dmarc.ietf.org>
> > > > Envoyé : mardi 5 novembre 2024 00:10 À : teas@ietf.org
> > Objet :
> > > > [Teas] FW: New Version Notification for draft-ietf-teas-
> > > > rfc8776-update-14.txt
> > > >
> > > > Dear TEAS WG and chairs,
> > > >
> > > > I have just uploaded an updated version of the draft
> > addressing all
> > > > the comments received during the second Working group last
> > call of
> > > > draft-ietf-teas-rfc8776-update-13 and discussion on the WG
> > mailing
> > > > list
> > > >
> > > > I believe the draft is not ready to go to IESG
> > > >
> > > > Thanks, Italo (on behalf of co-authors/contributors)
> > > >
> > > > > -----Original Message-----
> > > > > From: internet-drafts@ietf.org <internet-drafts@ietf.org>
> > > > > Sent: martedì 5 novembre 2024 01:05
> > > > > To: Aihua Guo <aihuaguo.ietf@gmail.com>; Igor Bryskin
> > > > > <i_bryskin@yahoo.com>; Italo Busi <Italo.Busi@huawei.com>;
> > > > Tarek Saad
> > > > > <tsaad.net@gmail.com>; Xufeng Liu
> > <xufeng.liu.ietf@gmail.com>
> > > > > Subject: New Version Notification for
> > > > > draft-ietf-teas-rfc8776-update-14.txt
> > > > >
> > > > > A new version of Internet-Draft draft-ietf-teas-rfc8776-
> > update-
> > > > 14.txt
> > > > > has been successfully submitted by Italo Busi and posted to
> > the
> > > > IETF repository.
> > > > >
> > > > > Name:     draft-ietf-teas-rfc8776-update
> > > > > Revision: 14
> > > > > Title:    Common YANG Data Types for Traffic Engineering
> > > > > Date:     2024-11-05
> > > > > Group:    teas
> > > > > Pages:    154
> > > > > URL:
> > > >
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > > > Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-teas-rfc8776-
> > update-
> > > >
> > >
> >
> 14.txt&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C26c442cf5
> > > 2
> > > >
> > >
> 2b4778426208dcfd2e4716%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7
> > > C0
> > > > %7C638663622429788248%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> 4wL
> > > jAwMDA
> > > >
> > >
> >
> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdat
> > > >
> > >
> a=hApMC%2Bb%2FKohyTzQJBIZ9ac0tKOzIqFZoVFo14Erf0IM%3D&reserved=0
> > > > > Status:
> > > >
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > > > Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-teas-rfc8776-
> > > >
> > >
> update%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C26c4
> > > 42c
> > > >
> > >
> >
> f522b4778426208dcfd2e4716%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%
> > > >
> > >
> 7C0%7C638663622429807585%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> > > wLjAw
> > > >
> > >
> >
> MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&
> > > s
> > > >
> > >
> data=2%2FJV94ILkIg0Gr6M29gWhYPnsVMFv5%2F7YM9dsZs%2Bs7c%3D&rese
> > > rve
> > > > d=0
> > > > > HTMLized:
> > > > >
> > > >
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > > > Fdata
> > > > > tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-teas-rfc8776-
> > > > &data=05%7C02%
> > > > >
> > > >
> > >
> 7Cmohamed.boucadair%40orange.com%7C26c442cf522b4778426208dcfd2e
> > > 47
> > > > 16%7C
> > > > >
> > > >
> > >
> 90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638663622429822216%
> > > 7CU
> > > > nknow
> > > > >
> > > >
> > n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> > > > WwiLC
> > > > >
> > > >
> > >
> JXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=xYJwo5A14GdYtVLDsrzVXxHSigD1js
> > > g1w
> > > > Jx9tL
> > > > > FoMEo%3D&reserved=0
> > > > > update
> > > > > Diff:
> > > >
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > > > Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-teas-
> > rfc8776-
> > > >
> > >
> &data=05%7C02%7Cmohamed.boucadair%40orange.com%7C26c442cf522b4
> > > 778
> > > >
> > >
> 426208dcfd2e4716%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C
> > > 638
> > > >
> > >
> 663622429836473%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
> > > LCJQI
> > > >
> > >
> >
> joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=hFW
> > > a
> > > > ZMR8jikNKAVcwSRrPYk%2FXPnzkc%2FQSlW2225ZksM%3D&reserved=0
> > > > > update-14
> > > > >
> > > > > Abstract:
> > > > >
> > > > >    This document defines a collection of common data types,
> > > > identities,
> > > > >    and groupings in YANG data modeling language.  These
> > derived
> > > > common
> > > > >    data types, identities and groupings are intended to be
> > > > imported by
> > > > >    other modules, e.g., those which model the Traffic
> > > > Engineering (TE)
> > > > >    configuration and state capabilities.
> > > > >
> > > > >    This document obsoletes RFC 8776.
> > > > >
> > > > >
> > > > >
> > > > > The IETF Secretariat
> > > > >
> > > >
> > > > _______________________________________________
> > > > Teas mailing list -- teas@ietf.org To unsubscribe send an email to
> > > > teas-leave@ietf.org
> > >
> >
> _________________________________________________________________
> > > ___________________________________________
> > > 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.