Re: [core] John Scudder's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT)

Martin Duke <martin.h.duke@gmail.com> Fri, 21 May 2021 16:28 UTC

Return-Path: <martin.h.duke@gmail.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB8C3A16CC; Fri, 21 May 2021 09:28:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 XSKtEPGOM_-G; Fri, 21 May 2021 09:28:35 -0700 (PDT)
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82B003A16CA; Fri, 21 May 2021 09:28:34 -0700 (PDT)
Received: by mail-io1-xd36.google.com with SMTP id o21so20695181iow.13; Fri, 21 May 2021 09:28:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NID2OeeL169r+QR6Vel0Ag0Es6Rg+2IaiuH6A8vhGTs=; b=XKqaLeHYg7jXqTZ7vXyEwgXOtBfFbIQSFWeMKmtERdhN4RjWg/V7DIuAtRwEnXQGo/ FC7swH08+uEq/aAMcUhKg5mbbG3UeUU30hAjksuDg0mSF2O3jjLPi7LzxXFg0/CCamjx VloJOV5CMvl99/E48uIizccoG2kgKiCTzTbX6ZZnkl4LKtZpTOqQR8TIpCe1TH8onCIC M/tReVLQVZPAURndGExIqlKaDxD9WsIaCkhbYweeZNyKoIDsdWxY2gW92kCwg4vw1RLG moq8bp9dGyn2yX7WO6EuZfgEYKWADBCugdbi+dCQRmpLoTLCH5VLg7Y9Yq8d5R5fbJ/b HwAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NID2OeeL169r+QR6Vel0Ag0Es6Rg+2IaiuH6A8vhGTs=; b=tYs39LWhXzUf6ChpHH7iYFrzs3uMaBOJBvsouYRf3oWr9C9el/7gJeDG93TOzJ7Rcu XEMJqegEyztFCawJv6xGSgmU5+D0S/QvgzAyL+8njDj1IpuddCko2ae3UJgAA0uKZLjL yFj7Hr7vnA80h+0Khe5c4nQ0IZSQCydT3tM+bTOFYJkKCZVesKkInES/rdKGFrjnHtTD rxm6KRQgFQeNGSWV97DB2E5XL02RoQQsDDL7QD7BTvVp36AGg1/sTZb0lG/bGQrD64Sz nsAKx6b8kMUOnEbjHxZi56diuFZvg4QYRf+JjT9Nt6EYWmf14kmLzBS7f3HAoJIjTkJg dzUg==
X-Gm-Message-State: AOAM533fnHj7z/b1ggdZFr+B7DkMPEDVQIIc/EmzYWSP2IcgxAukhCRo p9NesLy1uR6uwJTZWqLa9eEKGslFVoBZYo3LRMI=
X-Google-Smtp-Source: ABdhPJyi40ru6IrYN5WuT7q+c0vmRNJYw3XgzguRFxD7kFMdwl4zC3tkSKGSsSOhSeamLq3I1sWy4RbGM8Egmw58tYA=
X-Received: by 2002:a02:354c:: with SMTP id y12mr5733688jae.144.1621614513309; Fri, 21 May 2021 09:28:33 -0700 (PDT)
MIME-Version: 1.0
References: <162026169267.30008.8195219304146866165@ietfa.amsl.com> <8334_1620363749_6094C9E5_8334_151_1_787AE7BB302AE849A7480A190F8B9330353782EA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1CEEABBD-DF9A-4CB5-B052-0ED28FA8B276@juniper.net> <23771_1621516652_60A6616C_23771_79_1_787AE7BB302AE849A7480A190F8B93303538BB63@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <B7CF0ABB-4AE4-4D13-979B-A3242EDF5C9D@juniper.net> <4833_1621600918_60A7AA96_4833_485_3_787AE7BB302AE849A7480A190F8B93303538C272@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <36A5A92C-AD99-4554-8A09-4E76E60BA98A@juniper.net>
In-Reply-To: <36A5A92C-AD99-4554-8A09-4E76E60BA98A@juniper.net>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Fri, 21 May 2021 09:28:22 -0700
Message-ID: <CAM4esxRPw=Jk0TiwBV8D-fak6SDYBSRfZVjKSB1bmRLE+8LXOA@mail.gmail.com>
To: John Scudder <jgs=40juniper.net@dmarc.ietf.org>
Cc: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "draft-ietf-core-new-block@ietf.org" <draft-ietf-core-new-block@ietf.org>, "core-chairs@ietf.org" <core-chairs@ietf.org>, The IESG <iesg@ietf.org>, "core@ietf.org" <core@ietf.org>, "marco.tiloca@ri.se" <marco.tiloca@ri.se>
Content-Type: multipart/alternative; boundary="000000000000074c5c05c2d98d85"
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/Oy-q0ZElGPrvVPaVN3unIvCMv9w>
Subject: Re: [core] John Scudder's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 May 2021 16:28:40 -0000

So I'm not sure that "large numbers" are a sufficient reason to not worry
about jitter.

If two hosts simultaneously transmit on a quiet network, and cause losses
with each other. They both set the same retransmission timeout, and in
spite of no other traffic around cause the same collision, etc.

If an explicit configuration doesn't result in common round numbers, it's
an OK substitute, but I don't see any encouragement of that choice.

On Fri, May 21, 2021 at 9:17 AM John Scudder <jgs=
40juniper.net@dmarc.ietf.org> wrote:

> Hi Med,
>
> Your current working copy looks good. I’ve cleared my discuss.
>
> —John
>
> > On May 21, 2021, at 8:41 AM, mohamed.boucadair@orange.com wrote:
> >
> > [External Email. Be cautious of content]
> >
> >
> > Hi John,
> >
> > As you can see in
> https://urldefense.com/v3/__https://tinyurl.com/new-block-latest__;!!NEt6yMaO-gk!RlDk7GMcbxlFsT2QGl8ma04s1CggmQZQHcIP9aw2R2EP1rWkfQDAbIpzOgyR6g$
> , we went with the following changes to better address your latest comment
> on the jitter:
> >
> > (1) be explicit about the formula used for default values:
> >
> > OLD:
> >   NON_PROBING_WAIT is used to limit the potential wait needed when
> >   using PROBING_RATE.  By default, NON_PROBING_WAIT has the same value
> >   as EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]).
> >
> >   NON_PARTIAL_TIMEOUT is used for expiring partially received bodies.
> >   By default, NON_PARTIAL_TIMEOUT has the same value as
> >   EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]).
> >
> > NEW:
> >   NON_PROBING_WAIT is used to limit the potential wait needed when
> >   using PROBING_RATE.  By default, NON_PROBING_WAIT is computed in the
> >   same way as EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]) but with
> >   ACK_TIMEOUT and MAX_RETRANSMIT substituted with NON_TIMEOUT and
> >   NON_MAX_RETRANSMIT, respectively:
> >
> >      NON_PROBING_WAIT = NON_TIMEOUT * ((2 ** NON_MAX_RETRANSMIT) - 1) *
> >      ACK_RANDOM_FACTOR + (2 * MAX_LATENCY) + NON_TIMEOUT
> >
> >   NON_PARTIAL_TIMEOUT is used for expiring partially received bodies.
> >   By default, NON_PARTIAL_TIMEOUT is computed in the same way as
> >   EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]).  This default value
> >   is calculated in the same way as NON_PROBING_WAIT.
> >
> > (2) We don’t see a need to apply a jitter when a value is explicitly
> configured (these are expected to be large numbers, we don't care that much
> on the jitter). We added this text to be clear about the intent, and which
> BTW reflects the current implementation:
> >
> > NEW:
> >      When explicit values are
> >      configured for NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT, these
> >      values are used without applying any jitter.
> >
> > We also adopted your proposed edits in the message below.
> >
> > Thank you again for the careful review. This is highly appreciated.
> >
> > Cheers,
> > John & Med
> >
> >> -----Message d'origine-----
> >> De : John Scudder [mailto:jgs@juniper.net]
> >> Envoyé : vendredi 21 mai 2021 00:03
> >> À : BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com>
> >> Cc : The IESG <iesg@ietf.org>; draft-ietf-core-new-block@ietf.org;
> >> core-chairs@ietf.org; core@ietf.org; marco.tiloca@ri.se
> >> Objet : Re: John Scudder's Discuss on draft-ietf-core-new-block-11:
> >> (with DISCUSS and COMMENT)
> >>
> >> Hi Mohamed,
> >>
> >> I think we are converging. My comments in line. I’ve snipped agreed
> >> points for brevity, indicated by […].
> >>
> >>> On May 20, 2021, at 9:17 AM, mohamed.boucadair@orange.com wrote:
> >>
> >> […]
> >>
> >>>>>> 11. General
> >>>>>>
> >>>>>> By the way, none of the timers specify jitter (and indeed, if
> >> read
> >>>>>> literally, jitter would be forbidden). Is this intentional?
> >>>>>
> >>>>> No +/- tolerances have been defined. When a timer expires, then
> >> the
> >>>> next action takes place.
> >>>>
> >>>> I notice that RFC 7252 jitters its timers, for example:
> >>>>
> >>>>  counter.  For a new Confirmable message, the initial timeout is
> >> set
> >>>>  to a random duration (often not an integral number of seconds)
> >>>>  between ACK_TIMEOUT and (ACK_TIMEOUT * ACK_RANDOM_FACTOR) (see
> >>>>  Section 4.8)
> >>>> …
> >>>>  ACK_RANDOM_FACTOR MUST NOT be decreased below 1.0, and it SHOULD
> >>>> have
> >>>>  a value that is sufficiently different from 1.0 to provide some
> >>>>  protection from synchronization effects.
> >>>>
> >>>> MAX_TRANSMIT_SPAN and MAX_TRANSMIT_WAIT are similarly jittered. A
> >>>> number of your introduced parameters
> >>>>
> >>>>  This document introduces new parameters MAX_PAYLOADS,
> >> NON_TIMEOUT,
> >>>>  NON_RECEIVE_TIMEOUT, NON_MAX_RETRANSMIT, NON_PROBING_WAIT, and
> >>>>  NON_PARTIAL_TIMEOUT primarily for use with NON (Table 3).
> >>>>
> >>>> appear at least superficially similar to the timers the authors of
> >>>> RFC 7252 deemed important to jitter to prevent synchronization
> >>>> effects. Did you specifically consider jittering them, and decide
> >>>> that jitter was unnecessary? If so, can you explain what is
> >> different
> >>>> about your specification, compared to the base spec, that
> >> eliminates
> >>>> the concern?
> >>>
> >>> RFC7252 introduces ACK_RANDOM_FACTOR jitter and separately jitter
> >> for multicast responses (which is not relevant here).
> >>>
> >>> The ACK_RANDOM_FACTOR is there for when re-transmitting a packet
> >> that has not been acknowledged for some reason by its peer.
> >> NON_TIMEOUT is for when the next MAX_PAYLOADS_SET can start
> >> transmission (not re-transmission) assuming a 'Continue' has not
> >> arrived in the interim, and so was not thought necessary to add in
> >> ACK_RANDOM_FACTOR style jitter here.
> >>>
> >>> For NON_RECEIVE_TIMEOUT, what is important is that
> >> NON_RECEIVE_TIMEOUT is greater than NON_TIMEOUT (We say in the spec a
> >> minimum of one second) so that a peer does not fire off a re-
> >> transmission request before the local agent has a chance to start to
> >> transmit the next MAX_PAYLOADS_SET.  NON_RECEIVE_TIMEOUT is
> >> exponentially scaled for each retry to make sure that stability is
> >> preserved. So, again, ACK_RANDOM_FACTOR jitter was not thought to be
> >> necessary here.
> >>>
> >>> NON_MAX_RETRANSMIT is a fixed count.
> >>>
> >>> NON_PROBING_WAIT is used to put a limit on the potential delay that
> >> could incur when obeying PROBING_WAIT when there is no peer response.
> >> If the implementation goes with the default EXCHANGE_LIFETIME
> >> computation, then NON_PROBING_WAIT includes ACK_RANDOM_FACTOR in the
> >> math.
> >>>
> >>> NON_PARTIAL_TIMEOUT if computed using the default EXCHANGE_LIFETIME
> >> includes ACK_RANDOM_FACTOR.
> >>
> >> Thanks for taking the time to explain. You don’t comment regarding
> >> whether NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT should be jittered
> >> or not, you just explain that if they use the default they get jitter
> >> “for free”. The missing detail is that if they don’t use the default
> >> they don’t get jittered, so I think some consideration is still
> >> called for regarding whether having them not be jittered is OK.
> >>
> >> […]
> >>
> >>>>>> 15. Section 10.2.3
> >>
> >> […]
> >>
> >>>> One concern related to that: waiting NON_TIMEOUT isn’t actually
> >>>> required, it’s only RECOMMENDED, therefore this isn’t actually a
> >>>> guarantee. From §7.2:
> >>>>
> >>>>  As the sending of many payloads of a single body may itself
> >> cause
> >>>>  congestion, it is RECOMMENDED that after transmission of every
> >>>>  MAX_PAYLOADS_SET of a single body, a delay is introduced of
> >>>>  NON_TIMEOUT before sending the next MAX_PAYLOADS_SET to manage
> >>>>  potential congestion issues.
> >>>>
> >>>> I am curious why you made this a RECOMMENDED instead of a MUST. In
> >> a
> >>>> situation like this it would be preferable for you to explain to
> >> the
> >>>> implementor what situation they can ignore the RECOMMENDED in and
> >>>> what they should do instead, or of course to make it into a MUST.
> >>>
> >>> Because a continue signal may be received from the peer and then
> >> continue without waiting for the timeout to expire.
> >>>
> >>> This is to be linked with this text:
> >>>
> >>>     A response using this Response Code SHOULD NOT be generated
> >> for
> >>>     every received Q-Block1 Option request (Section 7.2).  It
> >> SHOULD
> >>>     only be generated when all the payload requests are Non-
> >>>     confirmable and a MAX_PAYLOADS_SET has been received by the
> >>>      server.  More details about the motivations for this
> >> optimization
> >>>
> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >>>     are discussed in Section 7.2.
> >>>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >>>
> >>> We could use **MUST unless a 'Continue' is received**, e.g.,
> >>>
> >>> OLD:
> >>>  As the sending of many payloads of a single body may itself cause
> >>>  congestion, it is RECOMMENDED that after transmission of every
> >>>  MAX_PAYLOADS_SET of a single body, a delay is introduced of
> >>>  NON_TIMEOUT before sending the next MAX_PAYLOADS_SET to manage
> >>>  potential congestion issues.
> >>>
> >>> NEW:
> >>>  As the sending of many payloads of a single body may itself cause
> >>>  congestion, after transmission of every MAX_PAYLOADS_SET of a
> >> single
> >>>  body, a delay MUST be introduced of NON_TIMEOUT before sending
> >> the
> >>>  next MAX_PAYLOADS_SET to manage potential congestion issues.
> >>>  However, if a 'Continue' is received from the peer for the
> >> current
> >>>  MAX_PAYLOADS_SET, then the next MAX_PAYLOADS_SET can start
> >>>  transmission immediately.
> >>>
> >>> ... but I know that many would argue this is a SHOULD.
> >>
> >> I would be OK with either your proposed new text, or a SHOULD/MAY
> >> pair as in
> >>
> >> NEW:
> >>  As the sending of many payloads of a single body may itself cause
> >>  congestion, after transmission of every MAX_PAYLOADS_SET of a
> >> single
> >>  body, a delay SHOULD be introduced of NON_TIMEOUT before sending
> >> the
> >>  next MAX_PAYLOADS_SET to manage potential congestion issues.
> >>  However, if a 'Continue' is received from the peer for the current
> >>  MAX_PAYLOADS_SET, then the next MAX_PAYLOADS_SET MAY start
> >>  transmission immediately.
> >>
> >> If you want to stick with MUST I think you can clear up the pain with
> >> something like
> >>
> >> NEW:
> >>  As the sending of many payloads of a single body may itself cause
> >>  congestion, after transmission of every MAX_PAYLOADS_SET of a
> >> single
> >>  body, a delay MUST be introduced of NON_TIMEOUT before sending the
> >>  next MAX_PAYLOADS_SET unless a 'Continue' is received from the peer
> >>  for the current MAX_PAYLOADS_SET, in which case the next
> >>  MAX_PAYLOADS_SET MAY start transmission immediately.
> >>
> >> (To my eye presenting the option in this way makes it clear when the
> >> MUST does, and doesn’t, apply. This is my preferred form but I don’t
> >> insist.)
> >>
> >> […]
> >>
> >>>> 17. Section 1:
> >>>>
> >>>>  This document introduces the CoAP Q-Block1 and Q-Block2 Options
> >>>> which
> >>>>  allow block-wise transfer to work with series of Non-confirmable
> >>>>  messages, instead of lock-stepping using Confirmable messages
> >>>>  (Section 3).  In other words, this document provides a missing
> >>>> piece
> >>>>  of [RFC7959], namely the support of block-wise transfer using
> >> Non-
> >>>>  confirmable where an entire body of data can be transmitted
> >> without
> >>>>  the requirement for an acknowledgement (but recovery is
> >> available
> >>>>  should it be needed).
> >>>>
> >>>> As far as I can tell the spec does not really remove the
> >> requirement
> >>>> for acknowledgement,
> >>>
> >>> These are not required. They were added as an optimization to avoid
> >> the non-timeout if the peer decides to use it.
> >>
> >> As I mentioned below (“awfully close parsing”), I think that although
> >> you can find some justification for this reading, it’s debatable.
> >> Transmission of the acknowledgement (at least the final
> >> acknowledgement of the entire body, in the form of a Response Code)
> >> is required, is it not? Reception isn’t required though. Without the
> >> verb, I’m not sure whether I can say whether acknowledgement is, or
> >> isn’t, required.
> >>
> >> I don’t insist that you change this, but I do think you could improve
> >> the clarity of the document, if you edited the above to read “…
> >> without the requirement that an acknowledgment be received from the
> >> peer"
> >>
> >>>> it just amortizes the acknowledgements by only sending them every
> >>>> MAX_PAYLOADS_SET. Response Code 2.31 is essentially an
> >>>> acknowledgement, and it gets sent that frequently, right? There’s
> >>>> also (if I recall correctly) some flavor of acknowledgement that
> >> is
> >>>> sent when the entire body has been transferred. So, I think the
> >> new
> >>>> paragraph isn’t accurate.
> >>>>
> >>>> This observation also applies to this claimed benefit in §3:
> >>>>
> >>>>  o  They support sending an entire body using NON messages
> >> without
> >>>>     requiring an intermediate response from the peer.
> >>
> >> And similarly, “… without requiring that an intermediate response be
> >> received from the peer.”
> >>
> >> […]
> >>
> >>>> 18. Section 2:
> >>>>
> >>>>  MAX_PAYLOADS_SET is the set of blocks identified by block
> >> numbers
> >>>>  that, when divided by MAX_PAYLOADS, they have the same numeric
> >>>>
> >>>> Remove “they”
> >>>
> >>> Fixed. Thanks.
> >>>
> >>>>
> >>>>  result.  For example, if MAX_PAYLOADS is set to '10', a
> >>>>  MAX_PAYLOADS_SET could be blocks #0 to #9, #10 to #19, etc.
> >>>>  Depending on the data size, the MAX_PAYLOADS_SET may not
> >> comprise
> >>>> all
> >>>>  the MAX_PAYLOADS blocks.
> >>>>
> >>>> I don’t understand the last sentence ("Depending on the data size,
> >>>> the MAX_PAYLOADS_SET may not comprise all the MAX_PAYLOADS
> >> blocks.”)
> >>>> Are you trying to say that if the body size isn’t evenly divisible
> >> by
> >>>> MAX_PAYLOADS then the final MAX_PAYLOADS_SET will have fewer than
> >>>> MAX_PAYLOADS blocks in it?
> >>>
> >>> We meant that the last set may include fewer blocks than
> >> MAX_PAYLOADS. Changed to:
> >>>
> >>> " Depending on the overall data
> >>>                   ^^^^^^^^
> >>>  size, the final MAX_PAYLOADS_SET may not comprise all the
> >>>            ^^^^^
> >>>  MAX_PAYLOADS blocks. "
> >>>
> >>> Better?
> >>
> >> Improving. The word “comprise” is prone to misinterpretation in my
> >> experience, I would suggest something like “… there could be fewer
> >> than MAX_PAYLOADS blocks in the final MAX_PAYLOADS_SET.”
> >>
> >> Thanks,
> >>
> >> —John
> >
> >
> _________________________________________________________________________________________________________________________
> >
> > 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.
> >
>
>