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

Shwetha Bhandari <shwetha.bhandari@thoughtspot.com> Wed, 27 April 2022 08:58 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 432FCC1850DC for <ippm@ietfa.amsl.com>; Wed, 27 Apr 2022 01:58:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.993
X-Spam-Level:
X-Spam-Status: No, score=-6.993 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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=wfgpe0wR; dkim=pass (2048-bit key) header.d=thoughtspot-com.20210112.gappssmtp.com header.b=ir3cv74s
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 sW5Kdk7rrZHu for <ippm@ietfa.amsl.com>; Wed, 27 Apr 2022 01:58:12 -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 72B9AC15ED6F for <ippm@ietf.org>; Wed, 27 Apr 2022 01:55:42 -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 23R8h44d031728 for <ippm@ietf.org>; Wed, 27 Apr 2022 01:44:49 -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=psNOoAvhvtyOEYDxRZzvhcxdEsEaQdSjp20pma1rIGY=; b=wfgpe0wR+mfj44R760FTTDry8BtCrhmhAa2nepYYjb2wIxfJi/hK4275J0/o448TUHgx qZaWn4wqDRTkTEzGn6zci4Zr8Awd8WSn6feLj7V8qO3UbMjTBI1dhZOUd/TwnlZ+WIuf 5aUs0kxQgCVqYLBwBoXfq09/dJboqRUeCFOoYJ7BoLEbtPkDZPRF/25xchXH/iOKfAlv 7uDRmc3oZQPXyPLLLek0emy+nW0DzNjRLddUL26R1Qy/o2IzjXpponJLbRKmg8SHVNaT TQPd+V4DTRu7vAxTTDK0n9b2AGpf7FoPmr2r8hyBNC/yVJFh/O6vbq7Ndzo1Zw1BvtyB Cw==
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 3fprra99bh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for <ippm@ietf.org>; Wed, 27 Apr 2022 01:44:48 -0700
Received: by mail-qt1-f199.google.com with SMTP id bb32-20020a05622a1b2000b002f1f41e6caeso661671qtb.19 for <ippm@ietf.org>; Wed, 27 Apr 2022 01:44:48 -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=psNOoAvhvtyOEYDxRZzvhcxdEsEaQdSjp20pma1rIGY=; b=ir3cv74s/R9Kp/NxFLrRBig+Wt4WE4oLvrthW4EAUqREWR7qGlG/r9BF9Q26ENvqdd 743/d6wba7pnC7sJo0ZHfvMgv615MxUapsMcCSrHjAl4z/NJ1QIzL/j0kKvIwAutQ7PY mrJrTh4rirCgPt8eQjPzTEWmzp1OcPgtoF2070QQjC3KSFsMITw7DPfYVaOsb+KFm8m6 zxlMhrtKOSArJkxQiwGcGzsFE5aY4Lwyys+9Y0xqkYLSsm589joG/FemLPMSBFPL2F1e HDSwigVBJMbU2wi9hW0LoGMls+8MMo1pKXrmCjmrcam021HdcwJ22eKfZJ7XGYxobLib NZBQ==
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=psNOoAvhvtyOEYDxRZzvhcxdEsEaQdSjp20pma1rIGY=; b=NiOYVWpWrLcnn1//oY3oMUk6iocFXuPDpoF4Qde5/cp6TunkifOP7vKYm1TBUxRigo ZWVuJwiqCVOEMbxqvIev7NUWsmt7l63g+hnQFKNS/YosbEwH6GDSNkSlzkxW5Pc2FkRB Cd57Rvjxqwr11Jvypcb6gS5K6hpGtGUFaM0xXQqFyE6cR0k9OIS2WEPcvniZKL2waZbN oe6Txc9clLk+i5X2rN0HyK1OWPWUUCn3Rlso80I/pZFROm8OX/wWLH09FsPAdwf8JjTn MqD2oXh6CFeTHKKvVRXZizSaxfFjLuJzcOtB4G3wS7Zvom8KrwQtepoO+VwL9uJhaj+8 fZoA==
X-Gm-Message-State: AOAM531NJQXBi3nQXql+umpZq7j/ZrK8xWHwoUVCWWnFpEQLgSIeD9Kf KoGel6OGEpiJfsiSp2G2HO5ssdCvkYYnozn/gGHswmkxDpiS4nVmjOxjl+OR7nrSxgSOlHQWVzz mjTXBOjhTL2ngVZrLLloc
X-Received: by 2002:ac8:7f02:0:b0:2f3:6d42:a50e with SMTP id f2-20020ac87f02000000b002f36d42a50emr7684680qtk.509.1651049088092; Wed, 27 Apr 2022 01:44:48 -0700 (PDT)
X-Google-Smtp-Source: ABdhPJyzsVKIR9sXwrx6yS63JSa7zAPYYFefJlpDvhRV4DdF3izBJ9iNZ8l1usXQQRUI8+f0C/bGVa92yyEphr1zrno=
X-Received: by 2002:ac8:7f02:0:b0:2f3:6d42:a50e with SMTP id f2-20020ac87f02000000b002f36d42a50emr7684663qtk.509.1651049087773; Wed, 27 Apr 2022 01:44:47 -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> <CA+RyBmX3MdqVX5=hEsO+9SMbpXw+enwnm_qb4+-6smqbsTPPwg@mail.gmail.com> <CAMFZu3NZBgKXHrktn04LbwW33S+j+kGG5hx2A+1+jJ8aasCRag@mail.gmail.com> <14665_1651047374_6268FBCD_14665_484_6_addb2a5f712d4307a463d0582cc0a8a0@orange.com>
In-Reply-To: <14665_1651047374_6268FBCD_14665_484_6_addb2a5f712d4307a463d0582cc0a8a0@orange.com>
From: Shwetha Bhandari <shwetha.bhandari@thoughtspot.com>
Date: Wed, 27 Apr 2022 14:14:36 +0530
Message-ID: <CAMFZu3O-vEAnrBE6rhuFh_POPD5E2i_bHvdBx=GUjRKxk3AOYw@mail.gmail.com>
To: Med Boucadair <mohamed.boucadair@orange.com>
Cc: James Guichard <james.n.guichard@futurewei.com>, "sfc-chairs@ietf.org" <sfc-chairs@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006243f505dd9ed24f"
X-Proofpoint-ORIG-GUID: FyGgSz5oR_Ij7ONcFao9MviX67vfQ2dK
X-Proofpoint-GUID: FyGgSz5oR_Ij7ONcFao9MviX67vfQ2dK
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-27_03,2022-04-26_02,2022-02-23_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 spamscore=0 malwarescore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=5 mlxlogscore=976 mlxscore=0 lowpriorityscore=0 impostorscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2204270057
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/7my1fFoQOAmW0hOCjEjUm7FWgUM>
X-Mailman-Approved-At: Wed, 27 Apr 2022 03:07:01 -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.34
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: Wed, 27 Apr 2022 08:58:16 -0000

Hi Med,

Thanks for the confirmation and quick review.

On,

> This means the new requested TBD_IOAM value will also be a valid next
> protocol. However, I wonder whether IOAM in IOAM in NSH is really something
> you want to have. If not, I suggest the text is updated to exclude it from
> the allowed value in the above excerpt.

Per earlier discussion in this thread, quoting Frank's mail here for reference:

In addition, I don’t think that draft-ietf-sfc-ioam-nsh would be the
> appropriate place to discuss and restrict deployment options. E.g., I’m not
> sure why we’d want to restrict a deployment to using a single IOAM header
> only. E.g., one could think of using different headers for different
> namespaces or groups of namespaces for operational reasons. IMHO, such a
> discussion – if we really need it - would belong into
> draft-ietf-ippm-ioam-deployment, rather than into a draft that defines the
> encap of IOAM into NSH.

I think the text on Next Protocol should be as is. We should not add
restrictions on number of IOAM headers that could be added to the packet.

Thanks,
Shwetha




On Wed, Apr 27, 2022 at 1:46 PM <mohamed.boucadair@orange.com> wrote:

> Hi Shwetha, all,
>
>
>
> The changes look great. Thanks.
>
>
>
> There is one specific point not addressed in previous replies. This is
> related to this text:
>
>
>
>       Next Protocol:  8-bit unsigned integer that determines the type of
>
>          header following IOAM.  The semantics of this field are
>
>          identical to the Next Protocol field in [RFC8300].
>
>
>
> This means the new requested TBD_IOAM value will also be a valid next protocol. However, I wonder whether IOAM in IOAM in NSH is really something you want to have. If not, I suggest the text is updated to exclude it from the allowed value in the above excerpt.
>
>
>
> Other than that, I think that the draft is ready to move forward.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Shwetha Bhandari <shwetha.bhandari@thoughtspot.com>
> *Envoyé :* mercredi 27 avril 2022 10:06
> *À :* James Guichard <james.n.guichard@futurewei.com>om>; sfc-chairs@ietf.org
> *Cc :* BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>om>; Frank
> Brockners (fbrockne) <fbrockne=40cisco.com@dmarc.ietf.org>rg>; sfc@ietf.org;
> ippm@ietf.org; Tal Mizrahi <tal.mizrahi.phd@gmail.com>om>;
> draft-ietf-sfc-ioam-nsh@ietf.org; Greg Mirsky <gregimirsky@gmail.com>
> *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!NGDq-VFOnDYhCxrwRIz1KbT5hb_RKKqKigks-nyqK1RKq5UgpwytWb7clzmlN3o0X0XBWL0KnE3aQfL7wrrx5ZezQN_YdhHpnETuWA$>
>
>
>
> Dear SFC chairs,
>
>
>
> A new version of the draft I-D.ietf-sfc-ioam-nsh has been submitted per
> the discussion in this thread.
>
> https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-ioam-nsh-09
> <https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-ioam-nsh-09__;!!MZ3Fw45to5uY!NGDq-VFOnDYhCxrwRIz1KbT5hb_RKKqKigks-nyqK1RKq5UgpwytWb7clzmlN3o0X0XBWL0KnE3aQfL7wrrx5ZezQN_YdhFd29kDew$>
>
>
> Can we please progress this draft to IESG if there are no further comments?
>
>
>
> Thanks,
>
> Shwetha
>
>
>
> On Thu, Apr 14, 2022 at 6:41 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
>
> Hi Shwetha,
>
> thank you for the proposed resolution. I agree with Med, direct normative
> reference to I-D.ietf-sfc-oam-packet seems like the logical conclusion of
> our discussion of the use of the NSH O bit. Please note that we're
> referring to I-D.ietf-sfc-oam-packet in the Active SFC OAM draft, e.g.,:
>
> The O bit in NSH MUST be set, according to [I-D.ietf-sfc-oam-packet].
>
>
>
> Regards,
>
> Greg
>
>
>
> On Thu, Apr 14, 2022 at 4:27 AM <mohamed.boucadair@orange.com> wrote:
>
> 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!LWQuxxxKpUum5gUoK44-znjehj2YRtlGMOATxfRVSc-7JOrPsk4BA4iP0oLQE4d0rObPhOCG_1iiipywftwMIMOEWh8lJI4$>
>
>
>
> 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.
>
>