Re: [ippm] [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/

Shwetha Bhandari <shwetha.bhandari@thoughtspot.com> Thu, 14 April 2022 12:53 UTC

Return-Path: <shwetha.bhandari@thoughtspot.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 879D93A181D for <ippm@ietfa.amsl.com>; Thu, 14 Apr 2022 05:53:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.006
X-Spam-Level:
X-Spam-Status: No, score=-2.006 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=thoughtspot.com header.b=TXCxKXTA; dkim=pass (2048-bit key) header.d=thoughtspot-com.20210112.gappssmtp.com header.b=XzwdgZKk
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFVlBaWawTQC for <ippm@ietfa.amsl.com>; Thu, 14 Apr 2022 05:53:52 -0700 (PDT)
Received: from mx0b-0055fe01.pphosted.com (mx0b-0055fe01.pphosted.com [205.220.176.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8FFA3A1813 for <ippm@ietf.org>; Thu, 14 Apr 2022 05:53:52 -0700 (PDT)
Received: from pps.filterd (m0211452.ppops.net [127.0.0.1]) by mx0b-0055fe01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 23E9C9vK013619 for <ippm@ietf.org>; Thu, 14 Apr 2022 05:48:21 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thoughtspot.com; h=mime-version : references : in-reply-to : from : date : message-id : subject : to : cc : content-type; s=proofpoint; bh=VOH5i1U5j2rnSkrWuaxx6iXI/bj4Le9Dzy72+x9m6fU=; b=TXCxKXTAwjMcc/fHxPyBhEV5djDIP1Wvw2l/EfpfXUD0y4PhwpIspipCYCMLGsP6VBlH iCnu4k15/Pxkv3Q0DXXgX+T4vmaA2GlQ6ZccJBGtbqCBhxMfojeT+90loBFqxr/59C3u 3+LfZE/7jLzDigo8CCKkCUScXxijPQd6A3OlctwgOQ6Qr0E7VZeM9oi6JKUBHj+F2gLQ MabLssTB2mw4hiiZgYJuJRcs28vn/JV8stHJqmgvFMCaHLEKt7N314XT6N6vEkOcB3DH pCfAdNJTNvLZDFXsO5nNB6QQP/YF7QQLKlxyuV0cYbADgLm9qIm5eJnldYSrWqCURkXo Ww==
Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) by mx0b-0055fe01.pphosted.com (PPS) with ESMTPS id 3fe8xshf7m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for <ippm@ietf.org>; Thu, 14 Apr 2022 05:48:19 -0700
Received: by mail-qt1-f199.google.com with SMTP id o17-20020ac872d1000000b002edcca4ce06so3132559qtp.7 for <ippm@ietf.org>; Thu, 14 Apr 2022 05:48:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thoughtspot-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VOH5i1U5j2rnSkrWuaxx6iXI/bj4Le9Dzy72+x9m6fU=; b=XzwdgZKkFh26yZvflnT6tu9nwDJXXxdbd/UWU1E0pFwCQiNgPLYCUltV2w7phkLonN lPO8ZjcQ7itqIPDPS+RLrWXveqhvkPbV+/FRn7j5wAKsO5n6G1wY4cNdpynR6ARuaUa4 jFLAz+sB9KMUGYia6xb4GTYpPk6S6jC2V6qDePxCdWCCHorhOhHywTca7Vy3/8e5ER3n w12pvANXswi6s+UauRxB5GuRcITDVgdMmhj2996NE38PTB63XVrXBYNpSKhNxDAcOSFg FOGuSs1FyT4l9WXfL5xERYSBCbgqyZBP0xW8iYVmcCCmUmD4jrCIb8ewvfG6QIxfHGBb NKvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VOH5i1U5j2rnSkrWuaxx6iXI/bj4Le9Dzy72+x9m6fU=; b=bMAmr7Uci05THJiMIDagsU1rcJZYe2/ViXfGutg+W94j8/x2NkEUUw3Vgxnper/EmX bJY4Hdx2IIPszzt2G7GQWFQIiST8SmeKS8zJNVzj8uhXxh0mUINwCd+s845kEJMLlz9B Rr71r4xVpuIP502R+9YfN5MCP/Fz0rYIQsn5qoDZM7+YJBR4X6xOFYP3kFYlbQwY/8Qp m+QrmDGMWcgCdIBpWu1/TbgDk7if4XMpw87Ifs2BUKodQGRvDKXtQYNJHBLmD7qMgsNP k5Qv1hYa7C/7Fs2Jypj0A1UAOYCIEqlobEAz5T9ijQZYSy62PqpK+ZNjv8pdfy7IMVZ+ KLiw==
X-Gm-Message-State: AOAM532GZ/eHZznQTu7OSOKhwouKxbNe4FJe0kYGcwUF85x7zRsxKoU5 blowPPGJT2vFfrrwCfYWzEIAJHn+lLPeXNVuCXEF5Jy3SiqDHaZeFdhN9aD+zyz6E2rtLI0LuTQ D8t6HI/Tpsqm4LDFB+zT3
X-Received: by 2002:a05:620a:1981:b0:477:6e45:3e7d with SMTP id bm1-20020a05620a198100b004776e453e7dmr1602027qkb.407.1649940499123; Thu, 14 Apr 2022 05:48:19 -0700 (PDT)
X-Google-Smtp-Source: ABdhPJyPeGD3+e9S1qcJi6Jh9tfGY2fTFulXL0glny1uFkhaPN0V+9l0B7KvSR+PLGq35J3VUlrnhNh0cxrRVI9IeVM=
X-Received: by 2002:a05:620a:1981:b0:477:6e45:3e7d with SMTP id bm1-20020a05620a198100b004776e453e7dmr1602005qkb.407.1649940498815; Thu, 14 Apr 2022 05:48:18 -0700 (PDT)
MIME-Version: 1.0
References: <MN2PR13MB4206C91446BA5FBBDA69E233D2FF9@MN2PR13MB4206.namprd13.prod.outlook.com> <CA+RyBmVSrdCaO77P4=1vZ2LmxtR65OmspN_wozyGPNwtM5Uv3A@mail.gmail.com> <CAMFZu3PaLQrHcBULzsxbdnTJyr-bVDVs1WpnFwLuSkR7DbntuQ@mail.gmail.com> <CA+RyBmWeUiTsA7-CvpXSBViB00Y-tmAuSr-P=Vf3vB61zfn6bg@mail.gmail.com> <CAMFZu3P45x9Mt5-MUpGO1Puqz57DPcGE4aBsPNxczW-pw9n=AA@mail.gmail.com> <MN2PR13MB42066C22CA66B0E1F0FC3FFFD2269@MN2PR13MB4206.namprd13.prod.outlook.com> <CAMFZu3NO6J-MM_a7TZm+wTzxbKzY5t0OkW8QNLk0673Fkr16RQ@mail.gmail.com> <CA+RyBmVVWdvLZdANV_whtcwwMKVfVpM8VL7BYMM7NTnmooUpcQ@mail.gmail.com> <CAMFZu3PEmrarcsp4tXQsx4eKvai8+UvzKSFxfcakX4LUAcayJA@mail.gmail.com> <MN2PR13MB420615DA403388EA0144A9C1D22F9@MN2PR13MB4206.namprd13.prod.outlook.com> <CAMFZu3MUmuBEDEzdafw2UHEvsTE+7sQ=E1kik5TuQ=_NznFF9w@mail.gmail.com> <CA+RyBmW=ZT0EUmSYYfZJjcapBZ5-pg93um5t287LreONLOVnJQ@mail.gmail.com> <CAMFZu3NCCmj4u75taEzBiMmkMQ0YrmK5KsUToSOKfwX1yBxePA@mail.gmail.com> <26916_1649050778_624A849A_26916_245_1_aa5a0049026247d9980f4ebbc8c5ac0b@orange.com> <CY4PR11MB1672FCF27DA2A4822C6E1B40DAED9@CY4PR11MB1672.namprd11.prod.outlook.com> <11111_1649774342_62558F05_11111_493_4_a734de5265ca498bbabf9805a6eaf91d@orange.com> <CAMFZu3N03E-nWYJNik91e+X=gr3s2TVF03ZCM8i02ru4_Q82og@mail.gmail.com> <CA+RyBmWUZcUN2jnpUuyhTmkNpwvh=2prBZDGinWe2v-b3n8+MQ@mail.gmail.com> <CAMFZu3N5+GdFk13oWbi8F1qhgRNsKpSFwza61SG2oeMW9TvaLQ@mail.gmail.com> <525_1649935673_62580539_525_487_2_d0a4949b3d9c4424a0261012c7ce6188@orange.com> <CY4PR11MB1672C44062B9ABDFBD80C7A9DAEF9@CY4PR11MB1672.namprd11.prod.outlook.com> <CY4PR11MB1672C19416619D29F069C5EDDAEF9@CY4PR11MB1672.namprd11.prod.outlook.com> <25972_1649939918_625815CE_25972_272_1_7403bcdf0f19464a8e6f8e40f7e8048c@orange.com>
In-Reply-To: <25972_1649939918_625815CE_25972_272_1_7403bcdf0f19464a8e6f8e40f7e8048c@orange.com>
From: Shwetha Bhandari <shwetha.bhandari@thoughtspot.com>
Date: Thu, 14 Apr 2022 18:18:05 +0530
Message-ID: <CAMFZu3PCk6UO7_Pc66O2ZSnAygfnjDw1HgAs=dSbxZ1zF53omA@mail.gmail.com>
To: Med Boucadair <mohamed.boucadair@orange.com>
Cc: "Frank Brockners (fbrockne)" <fbrockne@cisco.com>, Greg Mirsky <gregimirsky@gmail.com>, "Frank Brockners (fbrockne)" <fbrockne=40cisco.com@dmarc.ietf.org>, sfc-chairs@ietf.org, sfc@ietf.org, ippm@ietf.org, James Guichard <james.n.guichard@futurewei.com>, Tal Mizrahi <tal.mizrahi.phd@gmail.com>, draft-ietf-sfc-ioam-nsh@ietf.org
Content-Type: multipart/alternative; boundary="00000000000055313905dc9cb568"
X-Proofpoint-ORIG-GUID: gGKUSMSrJCbx6e19-1bkBGFWdZB7Kxar
X-Proofpoint-GUID: gGKUSMSrJCbx6e19-1bkBGFWdZB7Kxar
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.858,Hydra:6.0.486,FMLib:17.11.64.514 definitions=2022-04-14_04,2022-04-14_01,2022-02-23_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 spamscore=0 priorityscore=1501 mlxlogscore=918 phishscore=0 bulkscore=5 malwarescore=0 suspectscore=0 mlxscore=0 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2204140070
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/DMcIPPxaF7Zq7EXswjd_lmS0wVc>
X-Mailman-Approved-At: Mon, 18 Apr 2022 08:11:35 -0700
Subject: Re: [ippm] [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Apr 2022 12:53:58 -0000

Hi Med,

Why does reference to RFC 8300 and any update to it, not work? Doesn't
I-D.ietf-sfc-oam-packet update 8300 and anyone implementing this will be
able to find 8300 and any RFCs that update it and apply the rules?

Thanks
Shwetha

On Thu, Apr 14, 2022, 6:08 PM <mohamed.boucadair@orange.com> wrote:

> Re-,
>
>
>
> draft-ietf-sfc-ioam-nsh includes OAM data (likely with user data) but
> there is an ambiguity in 8300 to whether this is considered as an OAM
> packet. Please refer to the SFC archives where this was discussed.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Frank Brockners (fbrockne) <fbrockne@cisco.com>
> *Envoyé :* jeudi 14 avril 2022 14:29
> *À :* BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>om>; Shwetha
> Bhandari <shwetha.bhandari@thoughtspot.com>om>; Greg Mirsky <
> gregimirsky@gmail.com>
> *Cc :* Frank Brockners (fbrockne) <fbrockne=40cisco.com@dmarc.ietf.org>rg>;
> sfc-chairs@ietf.org; sfc@ietf.org; ippm@ietf.org; James Guichard <
> james.n.guichard@futurewei.com>gt;; Tal Mizrahi <tal.mizrahi.phd@gmail.com>om>;
> draft-ietf-sfc-ioam-nsh@ietf.org
> *Objet :* RE: [sfc] WGLC for
> https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/__;!!MZ3Fw45to5uY!P-r3UTstV56mLT678QmjnilBnxUfgnF62GGWB1KzZc9aczyFl44k8Ug9OrmNYsuFT09oX0UTEcp7d4J6cmU45CEFXUZ4y_RxQ0E9Fg$>
>
>
>
> Forgot to add: A clause like " The O-bit MUST be handled following the
> rules in and any updates to [RFC8300]“ simply states the obvious.
> draft-ietf-sfc-ioam-nsh does not touch or redefine the O-bit – hence the
> statement is at best optional. The reader might even wonder why the obvious
> is re-stated in the document. My preference is still to avoid any
> mentioning of the O-bit in draft-ietf-sfc-ioam-nsh.
>
>
>
> Frank
>
>
>
> *From:* Frank Brockners (fbrockne)
> *Sent:* Thursday, 14 April 2022 14:24
> *To:* mohamed.boucadair@orange.com; Shwetha Bhandari <
> shwetha.bhandari@thoughtspot.com>gt;; Greg Mirsky <gregimirsky@gmail.com>
> *Cc:* Frank Brockners (fbrockne) <fbrockne=40cisco.com@dmarc.ietf.org>rg>;
> sfc-chairs@ietf.org; sfc@ietf.org; ippm@ietf.org; James Guichard <
> james.n.guichard@futurewei.com>gt;; Tal Mizrahi <tal.mizrahi.phd@gmail.com>om>;
> draft-ietf-sfc-ioam-nsh@ietf.org
> *Subject:* RE: [sfc] WGLC for
> https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/__;!!MZ3Fw45to5uY!P-r3UTstV56mLT678QmjnilBnxUfgnF62GGWB1KzZc9aczyFl44k8Ug9OrmNYsuFT09oX0UTEcp7d4J6cmU45CEFXUZ4y_RxQ0E9Fg$>
>
>
>
> IMHO it would be better to refer to directly RFC8300 – since this is a
> stable reference; and it allows us to finish up draft-ietf-sfc-ioam-nsh and
> get the code points allocated. I-D.ietf-sfc-oam-packet is early stages and
> still evolving.
>
>
>
> Cheers, Frank
>
>
>
> *From:* mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>
> *Sent:* Thursday, 14 April 2022 13:28
> *To:* Shwetha Bhandari <shwetha.bhandari@thoughtspot.com>om>; Greg Mirsky <
> gregimirsky@gmail.com>
> *Cc:* Frank Brockners (fbrockne) <fbrockne=40cisco.com@dmarc.ietf.org>rg>;
> sfc-chairs@ietf.org; sfc@ietf.org; ippm@ietf.org; James Guichard <
> james.n.guichard@futurewei.com>gt;; Tal Mizrahi <tal.mizrahi.phd@gmail.com>om>;
> draft-ietf-sfc-ioam-nsh@ietf.org
> *Subject:* RE: [sfc] WGLC for
> https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/__;!!MZ3Fw45to5uY!P-r3UTstV56mLT678QmjnilBnxUfgnF62GGWB1KzZc9aczyFl44k8Ug9OrmNYsuFT09oX0UTEcp7d4J6cmU45CEFXUZ4y_RxQ0E9Fg$>
>
>
>
> Hi Shwetha,
>
>
>
> I prefer we go for an explicit reference to I-D.ietf-sfc-oam-packet rather
> than “any update to RFC8300”. This is consistent with the usage in the
> other OAM draft.
>
>
>
> Thank you.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Shwetha Bhandari <shwetha.bhandari@thoughtspot.com>
> *Envoyé :* jeudi 14 avril 2022 12:06
> *À :* Greg Mirsky <gregimirsky@gmail.com>
> *Cc :* BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>om>; Frank
> Brockners (fbrockne) <fbrockne=40cisco.com@dmarc.ietf.org>rg>;
> sfc-chairs@ietf.org; sfc@ietf.org; ippm@ietf.org; James Guichard <
> james.n.guichard@futurewei.com>gt;; Tal Mizrahi <tal.mizrahi.phd@gmail.com>om>;
> draft-ietf-sfc-ioam-nsh@ietf.org
> *Objet :* Re: [sfc] WGLC for
> https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/__;!!MZ3Fw45to5uY!P-r3UTstV56mLT678QmjnilBnxUfgnF62GGWB1KzZc9aczyFl44k8Ug9OrmNYsuFT09oX0UTEcp7d4J6cmU45CEFXUZ4y_RxQ0E9Fg$>
>
>
>
> Hi Med, Greg,
>
>
>
> How about this text :
>
>
>
> “The O-bit MUST be handled following the rules in and any updates
> to [RFC8300] ."
>
>
>
> Given that I-D.ietf-sfc-oam-packet  will update RF8300 and there could be
> others in future?
>
>
>
> Thanks,
>
> Shwetha
>
>
>
> On Tue, Apr 12, 2022 at 9:24 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
>
> Hi Shwetha,
>
> I believe that the text you've quoted is helpful. I would suggest changing
> references from [RFC8300] to [I-D.ietf-sfc-oam-packet] throughout that
> paragraph.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Tue, Apr 12, 2022 at 7:56 AM Shwetha Bhandari <
> shwetha.bhandari@thoughtspot.com> wrote:
>
> Med,
>
>
>
> Thanks for the details: this is exactly what we had before the latest
> revision:
>
> *4.2 <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh-06*section-4.2__;Iw!!MZ3Fw45to5uY!NBsrzhHEf0Y_-Sindy74K4QDA6EWJjx35STSH-UxEi3eYIX0GVli9Sn1azrOPJVcI2qUzWfezK_1D2RpyFB_FOIpJPfzrvI$>.  IOAM and the use of the NSH O-bit*
>
>
>
>    [RFC8300] defines an "O bit" for OAM packets.  Per [RFC8300 <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8300__;!!MZ3Fw45to5uY!NBsrzhHEf0Y_-Sindy74K4QDA6EWJjx35STSH-UxEi3eYIX0GVli9Sn1azrOPJVcI2qUzWfezK_1D2RpyFB_FOIpEB5AbbE$>] the O
>
>    bit must be set for OAM packets and must not be set for non-OAM
>
>    packets.  Packets with IOAM data included MUST follow this
>
>    definition, i.e. the O bit MUST NOT be set for regular customer
>
>    traffic which also carries IOAM data and the O bit MUST be set for
>
>    OAM packets which carry only IOAM data without any regular data
>
>    payload.
>
>
>
> This was removed as per the discussion in this thread. Please check
> https://mailarchive.ietf.org/arch/msg/sfc/srMit5zE8UseNOhxknAw_dqvj6M/
> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/sfc/srMit5zE8UseNOhxknAw_dqvj6M/__;!!MZ3Fw45to5uY!NBsrzhHEf0Y_-Sindy74K4QDA6EWJjx35STSH-UxEi3eYIX0GVli9Sn1azrOPJVcI2qUzWfezK_1D2RpyFB_FOIp-CeLfeA$>
>
> It looks like we are going in a loop here. This definition of SFC OAM
> packet to include the OAM data that comes in inner packets via the next
> protocol header chain is introduced in draft-ietf-sfc-oam-packet to update
> the RFC8300.
>
> Jim, What are you thoughts on this? Should we reintroduce the above text ?
>
> Thanks,
> Shwetha
>
>
>
> _________________________________________________________________________________________________________________________
>
>
>
> 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.
>
>