[Teas] Re: Second Working group last call of draft-ietf-teas-rfc8776-update-13 - one week

[[e-mail]]

Re-,

Thanks, Italo.

(1) Nit

This should be fixed to save you a warning:

CURRENT :

   <CODE BEGINS> file [e-mail]<mailto:[e-mail]>
     ...
     revision 2024-10-24 {
       description

(2) The security cons seems OK to me.

(3) 6241 and 8040 can be moved to be cited as informative per the following in the bis:

==
   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.
=

(4) I still see the list keys indicated in the tree as optional :-(

Cheers,
Med

De : Italo Busi <[e-mail]>
Envoyé : vendredi 25 octobre 2024 16:08
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>; [e-mail]; 'OSCAR GONZALEZ DE DIOS' <[e-mail]>; 'TEAS WG' <[e-mail]>
Cc : 'TEAS WG Chairs' <[e-mail]>
Objet : RE: [Teas] Re: Second Working group last call of draft-ietf-teas-rfc8776-update-13 - one week


Hi Med,

I have updated the draft based on your feedbacks: the previous URLs are still valid

Could you please double check the Security Consideration text in particular?

The template in RFC8407-bis is written assuming the draft defines only one module while this draft is defining two modules so I have tweaked a bit the text in the template

Thanks, Italo

From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: venerdì 25 ottobre 2024 14:28
To: Italo Busi <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; 'OSCAR GONZALEZ DE DIOS' <[e-mail]<mailto:[e-mail]>>; 'TEAS WG' <[e-mail]<mailto:[e-mail]>>
Cc: 'TEAS WG Chairs' <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Teas] Re: Second Working group last call of draft-ietf-teas-rfc8776-update-13 - one week

Re-,

What pyang produces is not authoritative, especially when this is broken.

Please fix this. The RFC Editor team does not have the skills to fix all items that need to be fixed. Adding a note would not be helpful.

Cheers,
Med

De : Italo Busi <[e-mail]<mailto:[e-mail]>>
Envoyé : vendredi 25 octobre 2024 11:32
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; 'OSCAR GONZALEZ DE DIOS' <[e-mail]<mailto:[e-mail]>>; 'TEAS WG' <[e-mail]<mailto:[e-mail]>>
Cc : 'TEAS WG Chairs' <[e-mail]<mailto:[e-mail]>>
Objet : RE: [Teas] Re: Second Working group last call of draft-ietf-teas-rfc8776-update-13 - one week

Hi Med,

I am ok with 1

Regarding 2, I am not in favor of manual changes to the output of pyang tool. These changes will be lost the next time we update the YANG and regenerate the tree.

I think this issue should be fixed by pyang or, as a last resort, by the RFC Editor before publication.

I can add an RFC Editor Note in the draft.

Note: the YANG tree was not present in RFC8776 because there were no requirements to include the tree, especially with YANG data models non defining YANG data tress but only types, identities and groupings. We have added in RFC8776-bis to comply with the new guidelines

Italo

From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: venerdì 25 ottobre 2024 06:48
To: Italo Busi <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; 'OSCAR GONZALEZ DE DIOS' <[e-mail]<mailto:[e-mail]>>; 'TEAS WG' <[e-mail]<mailto:[e-mail]>>
Cc: 'TEAS WG Chairs' <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Teas] Re: Second Working group last call of draft-ietf-teas-rfc8776-update-13 - one week

Hi Italo, all,

1- You may use the updated security template in the 8407bis. With that, even NETCONF/RESTCONF can be moved to informative. See the full guidance in the bis.
2- I also noticed some issues in the tree for list keys. These are displayed as optional!
This is actually a pyang bug. I checked RFC8776, but see that the too long tree was not included.

OLD:
     grouping label-set-info:
       +-- label-restrictions
          +-- label-restriction* [index]
             +-- restriction?    enumeration
             +-- index?          uint32
     ...
     grouping optimization-metric-entry:
       +-- metric-type?                      identityref
       +-- weight?                           uint8
       +-- explicit-route-exclude-objects
       |  +-- route-object-exclude-object* [index]
       |     +-- index?                       uint32
...
       +-- explicit-route-include-objects
          +-- route-object-include-object* [index]
             +-- index?                       uint32
...
     grouping path-constraints-route-objects:
       +-- explicit-route-objects
          +-- route-object-exclude-always* [index]
          |  +-- index?                       uint32
...
          +-- route-object-include-exclude* [index]
             +-- explicit-route-usage?        identityref
             +-- index?                       uint32
     grouping path-route-include-objects:
       +-- route-object-include-object* [index]
          +-- index?                       uint32

     grouping path-route-exclude-objects:
       +-- route-object-exclude-object* [index]
          +-- index?                       uint32

     grouping generic-path-metric-bounds:
       +-- path-metric-bounds
          +-- path-metric-bound* [metric-type]
             +-- metric-type?   identityref
             +-- upper-bound?   uint64
     grouping generic-path-optimization:
       +-- optimizations
       |  +-- (algorithm)?
       |     +--:(metric) {path-optimization-metric}?
       |     |  +-- optimization-metric* [metric-type]
       |     |  |  +-- metric-type?                      identityref
...


       |     |  |  |  +-- route-object-exclude-object* [index]
       |     |  |  |     +-- index?                       uint32
...
       |     |  |  +-- explicit-route-include-objects
       |     |  |     +-- route-object-include-object* [index]
       |     |  |        +-- index?                       uint32
...
     grouping generic-path-affinities:
       +-- path-affinities-values
       |  +-- path-affinities-value* [usage]
       |     +-- usage?   identityref
       |     +-- value?   admin-groups
       +-- path-affinity-names
          +-- path-affinity-name* [usage]
             +-- usage?           identityref
             +-- affinity-name* [name]
                +-- name?   string
     grouping generic-path-srlgs:
       +-- path-srlgs-lists
       |  +-- path-srlgs-list* [usage]
       |     +-- usage?    identityref
       |     +-- values*   srlg
       +-- path-srlgs-names
          +-- path-srlgs-name* [usage]
             +-- usage?   identityref
             +-- names*   string
...
       +-- path-metric-bounds
       |  +-- path-metric-bound* [metric-type]
       |     +-- metric-type?   identityref
       |     +-- upper-bound?   uint64
       +-- path-affinities-values
       |  +-- path-affinities-value* [usage]
       |     +-- usage?   identityref
       |     +-- value?   admin-groups
       +-- path-affinity-names
       |  +-- path-affinity-name* [usage]
       |     +-- usage?           identityref
       |     +-- affinity-name* [name]
       |        +-- name?   string
       +-- path-srlgs-lists
       |  +-- path-srlgs-list* [usage]
       |     +-- usage?    identityref
       |     +-- values*   srlg
       +-- path-srlgs-names
          +-- path-srlgs-name* [usage]
             +-- usage?   identityref
             +-- names*   string
     grouping generic-path-constraints:
...
          |  +-- path-metric-bound* [metric-type]
          |     +-- metric-type?   identityref
          |     +-- upper-bound?   uint64
          +-- path-affinities-values
          |  +-- path-affinities-value* [usage]
          |     +-- usage?   identityref
          |     +-- value?   admin-groups
          +-- path-affinity-names
          |  +-- path-affinity-name* [usage]
          |     +-- usage?           identityref
          |     +-- affinity-name* [name]
          |        +-- name?   string
          +-- path-srlgs-lists
          |  +-- path-srlgs-list* [usage]
          |     +-- usage?    identityref
          |     +-- values*   srlg
          +-- path-srlgs-names
          |  +-- path-srlgs-name* [usage]
          |     +-- usage?   identityref
          |     +-- names*   string
          +-- disjointness?             te-path-disjointness
     grouping generic-path-properties:
       +--ro path-properties
          +--ro path-metric* [metric-type]
          |  +--ro metric-type?          identityref
          |  +--ro accumulative-value?   uint64
          +--ro path-affinities-values
          |  +--ro path-affinities-value* [usage]
          |     +--ro usage?   identityref
          |     +--ro value?   admin-groups
          +--ro path-affinity-names
          |  +--ro path-affinity-name* [usage]
          |     +--ro usage?           identityref
          |     +--ro affinity-name* [name]
          |        +--ro name?   string
          +--ro path-srlgs-lists
          |  +--ro path-srlgs-list* [usage]
          |     +--ro usage?    identityref
          |     +--ro values*   srlg
          +--ro path-srlgs-names
          |  +--ro path-srlgs-name* [usage]
          |     +--ro usage?   identityref
          |     +--ro names*   string
          +--ro path-route-objects
             +--ro path-route-object* [index]
                +--ro index?                       uint32

NEW:

     grouping label-set-info:
       +-- label-restrictions
          +-- label-restriction* [index]
             +-- restriction?    enumeration
             +-- index          uint32
     ...
     grouping optimization-metric-entry:
       +-- metric-type?                      identityref
       +-- weight?                           uint8
       +-- explicit-route-exclude-objects
       |  +-- route-object-exclude-object* [index]
       |     +-- index                        uint32
...
       +-- explicit-route-include-objects
          +-- route-object-include-object* [index]
             +-- index                       uint32
...
     grouping path-constraints-route-objects:
       +-- explicit-route-objects
          +-- route-object-exclude-always* [index]
          |  +-- index                        uint32
...
          +-- route-object-include-exclude* [index]
             +-- explicit-route-usage?        identityref
             +-- index                        uint32
     grouping path-route-include-objects:
       +-- route-object-include-object* [index]
          +-- index                        uint32

     grouping path-route-exclude-objects:
       +-- route-object-exclude-object* [index]
          +-- index                        uint32

     grouping generic-path-metric-bounds:
       +-- path-metric-bounds
          +-- path-metric-bound* [metric-type]
             +-- metric-type    identityref
             +-- upper-bound?   uint64
     grouping generic-path-optimization:
       +-- optimizations
       |  +-- (algorithm)?
       |     +--:(metric) {path-optimization-metric}?
       |     |  +-- optimization-metric* [metric-type]
       |     |  |  +-- metric-type                       identityref
...


       |     |  |  |  +-- route-object-exclude-object* [index]
       |     |  |  |     +-- index                        uint32
...
       |     |  |  +-- explicit-route-include-objects
       |     |  |     +-- route-object-include-object* [index]
       |     |  |        +-- index                        uint32
...
     grouping generic-path-affinities:
       +-- path-affinities-values
       |  +-- path-affinities-value* [usage]
       |     +-- usage    identityref
       |     +-- value?   admin-groups
       +-- path-affinity-names
          +-- path-affinity-name* [usage]
             +-- usage            identityref
             +-- affinity-name* [name]
                +-- name    string
     grouping generic-path-srlgs:
       +-- path-srlgs-lists
       |  +-- path-srlgs-list* [usage]
       |     +-- usage     identityref
       |     +-- values*   srlg
       +-- path-srlgs-names
          +-- path-srlgs-name* [usage]
             +-- usage    identityref
             +-- names*   string
...
       +-- path-metric-bounds
       |  +-- path-metric-bound* [metric-type]
       |     +-- metric-type    identityref
       |     +-- upper-bound?   uint64
       +-- path-affinities-values
       |  +-- path-affinities-value* [usage]
       |     +-- usage    identityref
       |     +-- value?   admin-groups
       +-- path-affinity-names
       |  +-- path-affinity-name* [usage]
       |     +-- usage            identityref
       |     +-- affinity-name* [name]
       |        +-- name    string
       +-- path-srlgs-lists
       |  +-- path-srlgs-list* [usage]
       |     +-- usage     identityref
       |     +-- values*   srlg
       +-- path-srlgs-names
          +-- path-srlgs-name* [usage]
             +-- usage    identityref
             +-- names*   string
     grouping generic-path-constraints:
...
          |  +-- path-metric-bound* [metric-type]
          |     +-- metric-type    identityref
          |     +-- upper-bound?   uint64
          +-- path-affinities-values
          |  +-- path-affinities-value* [usage]
          |     +-- usage    identityref
          |     +-- value?   admin-groups
          +-- path-affinity-names
          |  +-- path-affinity-name* [usage]
          |     +-- usage           identityref
          |     +-- affinity-name* [name]
          |        +-- name    string
          +-- path-srlgs-lists
          |  +-- path-srlgs-list* [usage]
          |     +-- usage     identityref
          |     +-- values*   srlg
          +-- path-srlgs-names
          |  +-- path-srlgs-name* [usage]
          |     +-- usage    identityref
          |     +-- names*   string
          +-- disjointness?             te-path-disjointness
     grouping generic-path-properties:
       +--ro path-properties
          +--ro path-metric* [metric-type]
          |  +--ro metric-type           identityref
          |  +--ro accumulative-value?   uint64
          +--ro path-affinities-values
          |  +--ro path-affinities-value* [usage]
          |     +--ro usage    identityref
          |     +--ro value?   admin-groups
          +--ro path-affinity-names
          |  +--ro path-affinity-name* [usage]
          |     +--ro usage            identityref
          |     +--ro affinity-name* [name]
          |        +--ro name?   string
          +--ro path-srlgs-lists
          |  +--ro path-srlgs-list* [usage]
          |     +--ro usage     identityref
          |     +--ro values*   srlg
          +--ro path-srlgs-names
          |  +--ro path-srlgs-name* [usage]
          |     +--ro usage    identityref
          |     +--ro names*   string
          +--ro path-route-objects
             +--ro path-route-object* [index]
                +--ro index                        uint32

Please double check.

Cheers,
Med

De : Italo Busi <[e-mail]<mailto:[e-mail]>>
Envoyé : jeudi 24 octobre 2024 20:43
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; 'OSCAR GONZALEZ DE DIOS' <[e-mail]<mailto:[e-mail]>>; 'TEAS WG' <[e-mail]<mailto:[e-mail]>>
Cc : 'TEAS WG Chairs' <[e-mail]<mailto:[e-mail]>>
Objet : RE: [Teas] Re: Second Working group last call of draft-ietf-teas-rfc8776-update-13 - one week

Adrian, Med,

Thanks for your feedbacks

We have updated the draft to address the nits as discussed on the mailing list and we plan to submit it as soon as the submission reopens

You can have a preview at this link:

https://raw.githubusercontent.com/italobusi/te/refs/heads/8776-bis-2nd-wg-lc/drafts/te-types-update/draft-ietf-teas-rfc8776-update.txt

You can also check the diffs with the latest published draft at this link:

https://author-tools.ietf.org/diff?doc_1=draft-ietf-teas-rfc8776-update&url_2=https://raw.githubusercontent.com/italobusi/te/refs/heads/8776-bis-2nd-wg-lc/drafts/te-types-update/draft-ietf-teas-rfc8776-update.txt
Please review the proposed changes and let us know if you any other comments before we submit the updated I-D

Thanks, Italo (on behalf of co-authors/contributors)

From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: martedì 15 ottobre 2024 07:53
To: Italo Busi <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; 'OSCAR GONZALEZ DE DIOS' <[e-mail]<mailto:[e-mail]>>; 'TEAS WG' <[e-mail]<mailto:[e-mail]>>
Cc: 'TEAS WG Chairs' <[e-mail]<mailto:[e-mail]>>
Subject: [Teas] Re: Second Working group last call of draft-ietf-teas-rfc8776-update-13 - one week

Hi Italo,

I don't have the context that led to the text you quoted, but the key message out there is "normative reference statement". Not every cited document listed in a ref stmt is normative.

We need to avoid creating clusters in the publication process that would delay publication and would be a nightmare for every one.

My advice is to tweak the description so that the ref is only informative. Thanks.

Cheers,
Med

De : Italo Busi <[e-mail]<mailto:[e-mail]>>
Envoyé : lundi 14 octobre 2024 18:20
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; 'OSCAR GONZALEZ DE DIOS' <[e-mail]<mailto:[e-mail]>>; 'TEAS WG' <[e-mail]<mailto:[e-mail]>>
Cc : 'TEAS WG Chairs' <[e-mail]<mailto:[e-mail]>>
Objet : RE: [Teas] Re: Second Working group last call of draft-ietf-teas-rfc8776-update-13 - one week

Hi Med,

I am getting a bit confused about the requirements in RFC 8407

How would you suggest to reconcile this with the following text in section 3.9 of RFC 8407 (and of RFC 8407-bis)?

For every normative reference statement that appears in a module contained in the specification that identifies a separate document, a corresponding normative reference to that document SHOULD appear in the Normative References section. The reference SHOULD correspond to the specific document version actually used within the specification.

It is not clear to my why this is a SHOULD and not a MUST and therefore under which circumstance we can deviate from the SHOULD

Thanks, Italo

From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: lunedì 14 ottobre 2024 10:18
To: [e-mail]<mailto:[e-mail]>; 'OSCAR GONZALEZ DE DIOS' <[e-mail]<mailto:[e-mail]>>; 'TEAS WG' <[e-mail]<mailto:[e-mail]>>
Cc: 'TEAS WG Chairs' <[e-mail]<mailto:[e-mail]>>
Subject: [Teas] Re: Second Working group last call of draft-ietf-teas-rfc8776-update-13 - one week

Hi all,

For the first point below, as this one is still in the WG state and it is not used in an import, I think that it is better to follow this part from 8407 and move that I-D to be listed as informative:

      Be sure citations for all imported modules are present somewhere
      in the document text (outside the YANG module).  If a YANG module
      contains reference or "description" statements that refer to an
      I-D, then the I-D is included as an informative reference.

Cheers,
Med



Orange Restricted
De : Adrian Farrel <[e-mail]<mailto:[e-mail]>>
Envoyé : vendredi 11 octobre 2024 21:29
À : 'OSCAR GONZALEZ DE DIOS' <[e-mail]<mailto:[e-mail]>>; 'TEAS WG' <[e-mail]<mailto:[e-mail]>>
Cc : 'TEAS WG Chairs' <[e-mail]<mailto:[e-mail]>>
Objet : [Teas] Re: Second Working group last call of draft-ietf-teas-rfc8776-update-13 - one week

Thanks for the opportunity, Oscar.

I always look at idnits. I see that it is warning about a lot of downrefs. Downrefs aren't necessarily a bad thing, but there really are a lot here, and it made me wonder.
So...

  *   Does this document really need to be gated by draft-ietf-pce-sid-algo which is currently only 4th in the queue for WGLC in PCE?
  *   Do we really need normative references to such a long list of Informational RFCs?
  *   RFC 4115 seems like a *really* bad thing to include as a normative reference from an IETF standards track RFC given that it is an Independent Stream publication with a fairly assertive IESG note.
  *   RFCs 4125 and 4126 are a bit shaky as normative references. I'm not sure what the status of the experiments described is. Certainly, no one thought it worth moving them on to the Standards Track.
  *   RFC 4427 is a fine document, and explains a lot of stuff. But I don't think it defines any process or protocol behaviour. So does a normative reference actually give it too much weight? Should we be using the RFCs that actually define the different recovery protocol behaviours? For example:
     identity clear {
       base protection-external-commands;
       description
         "An action that clears the active near-end lockout of a
          protection, forced switchover, manual switchover, WTR state,
          or exercise command.";
       reference
         "RFC 4427: Recovery (Protection and Restoration) Terminology
                    for Generalized Multi-Protocol Label Switching
                    (GMPLS)";
     }
The term "WTR" or "WTR state" is not found in RFC 4427, although "Wait To Restore time" is in 4.16.
On the other hand, "Wait-To-Restore (WTR)" is in 6.1 of RFC 4428 and 6.2 has "a local Wait-to-Restore (WTR) state". Mind you, 4428 is also Informational.
RFC 6378 begins to put some behavioural substance behind the concept of a WTR timer, and the state machine has a WTR State.

  *
I'm not going to go through all of the references and check them. It is possible that some downrefs are a good idea (and will need to be called out in the shepherd write-up and the IETF last call unless they are already in the downref registry). The authors might want to check carefully.

Otherwise, this looks like a solid (if rather large) piece of work. Well done to the authors!

I think that the Security Considerations given here are correct. This is the equivalent of a family of typedefs. Of themselves, there is no security risk. It all depends how other YANG modules use them.

Cheers,

Adrian

From: OSCAR GONZALEZ DE DIOS <[e-mail]<mailto:[e-mail]>>
Sent: 11 October 2024 13:36
To: 'TEAS WG' <[e-mail]<mailto:[e-mail]>>
Cc: 'TEAS WG Chairs' <[e-mail]<mailto:[e-mail]>>
Subject: [Teas] Second Working group last call of draft-ietf-teas-rfc8776-update-13 - one week

Dear TEAS WG colleagues,

       As a result of the comments during the WG LC of draft-ietf-teas-rfc8776-update-10, the authors made several changes. The current version is draft-ietf-teas-rfc8776-update-13.

      This email starts a second working group last call on https://datatracker.ietf.org/doc/draft-ietf-teas-rfc8776-update/.

    As the focus is on the changes from -10 to -13, the duration will be one week. Hence, the second working group last call ends on October 18th 2024.

    Please send your comments to the working group mailing list. To facilitate the review, please find the diff here: Diff: draft-ietf-teas-rfc8776-update-10.txt - draft-ietf-teas-rfc8776-update-13.txt<https://author-tools.ietf.org/iddiff?url1=draft-ietf-teas-rfc8776-update-10&url2=draft-ietf-teas-rfc8776-update-13&difftype=--html>

Thank you,
              Oscar


________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

____________________________________________________________________________________________________________

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.

____________________________________________________________________________________________________________

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.
____________________________________________________________________________________________________________
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.