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

Igor Bryskin <i_bryskin@yahoo.com> Fri, 07 May 2021 14:11 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 568433A2318 for <teas@ietfa.amsl.com>; Fri, 7 May 2021 07:11:32 -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, RCVD_IN_DNSWL_BLOCKED=0.001, 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 p0T1UPVkfymV for <teas@ietfa.amsl.com>; Fri, 7 May 2021 07:11:24 -0700 (PDT)
Received: from sonic301-31.consmr.mail.ne1.yahoo.com (sonic301-31.consmr.mail.ne1.yahoo.com [66.163.184.200]) (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 ECB433A230F for <teas@ietf.org>; Fri, 7 May 2021 07:11:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1620396682; bh=HvX3ipF2NS5FZUs+wnW3dC4hD15Z4P1sz1WcAsuA40k=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=NOmFwOwxTMQpRzYn5slAN3TUXzZBBOcKqkCWU+xdrf1vkqvlyYzetSED4q+OYRMgZ+aqLweTCxCuyEko3vYx3gYWA0ImUMidlfQVhXPO3coU+JpJzmUcAmwWr7GcWvtkTjcdUCV6QSFGq+0ibbNgWTbnnsjRwynpZR/MR1r6Y0lsGQ/oWCu8cFYFkinEUww1SiKwPjvX9uAqCxc7DagyoXFMV1ouWvPsXavJFnW9MdDHEB9o1SysP1R20+ZxFmbTREvO5P3xBFOQTreMGZfKsK0sCSBjjfzGm7N99zn6eDgqAqtNotz+dMFeMfoDX3shl7M8AiAgi+9ujEk7sronsQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1620396682; bh=ohFxgaFtrMKIP+GqldmEgYTGkj41jWrNcrE4+6G6iwq=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=fsFQuy6ZpkiGTAflQ7dxMqjmnf/CHwnl11zdPVMTKBOZisW4dhS05OXUGoQWHeDiKzkVhMyKeH0xGNTeSRpWSfDKJ8ZuwHyqrO1pBsjq7sw1GuNTW/+cx+d+RROjEz1CfWID5W2BR8l0aLz2yD43L+OYALwijDXlHPV3lf0EDaG+CbgrqLcgl+a+E6DVazwKxvxo7pD4j9LUDl9t5V2xhYa3fMiKPHR8EUPdyfkm9Y8RWoY1mgu3FEzr36WxerBE2HC6sc9piKRQ0zFQYjVI355zMVkb3poAYXiYONNUsqGB2J/6oRR153E3j40/fLsgoq2yj7U+3lljWMAROlpplg==
X-YMail-OSG: i2lwXtkVM1msqmEL9sIYRqqqaU2uEYw1kLixPgTNvhyG0Wau8dwL.h53p8RVfDO Nyi0wlp.O9N.7rVnAR8ZLxejKFu6DDRMn8gA3vyhzucV6.rt8J6cTzQhaHBgKHLtoK4VcWIgZBRs 4tjdcsX4_dUCUY2cM1c8AIZvlnsXW.87qkJUa3HnO0Tlm6rVvAr0onABvZ3..8jMezIo7akpk5_2 ZTuFYLiqmA.KFsPU_KAs0jfv4xNP597rKYvdgGwQ97kTxie972bI8o4op66fozxgBmCuSVaxqRs3 RBbtHZ_N3v3VW9gGPnR.jb4dozA8jL01dZ1dniG.ynYaebRrH8J3Ewk3ci0JOrFDX6OUjt_uikNQ 49xo.xyoXGfraEC9.SsIzBIBY8w4f7Zm8X34e6bMQDEHFsbmPxksLb8mqowG78c2FcPj6rlfllJc DkXLSS3QS._vT5vdS4I4MpQt10nSlUFye2HnmP4NzoMGdDrQQjSUyUwYj230YmwX3sZu5VR_Cdv2 m7yg42RgTSFtbM7dCVuet3oOYIGQOK3w_yCl7HEMms_OsBIY763KFigSU.WGGPTHuRvSzqi2smqm cet28Kdu2qd7G2EHB3cbVMrbGXJN_rjPPPzYkxe.vWlRsDE3v_Ljr0dn9bbiHyJl_Kqv5sSr6wwf 3HClhl0Cpwz23MGr7l2zPic4AfLtftLsHk4l0207zZu1wu_VurtTDx3tf5YKPCbBnd12gz9E7Bk2 N_RCAjDIDKLF9tS.2.OTPE2.BQJA8PJmjDEPetpdFThuqxZSPdvD.YDQ1R1jsMJiKlt3yU61N2MO ewnA4ReaLX9HoqpZoup2M6rv9mfyeNy4bOQUFrIPAVL2846e5mW91WNIoYiANHZS6dHDSwZEiTzv cQHiNcdokpW2lckXcsAodWX5Zm2nA5gIIyeOW6nEQExQvokAkxqWmQ9xMkBYcc9pZglWqDg9pkXW VT4ZuJ.l4ogEqG5y7U24Ui7prgDGH6yT4BDeH3yZl6ZZsHOTD_i_9taLuEPDt7YR0K5Zv0ln_jeG Vr.PNcK6LJicDLeYKNngqBgaQOliIpajnmnyv0O.kK323_oIdgBocK32VtbhINBwA8HdjVjLmzJn SFHx30XI3R8agU0KHasIOqGsd_mlbc5GzDcIEpY5apPaT7gFCorxXwpvHf6XfhsgqL7i45P02Gl_ RexKgSnqrUZxiB95z5miog4MKXa7vs6kxnAMpbLMJsWpEqIhaX7EGKjE1PAan32R6SWmUjYRi0w_ mon4P66l7oGNEhzKCrA78e3oApB6cjQCQSFJkvYgjGKR.e_Fouk_aQNTa28M5AcYgaDhpe5npZBu dhI7Myi3LryeR9BgPFe5L3ztWXvPhUvWR6h_KP6jnbyZu1j28w4QrYv0xSmd7EuTeGQscvTFNGCR fojdMgpeUTwTXJFZYIDLRJBGH4Lxb66G1Q1dMyuYDnUW4cYD_muPFv5BKUJ_AyKxYcEq5zDtQqe6 yTfPXRW57oiOTbTvBaLbg8r4aYions8_Y9RDJ9q1iVh39Jyn5VF4BClCA78q5WmpeIGb_SvAxnSG Rljg80pu39fbU7gYSv1lXtKchTtY6c6gZR1AEGtCAhSoifgjWdIs8lOpT3ssIW2Pwzr43v_ydnqg UVDCw6ksGCjjdPgUGAPPnYwTRXADT6kMwTzd34RZCk7hLZBwJHCqE1Ov88i_KCQVAT3Gpz8.P7iG q3ppQvw0VFLkeAsAmrvbB7QcETfpfgy9SXc4rAZ0S2aylD99vO7i52ZCtF3xCAqsklgtVITdQ8ul xI.qXRY8NkNAyTfZTRmfNs0ADCj_zqpfbfp8uyp8hWsDc_7Nc7DM.N1yT.mpLBwkPRJ2gS5ZkJdn NEj9Cl8fYHwefXmbAP5AP6zew2wZPMH1ycNBWqgK4D7XMF4cdT.AgOnaIpz30zjzM9uyYHq1f6n2 wJ3ovLJGbpNcrvVspYf6ljFvMZp.d3Jdy4R1.B_yAApnzZ8Gr2ZlKSCV1mCXAFU7Fn_E0uKt7fU2 2B3kt8V82iWwjWujk2aa2CzI1zGhF2SOq.02IHEzw6FsuZyqIwQLyUubsyaKyszx39QOR5ogKAEg BYCRimDnG03WbytuiJHX_E5.yevsK5qO.9MmNUX0esWx5dUYVRF1..1DkwjqADqyxep1RJ6fZ5Iu CCjr4F7ZI_aKA9JO1WsEMjDOXn9S0jIVb7sVbGJJ0V4EEQLv5WN6dkwjG.9KMcf4ztp9zuaWr9JG sflmDVG_c0j79btC8zVAa5HQRYVfwa4ZRWlaJdsGR_sRtTUz3D_ztHWsGF_wXCvF.HFm483DSyYf zh_YQQMowlAOMqIIaI1l1A2YKRJdKw8buRVxOD.eHo_9X5_wW52XtnHGwDBKZVocEHlBIqNaMfoU UiGXApFzjF_6zfhSWlSnFJNTVVGexb9FKMYYoBWSuwXVWCgkHkXuyRRe9t_6xsB1sYYIBp9DeytW uKbib1pNkdNVorzzgvS6t8OkfFuTYm.A1uVhmx_oXSG6QF0YEiLu4EmxFgo.ktR1P7VOYBztjAWq E2qyxtMWBUBUXtSg66m_1Xh5xInSdhr8x.7rrgLp65cRMmaJjJwUpAdGxM4Ee9rbnhFy5i9r1mxO _7uQv_LwAll0KG50s8w4Cgat53CQBYVfy4trRF0gkwCw66SwNRyKYHiQKPzYv9.2DFXGqbjYxR53 Mn02aGhHBsfzt6UUqoFY9b6Upaz3s8DAFBnjPfMB5eqr2pI4lL0BoUvcVFCFarlY_O25IylLnjvd aHLhPAuGsqYN7HJbblIKA6PmiNgM-
X-Sonic-MF: <i_bryskin@yahoo.com>
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ne1.yahoo.com with HTTP; Fri, 7 May 2021 14:11:22 +0000
Date: Fri, 7 May 2021 14:10:54 +0000 (UTC)
From: Igor Bryskin <i_bryskin@yahoo.com>
To: =?UTF-8?Q?Oscar_Gonz=C3=A1lez_de_Dios?= <oscar.gonzalezdedios@telefonica.com>, Shunsuke Homma <shunsuke.homma.ietf@gmail.com>
Cc: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "teas@ietf.org" <teas@ietf.org>, Loa Andersson <loa@pi.nu>
Message-ID: <846651974.1600663.1620396654181@mail.yahoo.com>
In-Reply-To: <CAKr2Fb9Krrqe7SWB4Zxyp8y8q1S1-jR2=Z3KkoF89cwhOEV4bg@mail.gmail.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> <CAKr2Fb9Krrqe7SWB4Zxyp8y8q1S1-jR2=Z3KkoF89cwhOEV4bg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_1600662_950559792.1620396654176"
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/8lj4HLYrdzKNPOrnbzq4xnrZNqs>
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: Fri, 07 May 2021 14:11:32 -0000

 Hi Joel,
     As far as I can tell, the client should not be trying to control the
details of which instance is used to fill the service function
requirements.IB>> But is not possible that in  the chain:AccessPoint 1 -> SF1->SF2->...-> AccessPoint2 the client cares about SF1->SF2 delay more than  about AccessPoint1 to AccessPoint2 delay ?
      Constraints like "stay out of a certain country", or
"stay within a given country" would be expressed in terms of the
properties the slice is to meet (service level expectations).  Not by
controlling particular aspects of the service.
IB>> What if I want to stay away, say, from a particular DC? Would it be easier and more flexible to express such exclusions/inclusions in terms of an abstract topology nodes representing countries, DCs, internal networks, etc.?

Igor

    On Thursday, May 6, 2021, 11:14:07 PM EDT, Shunsuke Homma <shunsuke.homma.ietf@gmail.com> wrote:  
 
 Hi,
Firstly, I also follow the WG consensus, and I’m ok to use “customer” if WG prefers it.
I assume there are mainly two types of use cases on (IETF) network slices:1. Providing slices to externals(customers) as a network service 2. Operating some internal network resources with the same slice system with case1
As far as I read other comments on the terms, most of people seem to focuses on use cases where IETF network slices are provided as a type of network services (i.g., case1), and I’d like to confirm if case2 is also in our scope and “customer” can cover both cases. (I personally want to avoid using different terms depending on assumed use cases).


Btw, I agree with that slice management would be important, and we’ll need to clarify what “customers” and “providers” can do on slice managements. In my memory, the NS-DT’s study was started with an assumption that resources should be abstracted from several reasons, such as usability, scalability, security, etc. In this assumption, in my understanding, who controls network resources will be always slice provider (i.e., the owner of NSC). In other words, customers never manage resources structuring a slice directly, and a customer will send a service request to a slice provider/NSC when he/she wants to create/change/delete a slice. (I think this is fit to operation models considered in other SDOs such as TMF.) 




What can be done via service request will depend on design of slice service, and the current definition part provides just minimal sets of selectable parameters as SLOs. More details are provided in NBI drafts.




Regards,




Shunsuke 

2021年5月6日(木) 20:53 Oscar González de Dios <oscar.gonzalezdedios@telefonica.com>om>:

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