Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD70C14F5E5 for ; Thu, 27 Jun 2024 05:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.263 X-Spam-Level: X-Spam-Status: No, score=0.263 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, RCVD_HELO_IP_MISMATCH=2.368, 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=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=insa-lyon.fr 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 fZhOyL7iRWWa for ; Thu, 27 Jun 2024 05:16:29 -0700 (PDT) Received: from smtpout01-ext2.partage.renater.fr (smtpout01-ext2.partage.renater.fr [194.254.240.33]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF4D9C14EB1E for ; Thu, 27 Jun 2024 05:16:27 -0700 (PDT) Received: from zmtaauth01.partage.renater.fr (zmtaauth01.partage.renater.fr [194.254.240.25]) by smtpout10.partage.renater.fr (Postfix) with ESMTP id 4F6856455C; Thu, 27 Jun 2024 14:16:23 +0200 (CEST) Received: from zmtaauth01.partage.renater.fr (localhost [127.0.0.1]) by zmtaauth01.partage.renater.fr (Postfix) with ESMTPS id 645F71400EE; Thu, 27 Jun 2024 14:16:22 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zmtaauth01.partage.renater.fr (Postfix) with ESMTP id 53F5714060E; Thu, 27 Jun 2024 14:16:22 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.10.3 zmtaauth01.partage.renater.fr 53F5714060E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=insa-lyon.fr; s=CB289C06-95B8-49FE-9C4B-D197C6D2E7CB; t=1719490582; bh=3HzavyObeZctygK/gGlEK4UMAHTTorHaTQmLvjGycWg=; h=From:Message-Id:Mime-Version:Date:To; b=Cp35n6xKnaDor4wZVz/36Ymxu19nH0uVRzTTDgdfEvN7FaUb6xznRxEOYV8e/TOn1 1nUQYW/8NR4sUDazmMkqmUC59KdwCTkCOZvmIGqG6van5FhlX3BLNruCqo7rakodMW AZjr3uoCT/amHoajnz2JAvlgNs5zXowTyiy9hC+csXq0BDGXqM+fYmqjIVYl61yrri 04C3qOIUozX5giH86PCrxTyLQFiElWU+WrinlcE0ACwOcE4gpEz5lgIcbpClFVoO+D TQFnyuPdk/VxjO92oPP8leDl1ovkBqNfVtJ5YhTYe78eOqVXT36L3Z3DnfZYB880P9 Mdck3PG9KWcLA== Received: from zmtaauth01.partage.renater.fr ([127.0.0.1]) by localhost (zmtaauth01.partage.renater.fr [127.0.0.1]) (amavis, port 10026) with ESMTP id KzDP4R0caYVg; Thu, 27 Jun 2024 14:16:22 +0200 (CEST) Received: from 134.214.58.21 (unknown [194.254.241.250]) by zmtaauth01.partage.renater.fr (Postfix) with ESMTPA id 0B4871400EE; Thu, 27 Jun 2024 14:16:22 +0200 (CEST) From: Alex Huang Feng Message-Id: <43889A13-14D9-49CD-9C5F-0437B0497AD6@insa-lyon.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_28237F65-F413-437A-8682-3ACF115E690C" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Date: Thu, 27 Jun 2024 14:16:12 +0200 In-Reply-To: To: mohamed.boucadair@orange.com References: <171872264355.20027.6027117271461135736@ietfa.amsl.com> <124ED22D-FAB1-4DF4-AF71-3B6C9C3452E0@insa-lyon.fr> X-Mailer: Apple Mail (2.3774.600.62) X-Virus-Scanned: clamav-milter 0.103.8 at clamav03 X-Virus-Status: Clean X-Renater-Ptge-SpamState: clean X-Renater-Ptge-SpamScore: 0 X-Renater-Ptge-SpamCause: gggruggvucftvghtrhhoucdtuddrgeeftddrtdeggdehtdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucftgffptefvgfftnecuuegrihhlohhuthemuceftddtnecunecujfgurhephffktgggufffjgevvfhfofesrgdtmherhhdtjeenucfhrhhomheptehlvgigucfjuhgrnhhgucfhvghnghcuoegrlhgvgidrhhhurghnghdqfhgvnhhgsehinhhsrgdqlhihohhnrdhfrheqnecuggftrfgrthhtvghrnhepjeekieehheelledtledutdegudelvdduueefvdfgtdduvedvgffghffgudekgeeunecuffhomhgrihhnpehgihhthhhusgdrtghomhdpihgvthhfrdhorhhgpdhgihhthhhusghushgvrhgtohhnthgvnhhtrdgtohhmnecukfhppeduleegrddvheegrddvgedurddvhedtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepudelgedrvdehgedrvdeguddrvdehtddphhgvlhhopedufeegrddvudegrdehkedrvddupdhmrghilhhfrhhomheprghlvgigrdhhuhgrnhhgqdhfvghnghesihhnshgrqdhlhihonhdrfhhrpdhnsggprhgtphhtthhopedvpdhrtghpthhtohepmhhohhgrmhgvugdrsghouhgtrggurghirhesohhrrghnghgvrdgtohhmpdhrtghpthhtohepnhgvthgtohhnfhesihgvthhfrdhorhhg Message-ID-Hash: QYEA5GZJUN7DT23IS2DXEU4MQBORE4SS X-Message-ID-Hash: QYEA5GZJUN7DT23IS2DXEU4MQBORE4SS X-MailFrom: alex.huang-feng@insa-lyon.fr X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-netconf.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: netconf X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5Bnetconf=5D_Re=3A_I-D_Action=3A_draft-ietf-netconf-udp-client-se?= =?utf-8?q?rver-02=2Etxt?= List-Id: NETCONF WG list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail=_28237F65-F413-437A-8682-3ACF115E690C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Med, I integrated the proposed changes: = https://github.com/netconf-wg/udp-client-server/blob/master/draft-ietf-net= conf-udp-client-server-03.txt Diff of last commit: = https://author-tools.ietf.org/diff?url_1=3Dhttps://raw.githubusercontent.c= om/netconf-wg/udp-client-server/2e8ac0ec7efcd333e156352313be8c828e5a4e5b/d= raft-ietf-netconf-udp-client-server-03.txt&url_2=3Dhttps://raw.githubuserc= ontent.com/netconf-wg/udp-client-server/master/draft-ietf-netconf-udp-clie= nt-server-03.txt Diff to last iteration: = https://author-tools.ietf.org/diff?doc_1=3Ddraft-ietf-netconf-udp-client-s= erver-02&url_2=3Dhttps://raw.githubusercontent.com/netconf-wg/udp-client-s= erver/master/draft-ietf-netconf-udp-client-server-03.txt=20 Yes, regarding the default, I=E2=80=99ll wait for a bit to see if other = members from the ML have any opinions. But yes, my reflex is also removing it. Cheers, Alex > On 27 Jun 2024, at 13:28, mohamed.boucadair@orange.com wrote: >=20 > Hi Alex, > =20 > Thanks for the follow-up and for addressing the comments. > =20 > I confirm that issue#2 below applies for = draft-ietf-netconf-tcp-client-server-26#section-3.1.1. > =20 > Noted the pending point about the default. If you decide to remove the = default, you may consider adding a note to explain why that design is a = hurdle for better reusability. > =20 > Please find below some comments on the candidate version: > =20 > # Section 5.2: 6020 is authoritative here > =20 > OLD: > This document requests IANA to register the following YANG modules = in > the "YANG Module Names" registry [RFC8342] within the "YANG > Parameters" registry group. > =20 > NEW: > This document requests IANA to register the following YANG modules = in > the "YANG Module Names" registry [RFC6020] within the "YANG > Parameters" registry group. > =20 > # Move =E2=80=9CI-D.ietf-netmod-rfc8407bis=E2=80=9D to be listed as = informative instead of normative. > =20 > Thank you. > =20 > Cheers, > Med > =20 > De : Alex Huang Feng >=20 > Envoy=C3=A9 : jeudi 27 juin 2024 12:21 > =C3=80 : BOUCADAIR Mohamed INNOV/NET > > Cc : netconf > > Objet : Re: [netconf] I-D Action: = draft-ietf-netconf-udp-client-server-02.txt > =20 >=20 > Dear Med, > =20 > Thank you very much for the review and comments. > Please see inline. >=20 >=20 > On 18 Jun 2024, at 17:28, mohamed.boucadair@orange.com = wrote: > =20 > Hi Alex,=20 >=20 > Thanks for this revised versions.=20 >=20 > Please find below some easy-to-fix comments: >=20 > # Sections 2 and 3.3. >=20 > OLD: > reference > "RFC-to-be: YANG Grouping for UDP Clients and UDP Servers"; > NEW: > reference > "RFC-to-be: YANG Groupings for UDP Clients and UDP Servers"; >=20 > # Section 2: Not sure how to interpret this feature in a module for = managing UDP clients: >=20 > CURRENT: > feature local-binding-supported { > description > "Indicates that the UDP server supports configuring local > bindings (i.e., the local address and local port) for > UDP clients."; > } > =20 > It is a typo. Changed to > Indicates that the UDP client supports configuring local > bindings (i.e., the local address and local port) for > UDP clients. > =20 > I understand this feature as a way to advertise that the client is = able to configure the local IP and local port. > =20 > I guess the typo is also valid for = https://datatracker.ietf.org/doc/html/draft-ietf-netconf-tcp-client-server= -26#section-3.1.1? If not, I am missing something. >=20 > # Section 2 >=20 > CURRENT: > "The local IP address/interface to bind to when sending UDP > messages to the remote server. INADDR_ANY ('0.0.0.0') or > INADDR6_ANY ('0:0:0:0:0:0:0:0' a.k.a. '::') MAY be used to > explicitly indicate the implicit default, that the server > can bind to any IPv4 or IPv6 address."; >=20 > ## only ip-address type is defined here. I would delete the = "interface" mention. > ## s/MAY/may > ## I would delete "explicitly indicate the implicit default" >=20 > # Section 2 >=20 > OLD: > "The local IP port number to bind to when sending UDP > NEW: > "The local port number to bind to when sending UDP >=20 > # delete " which is the default value," or "default "0";" as there are = redundant. I have a preference to delete "default "0";" as this is = reusable grouping and my prevent some uses.=20 > =20 > I already encountered this =E2=80=9Cissue" in UDP-notif, how to use = this grouping with a YANG model that implements a mandatory port. YANG = does not allow refining a default statement to a mandatory field. > I am totally okay removing the default =E2=80=9C0=E2=80=9D, but also = wanted some consistency with the tcp-client-server draft. That=E2=80=99s = is why I implemented default. > Is there any other thoughts about this from the WG? Should I remove = the default in the next iteration? >=20 >=20 >=20 > # Section 3.2: Per https://datatracker.ietf.org/doc/html/rfc5952 >=20 > OLD: 2001:DB8::0 > NEW: 2001:db8::0 >=20 > # Security: I would follow the template at = https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-11#name= -security-considerations-sect > =20 > Changed > =20 > For the rest, all integrated to the next iteration: = https://github.com/netconf-wg/udp-client-server/blob/master/draft-ietf-net= conf-udp-client-server-03.txt > =20 > rfcdiff: = https://author-tools.ietf.org/diff?doc_1=3Ddraft-ietf-netconf-udp-client-s= erver-02&url_2=3Dhttps://raw.githubusercontent.com/netconf-wg/udp-client-s= erver/master/draft-ietf-netconf-udp-client-server-03.txt > =20 > I will submit before cutoff. > =20 > Cheers, > Alex >=20 >=20 >=20 > # Section 5.1: >=20 > OLD: IANA is requested to assign two new URI from the IETF XML = Registry > NEW: IANA is requested to assign two new URIs from the IETF XML = Registry >=20 > # Section 5.2: >=20 > OLD: > This document also requests two new YANG module names in the YANG > Module Names registry [RFC8342] with the following suggestions: >=20 > NEW: > This document requests IANA to register the following YANG modules = in > the "YANG Module Names" registry [RFC6020] within the "YANG > Parameters" registry group. >=20 > Cheers, > Med >=20 >=20 > -----Message d'origine----- > De : Alex Huang Feng > > Envoy=C3=A9 : mardi 18 juin 2024 17:08 > =C3=80 : netconf > > Cc : i-d-announce@ietf.org > Objet : [netconf] Re: I-D Action: draft-ietf-netconf-udp-client- > server-02.txt >=20 >=20 > Dear NETCONF, >=20 > Following the feedback from the last IETF WG meeting, I updated > the client-server groupings mimicking the tcp client-server > groupings. >=20 > Changes: > - On the client-grouping, the remote-address is a generic > inet:host instead of the limited inet:ip-address-no-zone and > supports local bindings > - On the server-grouping, it is a list of local binding > addresses. > - Added some examples of usage. >=20 > We welcome any new comment on this draft. >=20 > Regards, >=20 > Alex >=20 >=20 > On 18 Jun 2024, at 16:57, internet-drafts@ietf.org = wrote: >=20 > Internet-Draft draft-ietf-netconf-udp-client-server-02.txt is > now available. >=20 > It is a work item of the Network Configuration (NETCONF) WG of > the IETF. >=20 >=20 > Title: YANG Groupings for UDP Clients and UDP Servers > Authors: Alex Huang Feng > Pierre Francois > Kent Watsen > Name: draft-ietf-netconf-udp-client-server-02.txt > Pages: 12 > Dates: 2024-06-18 >=20 > Abstract: >=20 > This document defines two YANG 1.1 modules to support the > configuration of UDP clients and UDP servers. >=20 > = __________________________________________________________________________= __________________________________ > 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. >=20 > 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. > =20 > = __________________________________________________________________________= __________________________________ > 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. >=20 > 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. --Apple-Mail=_28237F65-F413-437A-8682-3ACF115E690C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear = Med,

I integrated the proposed changes: https://github.com/netconf-wg/udp-c= lient-server/blob/master/draft-ietf-netconf-udp-client-server-03.txt

Yes, regarding the default, I=E2=80=99ll wait for a = bit to see if other members from the ML have any opinions.
But = yes, my reflex is also removing = it.

Cheers,
Alex

On 27 Jun 2024, at 13:28, = mohamed.boucadair@orange.com wrote:

Hi Alex,
 
Thanks for the follow-up = and for addressing the comments.
 
I confirm that issue#2 = below applies for = draft-ietf-netconf-tcp-client-server-26#section-3.1.1.
 
Noted the pending point = about the default. If you decide to remove the default, you may consider = adding a note to explain why that design is a hurdle for better = reusability.
 
Please find below some = comments on the candidate version:
 
# Section 5.2: 6020 is = authoritative here
 
OLD:
  This document = requests IANA to register the following YANG modules = in
  the "YANG Module = Names" registry [RFC8342] within the "YANG
  Parameters" registry = group.
 
NEW:
  This document = requests IANA to register the following YANG modules = in
  the "YANG Module = Names" registry [RFC6020] within the "YANG
  Parameters" registry = group.
 
# Move =E2=80=9CI-D.ietf-netmod-rfc8407bis=E2=80=9D to be listed = as informative instead of normative.
 
Thank = you.
 
Cheers,
Med
 
De : Alex Huang Feng <alex.huang-feng@insa-lyon.fr> 
Envoy=C3=A9 :=  jeudi 27 juin 2024 = 12:21
=C3=80 : BOUCADAIR Mohamed INNOV/NET = <mohamed.boucadair@orange.com>
Cc : netconf <netconf@ietf.org>
Objet : Re: [netconf] I-D Action: = draft-ietf-netconf-udp-client-server-02.txt
 

Dear = Med,
 
Thank you very = much for the review and comments.
Please see inline.


On 18 Jun 2024, at 17:28, mohamed.boucadair@orange.com wrote:
=
 
Hi = Alex, 

Thanks = for this revised versions. 

Please find below = some easy-to-fix comments:

# Sections 2 and = 3.3.

OLD:
      reference
 = ;       "RFC-to-be: YANG Grouping for = UDP Clients and UDP = Servers";
NEW:
      reference
&nbs= p;       "RFC-to-be: YANG Groupings = for UDP Clients and UDP Servers";

# Section 2: Not sure how to = interpret this feature in a module for managing UDP = clients:

CURRENT:
    feature = local-binding-supported = {
      description
   =      "Indicates that the UDP server supports = configuring = local
         bindings = (i.e., the local address and local port) = for
         UDP = clients.";
    }
 
It is a typo. Changed = to
Indicates that the UDP client supports = configuring local
       bindings = (i.e., the local address and local port) for
       UDP = clients.
 
I understand = this feature as a way to advertise that the client is able to configure = the local IP and local port.
 
I guess the = typo is also valid for https://datatracker.ietf.org/doc/html/draft-ietf-netconf-tcp-c= lient-server-26#section-3.1.1? If not, I am missing = something.

# Section = 2

CURRENT:
         = ; "The local IP address/interface to bind to when sending = UDP
          message= s to the remote server. INADDR_ANY = ('0.0.0.0') = or
          INADDR6_= ANY ('0:0:0:0:0:0:0:0' a.k.a. '::') MAY be used = to
          explicit= ly indicate the implicit default, that the = server
          can = bind to any IPv4 or IPv6 address.";

## only ip-address type is = defined here. I would delete the "interface" mention.
## = s/MAY/may
## I would delete "explicitly indicate the implicit = default"

# Section = 2

OLD:
         &nb= sp;"The local IP port number to bind to when sending = UDP
NEW:
          = ;"The local port number to bind to when sending UDP

# delete " = which is the default value," or "default "0";" as there are redundant. I = have a preference to delete "default "0";" as this is reusable grouping = and my prevent some uses. 
 
I already = encountered this =E2=80=9Cissue" in UDP-notif, how to use this grouping = with a YANG model that implements a mandatory port. YANG does not allow = refining a default statement to a mandatory = field.
I am totally okay removing the = default =E2=80=9C0=E2=80=9D, but also wanted some consistency with the = tcp-client-server draft. That=E2=80=99s is why I implemented = default.
Is there any other = thoughts about this from the WG? Should I remove the default in the next = iteration?



# Section 3.2: Per https://datatracker.ietf.org/doc/html/rfc5952

OLD: = <local-address>2001:DB8::0</local-address>
NEW: = <local-address>2001:db8::0</local-address>

# = Security: I would follow the template at https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc84= 07bis-11#name-security-considerations-sect
 
Changed
 
<= div style=3D"margin: 0cm; font-size: 11pt; font-family: Calibri, = sans-serif;"> 


-----Message = d'origine-----
De : Alex Huang Feng <alex.huang-feng@insa-lyon.fr>
Envoy=C3=A9 : = mardi 18 juin 2024 17:08
=C3=80 : netconf <netconf@ietf.org>
Cc : i-d-announce@ietf.org
Objet : = [netconf] Re: I-D Action: = draft-ietf-netconf-udp-client-
server-02.txt


Dear = NETCONF,

Following the feedback from the last IETF WG meeting, I = updated
the client-server groupings mimicking the tcp = client-server
groupings.

Changes:
- On the client-grouping, = the remote-address is a generic
inet:host instead of the limited = inet:ip-address-no-zone and
supports local bindings
- On the = server-grouping, it is a list of local binding
addresses.
- Added = some examples of usage.

We welcome any new comment on this = draft.

Regards,

Alex


On 18 Jun 2024, at 16:57, internet-drafts@ietf.org wrote:

Internet-Draft = draft-ietf-netconf-udp-client-server-02.txt = is
now = available.

It is a work item of the Network = Configuration (NETCONF) WG of
the IETF.


 Title:   YANG Groupings for UDP Clients = and UDP Servers
 Authors: Alex Huang = Feng
          Pierre= = Francois
          Ke= nt Watsen
 Name: =    draft-ietf-netconf-udp-client-server-02.txt
 Pag= es:   12
 Dates: =   2024-06-18

Abstract:

 This document = defines two YANG 1.1 modules to support the
 configuration of = UDP clients and UDP = servers.

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

= --Apple-Mail=_28237F65-F413-437A-8682-3ACF115E690C--