Re: [Teas] Moving forward with draft-ietf-teas-ietf-network-slices

Igor Bryskin <i_bryskin@yahoo.com> Thu, 06 May 2021 16:38 UTC

Return-Path: <i_bryskin@yahoo.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 877BF3A2856 for <teas@ietfa.amsl.com>; Thu, 6 May 2021 09:38:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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=yahoo.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 OSb6L1o8nJa1 for <teas@ietfa.amsl.com>; Thu, 6 May 2021 09:38:45 -0700 (PDT)
Received: from sonic310-24.consmr.mail.ne1.yahoo.com (sonic310-24.consmr.mail.ne1.yahoo.com [66.163.186.205]) (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 75DC33A28A9 for <teas@ietf.org>; Thu, 6 May 2021 09:38:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1620319122; bh=NOsHu4OKZ8WTl/ZCidW1smybEipGbS6uZCt1W/xJ5Vo=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=Dna8pY08MLataR/aL5jtcEzwlwroHvS8oRvX6skmgUKGpQd0UK5PkG7yRehdrdXLnEHgHMq68BQ+eU9+nEVRuvYMD5OZB1NBYSpv3rc65gLfTwIh1AYo6AUjnOXl4b+/0GIioHUfBuUDqs8cvjPzrUDuTPWdcIiOSJYu8OfRI7fABEPztHmh7YS7cJ1U91ll1uw5KYrpws661ipp0Xw3d7zYLrQhFve3g28CDmGYI2OdVTphnxP8/QVFn0HPoWDLz7ihIU3HAxD34969RRPgtFopNHZbO5leGfUIQGxukd2pBXP6wYzdDkAz/hq+PlgKSz1EhLtUXmMCC0cdVnK/uQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1620319122; bh=HG+g0TwXO33o3a/dZ6pk4LLZVFKjIF6YJxRPg2vYEkb=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=WV7ewowe+Bihu1IUxwiPYMGUpyKvEztwkBQ44KbSURNjpa5Fn+jhVxQ2GvI/TQIgnolyD2GDyuhls6Kp+OGKRhGd9AT9oI9cKR3JUn8zYVHCodbfscZuRQGjJS9vydZ+7h9FW1MApGYXTdgG47oGvFM9qa6QrvOUkrvP1hhVC85Zrt9PWcD21shmId0vxWCFU063lbB/eUyWJNsflYJ92gFDuxxQXbzevWzB37a5fCyp1jlBIX2u3kiRCOzt6FPtWO+umlWKiY2RIMQBIZ5T1AKVB5iTgk65mPKXb+0rQebwP8JTcVIx6Bn2dUaKnli2dCzmO6TezSlXlI0i/k29/Q==
X-YMail-OSG: C2X8uEEVM1nn__f11xYiYsvbQhCxbGYs5Kf5h9f6pknDxXhVYFpTUDnK5CpiSsB G5KKZmbcf0hy4l_DwMINyiYodHkc1ocmeCN5E6NDHQdEm.R3dnfV4zIPpjH.japxJcoworWfLZq. iRpgcqodmMJGw5aTtXifbyIyprE5RnMKUltKSRLEedAGwt3XgkX1wpUyaVRDcbbirNUWGoqRl9Zw aBMoBv95QS25VqAU0_xosUF4ZSTxpX1vdJdkRW8IkW.HyhRXrkeuUAQnnZ47dG7SSJYGMWcN2hOj aJXhdZ.Ewgw8WHNCtkUi4h0zy8vjRyQZODs43kxnjC3XVq3NxY.a4rJsbBpplwZRGq7xrN7QsQwL BgSw7fnM.QgNSMGGpoT1nIAveiYueP64S6xZHU_RMswB0.qZ8MVpkGCESxcHgMzhDq99HySMyghr c7O5G6ZpCNUXkIOhOTHIhn9083fRrFTGpQPMBXcOuMAYscyoocl0AJHCipZ1Y8W77JKujWA9c0vm 2MV2FELgVRp_MvKlVJF9CvAa5NlMwGdCkE_xKLJ2vXd7acJFkOaBtf58UfsqE3x34RgMPgZ_U5Dc 2_N4EekDCnerPahUdm1QXwToBHWKWCscmGoW3lPAWyGhetVuhag.2WIn.XblegW4y1FOzyhZF1Gw drlY.FeKJ80YeklkmSFPYRcgps.wkxIwjpflW5fztS6RE0XoMxHZWyQUnHxZcoxTRDKr9sdAUVTf 4XPv4LgS20rnz0WSfnxPACGw6.uwPJYsvzfj0NPpWZ2_umARgoezIMZCO.iAxh8NP.lAgX1VjHyX XGAhN3jkT.7k01TrMVLMvTWOcJthWh1KlkxFV_xbd.LNemhmZGaB1TaTx6YZafIjjDnMBHWdznwp L.Hvzn3Wf7d5y5TubeTSBBL_2Y2xAecznYatwF5jAss3sQOF98tBtiM9T6cK9bLrrTONVGWCkcvu EMzz5Giy8R8nYNQhORRkgjjQ8Z4.QJyLtLFstXTwL0fDMGWh9B6jyIsCS45sdJOBj5JMWEZAk_tp fy5SIMltk.NYDgptR4li2qHdWrWLIt0JyKIEhmCJht7HmOW2Z8pdLsATbEMYvR5XoCSCljbcrIJD AUn3Ma2ssmMFbtGJIg0jCTj7g3TrMj5xJCxN60b6ywWj454iv96vguXLHm3G1Pe74XKdApT0gk9T .5RGIKhoeWDb25nHsCfzl_zthA5jnbiMQESYvSCeS73j75hwS_EE789HfS6vvM6TtDxPDV..lmIM hQoDSWcQEZDOv9ACtFaZeJTBoPs8TKzRu_AN4RXainTcxAkeqmILgYquLTOckNUDf1ybEgYhNXUg 1i7Ig0_KjD1QCmggrE_bIO6QgX8fHnyZ8xrdc5zb9pYIwVI8E14H1QAAV991nnbObTm30b_PUQSY uHyBOyix_zxxTOpqr7E3yQKpGOCiiSxSd85cpVMIao7GTWYv5DvuU3lMKYaqdKCJCNF7jRIqOyH. E1wM1iIrR98UpfFrANWy_o6Vo1isbTTXJWzKEs_DZXE84G3jeeYVNBqgT5pW_AhkN0u76UaCyRds SzrS6.LaWrRP1QFlv3e9V.CnCilyeruyPk1YlV5.cIm56iKjPdxsB3B9uPZj1gJPzlufWZhgKUHQ 7YEpRtSnBxdu73tU6X2TBtD9iBp90qwA1m2e7babPy2nqA8W.SjJ4ySRZWQ6hus0TzUB_uk8fVqz AvLmR6yvlPEukh1Awsg93uwNQPV9qE.zz49aHi5Y463kQlPMc_eHMjEEDRD1ougTCwnNh8w06dXb 8Xbo8m8aSCbSJTAvsrkiwOVFlEVDNvxYR38BOKPGQE9dIaK2N_2uus8OCMY91JNhyMO0u770V4hE 4YS9TOmcun6yj7NDWl99D9sVMTRr_v4fcsDmLsy1uu4JI9fVznQnq0hXbAdWonLd35iyB8K5CGQO jvkc65jMIhJVGVEXB6zfW0k3z5cDb_5t9bigTNmxIaDr8Xw2hdT61FrQDIb34AhkUbBmEXSZolhx WK5YbLATvbBcNl368WL0Z.UseEOzb5wMcWBnJjxFlY33PbSkrqQBraVRgsMyptAYAPijR7qjpPJi 5r4eZ6cpaWxEs_AbKO1ghla4LxDh7gSAIgqTkDLUM_oR_fAG9SrjidbNmhKD08Y843DBJ4oiwLLf UzGzuPeUFpqKr.v0eNceJLePd6Og8IYnLA1h8ri.5edChIiKF7.k6o2jPFmpgtDSc4v7xJVg6_J0 qvSlhKIZ5jT65IG5lbm.2JIK.ylQxsCOYbE22EWry_WJA8c77uyu52w.GSYECz4aAJMAECj5HdhC gvoHlQT44wfrMZxg81wGcfjWTEsJG1LPOBVlSlcO30aRKyq_Z3YN9zgeY8OuWKbslptNbcK3.LKC kqbdv97sNn6zYGgP3XhkiSnV7IR07RTANubLVXntI7HYwHyVYVmgai5DrH_3RkVftR8_07jJj6XW hw3QOqgDyxKXbK4odCHKFyGSlssSdUbRDGlmMgftvMNJNgPiYbvqfKqNkN7.Hug_Q.qkqdXZZovU 9auGHSG9DWXwkR3YOz6P.8e6ih35EeqZM1jJJqtuwb6u0LbQu0IhglfeQ0xxNxE7erdYj6eiBRAJ iEn.PqdBIu2F5F8b_9qH2kQlFfqBFx_v2N2Kkb_BHtUO74.c7W55wLtX53ORiwqhM5LuZ6rxVjBV lw5riRM6yAAvgRA8YHhqPbBdwNnZXzH9YEw0_K6GkQ3lC.mKcIe50cTKc0gUm68zjVAqiW_33xAH ZOgoaHMJlvKD_mtuCKSuIdA0nRnMFHVjw1cnYMoyb2uvm18yTP9hyEf5V6VJ8.5sYK2xDvSJSLyA 6sU.Rq0hP.56t_IcBeMLDpaw-
X-Sonic-MF: <i_bryskin@yahoo.com>
Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ne1.yahoo.com with HTTP; Thu, 6 May 2021 16:38:42 +0000
Date: Thu, 6 May 2021 16:38:37 +0000 (UTC)
From: Igor Bryskin <i_bryskin@yahoo.com>
To: Igor Bryskin <i_bryskin=40yahoo.com@dmarc.ietf.org>, Loa Andersson <loa@pi.nu>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "teas@ietf.org" <teas@ietf.org>, =?UTF-8?Q?Oscar_Gonz=C3=A1lez_de_Dios?= <oscar.gonzalezdedios@telefonica.com>, John E Drake <jdrake=40juniper.net@dmarc.ietf.org>
Message-ID: <919542370.1252604.1620319117290@mail.yahoo.com>
In-Reply-To: <BY3PR05MB80815F1DD23D443E17009E5DC7589@BY3PR05MB8081.namprd05.prod.outlook.com>
References: <037401d740c5$70a9cc30$51fd6490$@olddog.co.uk> <3ea262cf-e4c0-5ec0-9736-aedaf6d5d4d8@pi.nu> <009401d74195$41fd70a0$c5f851e0$@olddog.co.uk> <9933_1620212302_60927A4E_9933_344_1_787AE7BB302AE849A7480A190F8B933035376DFA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <00a001d7419e$99e5a040$cdb0e0c0$@olddog.co.uk> <03cf404d-59a7-0ec5-e18f-0a98bf638c0f@pi.nu> <PAXPR06MB7872B2DEF299B15988966A9DFD589@PAXPR06MB7872.eurprd06.prod.outlook.com> <914297092.1179550.1620311146249@mail.yahoo.com> <BY3PR05MB80815F1DD23D443E17009E5DC7589@BY3PR05MB8081.namprd05.prod.outlook.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_1252603_951777460.1620319117285"
X-Mailer: WebService/1.1.18231 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36 Edg/90.0.818.51
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/7kJjXb5x32V4ICkQ_0ZufXJka-4>
Subject: Re: [Teas] Moving forward with draft-ietf-teas-ietf-network-slices
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 May 2021 16:38:51 -0000

 Thanks John,
But wouldn't the client want to constrain the connectivity for a given link in the specified SFC, say, to be more stringent than end-to-end (perhaps by a separate set of SLOs)?
Also, could the client have a say on location of SFs? For example, can it instruct to avoid a country or DC?
Igor
    On Thursday, May 6, 2021, 11:48:22 AM EDT, John E Drake <jdrake=40juniper.net@dmarc.ietf.org> wrote:  
 
 #yiv6988404160 #yiv6988404160 -- _filtered {} _filtered {} _filtered {} _filtered {}#yiv6988404160 #yiv6988404160 p.yiv6988404160MsoNormal, #yiv6988404160 li.yiv6988404160MsoNormal, #yiv6988404160 div.yiv6988404160MsoNormal {margin:0in;font-size:11.0pt;font-family:sans-serif;}#yiv6988404160 a:link, #yiv6988404160 span.yiv6988404160MsoHyperlink {color:blue;text-decoration:underline;}#yiv6988404160 span.yiv6988404160EmailStyle18 {font-family:sans-serif;color:windowtext;}#yiv6988404160 p.yiv6988404160msipfooter30b3d538, #yiv6988404160 li.yiv6988404160msipfooter30b3d538, #yiv6988404160 div.yiv6988404160msipfooter30b3d538 {margin-right:0in;margin-left:0in;font-size:11.0pt;font-family:sans-serif;}#yiv6988404160 .yiv6988404160MsoChpDefault {font-size:10.0pt;} _filtered {}#yiv6988404160 div.yiv6988404160WordSection1 {}#yiv6988404160 
Igor,
 
  
 
Given the IETF Network Slice Service definition that Eric and I proposed, I think we could add an SFC definition to the SLO definition for each sender to a given connectivity construct.  It would indicate that a packet from that sender to each receiver would pass through the specified SFC before being received.  This is consistent with  what is described in: https://datatracker.ietf.org/doc/html/draft-ietf-bess-nsh-bgp-control-plane-18.
 
  
 
Yours Irrespectively,
 
  
 
John
 
  
 
  
 
Juniper Business Use Only
 
From: Teas <teas-bounces@ietf.org> On Behalf Of Igor Bryskin
Sent: Thursday, May 6, 2021 10:26 AM
To: Loa Andersson <loa@pi.nu>nu>; adrian@olddog.co.uk; mohamed.boucadair@orange.com; teas@ietf.org; Oscar González de Dios <oscar.gonzalezdedios@telefonica.com>
Subject: Re: [Teas] Moving forward with draft-ietf-teas-ietf-network-slices
 
  
 
[External Email. Be cautious of content]
 
  
 
Hi Adrian,
 
  
 
I probably missed the discussion, but how do we reconcile  two IETF stories - network slicing and SFCs? Surely, at some point a network slice client will ask the provider not just only to deliver its traffic from A to B with delay no worse than D, but also to do something else with the data (e.g. DPI). On the other hand, when we talk about SFCs we cannot assume I think any longer the context of a physical (not sliced) network. I do not suppose we can simply mandate the SF placement at network slice end points or somewhere outside network slices - this approach would probably not scale well. 
 
  
 
So, the question is how SFs relate to network slices, in particular, to their SLAs, SLOs and topologies?
 
  
 
Thanks,
 
Igor
 
  
 
On Thursday, May 6, 2021, 07:53:32 AM EDT, Oscar González de Dios <oscar.gonzalezdedios@telefonica.com> wrote: 
 
  
 
  
 
Hi Adrian,

        I think what is really relevant is to have a clear definition on the chosen term to avoid misunderstandings. Unfortunately today customer/consumer/client are used also in other contexts that might bring extra implications.

          Said that, I am fine with the term customer. There are still a couple of places in the document where the term "service customer" is used. Please change those to "IETF Network Slice customer" to be coherent.

        One argument in favor of the term customer is that the "IETF Network slice customer" makes use of the slice to fulfill its needs (can be carry the traffic from a to b with a set of SLOs) and manage the granted slice (that is, it can rearrange the resources it is allowed to).  The term consumer misses the management part, which is a key differentiator of a slice.

        In the definition of customer, Can we just say: " A customer may manage the granted IETF Network Slice.

        Also, I'd like to clarify between the management of the IETF Network slice that the customer can do and the management the provider can do. The customer can "play" within the allocated resources, but may have some limitations. One question, the ability to manage the slice, is part of an SLO? Or should be defined separately with a different term? It would be interesting to have the possibility to indicate what the slice customer can manage and what not...

        I support moving earlier in the document the definition of the IETF Network Slice Customer and, also, add a definition for the IETF Network Slice Provider (although only "provider" is used thought the text).

        Best Regards,

                Oscar


-----Mensaje original-----
De: Teas <teas-bounces@ietf.org> En nombre de Loa Andersson
Enviado el: jueves, 6 de mayo de 2021 9:31
Para: adrian@olddog.co.uk; mohamed.boucadair@orange.com; teas@ietf.org
Asunto: Re: [Teas] Moving forward with draft-ietf-teas-ietf-network-slices

Adrian,

That is acceptable.

As you said it is late in the document, and really not in a definitions section. I don't know if we can we place something in Section "2.  Terms and Abbreviations", but there seems to be only abbreviations.

Your wholesale example:

I think you forget about wholesale. What do you call the school that buys food at the shop to provide to the children? Do you call the school the customer, or do you refer to the cook who buys the food as the customer? The contract is with the school, negotiated by the cook, signed by the bursar.

I think "the school! is the customer, which is OK in this context. The cook and the school kids could be viewed as consumers", one removed from the system.

It strikes me that "Customer System" and "IETF Slice" are somewhat similar, the risk is that we talk about "customer" (even if we change it), and "slice" (even though if is really "IETF Slice)",

Having said that, though it is not my task to call consensus, I think we have a enough support to use "customer".

I rest my case.

/Loa


On 05/05/2021 13:05, Adrian Farrel wrote:
> We currently have (in section 5.1, which may be a bit late in the
> document)
>
>    Customer:  A customer is the requester of an IETF Network Slice.
>        Customers may request monitoring of SLOs.  A customer may manage
>        the IETF Network Slice service directly by interfacing with the
>        IETF NSC or indirectly through an orchestrator.
>
> We could add "A customer may be an entity such as an enterprise
> network or a network operator, an individual working at such an
> entity, a private individual contracting for a service, or an
> application or software component."
>
> Cheers,
> Adrian
>
> -----Original Message-----
> From: mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>
> Sent: 05 May 2021 11:58
> To: adrian@olddog.co.uk; 'Loa Andersson' <loa@pi.nu>;teas@ietf.org
> Subject: RE: [Teas] Moving forward with
> draft-ietf-teas-ietf-network-slices
>
> Hi all,
>
>> Anyone else got anything to say on the topic?
>
> I would simply use "customer" and make sure the definition is generic
> enough to denote a role/entity.
>
> Thanks.
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : Teas [mailto:teas-bounces@ietf.org] De la part de Adrian Farrel
>> Envoyé : mercredi 5 mai 2021 11:59 À : 'Loa Andersson' <loa@pi.nu>nu>;
>> teas@ietf.org Objet : Re: [Teas] Moving forward with
>> draft-ietf-teas-ietf-network- slices
>>
>> Hi Loa,
>>
>>> On customer vs. consumer Adrian says:
>>>
>>>>    c. "Consumer" vs "customer". I have made this consistent (we
>> only need to
>>>>        use one term). I selected "Customer" because that seemed
>> best, but I
>>>>        know some people prefer "consumer". Please discuss if you
>> are not
>>>>        happy.
>>>
>>> If the choice is between customer vs. consumer, I prefer customer.
>>
>> OK. So I made an improvement, but...
>>
>>> I don't know if it is too late to bring this up.
>>
>> It's never too late to bring things up.
>>
>>> But I really don't like either, normal language has a strong
>>> indication that that that a customer is a person (a person that
>> walks
>>> inte to your
>>> shop) and consumer is also a person /that eats what I bought at
>> your shop).
>>
>> I think you forget about wholesale. What do you call the school that
>> buys food at the shop to provide to the children? Do you call the
>> school the customer, or do you refer to the cook who buys the food as
>> the customer? The contract is with the school, negotiated by the
>> cook, signed by the bursar.
>>
>>> IETF specifies "systems", including what goes into SW and HW, but
>> we
>>> don't specify normative rules for human behavior.
>>>
>>> I don't know if we can talk about Customer System?
>>
>> I'm afraid of this getting heavy for the reader. There are 73
>> instances of "customer" in the document, and "customer system" may
>> become tiresome to read.
>>
>> Anyone else got anything to say on the topic?
>>
>> Cheers,
>> Adrian
>>
>> _______________________________________________
>> Teas mailing list
>> Teas@ietf.org
>> https://www.ietf.org/mailman/listinfo/teas
>
> ______________________________________________________________________
> ______ _____________________________________________
>
> 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.
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>

--

Loa Andersson                        email: loa@pi.nu
Senior MPLS Expert                          loa.pi.nu@gmail.com
Bronze Dragon Consulting            phone: +46 739 81 21 64

_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas

________________________________

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 privileged and confidential 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
 

_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas
 _______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas