Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition - Appendix

"BRUNGARD, DEBORAH A" <db3546@att.com> Sat, 22 August 2020 12:07 UTC

Return-Path: <db3546@att.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 8D0C33A0812 for <teas@ietfa.amsl.com>; Sat, 22 Aug 2020 05:07:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.796
X-Spam-Level:
X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 Nv3ZNp-KXhdt for <teas@ietfa.amsl.com>; Sat, 22 Aug 2020 05:07:49 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C347E3A081C for <teas@ietf.org>; Sat, 22 Aug 2020 05:07:47 -0700 (PDT)
Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 07MC6pha043867; Sat, 22 Aug 2020 08:07:21 -0400
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049462.ppops.net-00191d01. with ESMTP id 3332ef0b8d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 22 Aug 2020 08:06:54 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 07MC3m5c029979; Sat, 22 Aug 2020 08:03:48 -0400
Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [135.47.91.93]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 07MC3iql029917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 22 Aug 2020 08:03:44 -0400
Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [127.0.0.1]) by zlp30488.vci.att.com (Service) with ESMTP id 017FB400AF90; Sat, 22 Aug 2020 12:03:44 +0000 (GMT)
Received: from GAALPA1MSGEX1DC.ITServices.sbc.com (unknown [135.50.89.116]) by zlp30488.vci.att.com (Service) with ESMTPS id BFA8C400AF73; Sat, 22 Aug 2020 12:03:43 +0000 (GMT)
Received: from GAALPA1MSGEX1DE.ITServices.sbc.com (135.50.89.118) by GAALPA1MSGEX1DC.ITServices.sbc.com (135.50.89.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Sat, 22 Aug 2020 08:03:43 -0400
Received: from GAALPA1MSGEX1DE.ITServices.sbc.com ([135.50.89.118]) by GAALPA1MSGEX1DE.ITServices.sbc.com ([135.50.89.118]) with mapi id 15.01.2044.004; Sat, 22 Aug 2020 08:03:36 -0400
From: "BRUNGARD, DEBORAH A" <db3546@att.com>
To: "Dongjie (Jimmy)" <jie.dong@huawei.com>
CC: David Sinicrope <david.sinicrope=40ericsson.com@dmarc.ietf.org>, Joel Halpern Direct <jmh.direct@joelhalpern.com>, Kiran Makhijani <kiranm@futurewei.com>, Vishnu Pavan Beeram <vishnupavan@gmail.com>, TEAS WG <teas@ietf.org>
Thread-Topic: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition - Appendix
Thread-Index: AQHWd0WwM49orxDf90+zmKjJ0J5mVqlB/ZgmgACATACAAE+JAP//xUDQgAFFdgCAADHZNg==
Date: Sat, 22 Aug 2020 12:03:36 +0000
Message-ID: <80077645-B609-4CB4-A5E5-FBAE7DA4D298@att.com>
References: <CA+YzgTvnv5nUZ6OYx9GkFUxDHxAFNvYsx5LrFfho3860_MLfZA@mail.gmail.com> <330a76d8-2f05-795f-42a6-01de094b54b4@joelhalpern.com> <BYAPR13MB2437D23542B163D477B583C8D95A0@BYAPR13MB2437.namprd13.prod.outlook.com> <93726585-ccdd-3460-e6c6-540f98ec9084@joelhalpern.com> <BYAPR13MB243700523A1B5D597973C1CCD95A0@BYAPR13MB2437.namprd13.prod.outlook.com> <2265a594-f48f-3903-d998-3bb764df627a@joelhalpern.com> <b7b110ce14344cadb74b80ea9ccce144@huawei.com> <f07c0de8-6d51-7ffe-7ff5-8fb13212708a@joelhalpern.com>, <3f563fbf4a3742a195e61d96844bd042@huawei.com> <MN2PR15MB29903640C9630924BA18B61E8F5B0@MN2PR15MB2990.namprd15.prod.outlook.com> <77124c508ce54822a70afc616c31e5cf@att.com>, <df95bfde97614e5b857b4ad4c785c0ce@huawei.com>
In-Reply-To: <df95bfde97614e5b857b4ad4c785c0ce@huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tm-snts-smtp: FDB3A3EACCE26B01D7DB714FFD632A1CDA558A3EF905098AF93ABDA10D226C432
Content-Type: multipart/alternative; boundary="_000_80077645B6094CB4A5E5FBAE7DA4D298attcom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-22_07:2020-08-21, 2020-08-22 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 malwarescore=0 spamscore=0 impostorscore=0 suspectscore=0 priorityscore=1501 bulkscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 phishscore=0 adultscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008220129
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/Cv1u1FBcBgT-uSZR5CDURyRiBlY>
Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition - Appendix
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: Sat, 22 Aug 2020 12:07:53 -0000

Hi Jie,
(Individual)

Yes, the term isolation needs careful definition. Here in this definition document, need to be careful in defining vs. realization (solutions). It’s always a difficult trade in any requirements document.

“Dedicated resources” has many interpretations for packet network technologies - especially when realized over a multilayer network. As noted in the ETSI document, virtualization technologies when used for infrastructure, especially 5G, the advantages are being flexible and dynamic. “Dedicated” is not mentioned.

If we were doing a document in SG15, “dedicated” is somewhat clear, though even there it always is entertaining when the question is asked “does it mean the older fixed fiber distribution panel”. But not in this document where we are discussing a virtual network topology (described in the document).

Best is to remove the example  for now - if any example in the appendix, use a VPN and/or TE VNT which are IETF technologies. But as this work is to understand what more is needed for our technologies, it would be confusing without a comprehensive solution explanation.

Thanks, Good weekends,
Deborah
(Individual)

On Aug 22, 2020, at 1:05 AM, Dongjie (Jimmy) <jie.dong@huawei.com> wrote:


Hi Deborah,

Thanks a lot for your comment.

As mentioned both in your mail and pervious mails by others and myself, network slicing is coupled with the concept of isolation in 5G related communities, such as 3GPP, GSMA, ETSI, etc. Similar to the term “transport” network, IMO it is also important to define or describe “isolation” for the IETF context, so as to avoid the possible confusion both in and outside IETF.

The text in the appendix is trying to give explanation about the isolation in the context of IETF or “transport” network, and it also tries to separate the requirement from realization. As explained in the text, isolation as a requirement has multi-dimension meanings, it can mean traffic separation or interference avoidance, etc., and each can be realized by some specific technologies, providing dedicated resource is just listed as one approach to realize some dimension of the requirement. The current text may need some improvement to better clarify the requirement and the realization separately, while such confusion just shows the necessity of explaining it further in IETF.

Best regards,
Jie

From: BRUNGARD, DEBORAH A [mailto:db3546@att.com]
Sent: Friday, August 21, 2020 11:51 PM
To: David Sinicrope <david.sinicrope=40ericsson.com@dmarc.ietf.org>; Dongjie (Jimmy) <jie.dong@huawei.com>; Joel Halpern Direct <jmh.direct@joelhalpern.com>; Kiran Makhijani <kiranm@futurewei.com>; Vishnu Pavan Beeram <vishnupavan@gmail.com>; TEAS WG <teas@ietf.org>
Subject: RE: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition - Appendix

Hi,

(speaking as an individual)

While the document is in it’s early stages, I think it is important to sort out this use of the term “isolation”. Already by use of the term “transport”, the scope of this work may be confused with the traditional definition of a transport network and overlapping with ITU-T SG15’s transport technologies. Important is to define “transport” carefully for the IETF context, which I think this document is a good start. Mixing “isolation” with “dedicated resources” is a step back to the traditional definition.

As the authors note, the term “isolation” is used in other SDOs, including 3GPP, but it is used differently. Here’s a recent publicly available white paper from ETSI NFV which summarizes the requirements from 3GPP for network slicing:
https://www.etsi.org/deliver/etsi_gr/NFV-EVE/001_099/012/03.01.01_60/gr_NFV-EVE012v030101p.pdf<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.etsi.org_deliver_etsi-5Fgr_NFV-2DEVE_001-5F099_012_03.01.01-5F60_gr-5FNFV-2DEVE012v030101p.pdf&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=gqhaYzybXCBPhw5oIBQATHe-nbZzzDh-oXrQZxU_2Gw&s=-IRr0tfeosn2ArvhNrpBKsQyiHvcabz_drsneDIBPUw&e=>

In this ETSI document, when they discuss isolation properties, physical resources are not mentioned, they discuss performance, resiliency, security, privacy and management. 3GPP recognizes resources may be logical or physical (and either fully or partly), it is not a “requirement”. Physical and virtual resources are used with respect to “realize”, not define.

I agree with Joel and Dave, I think Appendix A’s example saying a customer will request “dedicated resources” and saying the solution of using dedicated resources (vs. VPN)  guarantees the requirements are met, clashes with the rest of the document (section 5.3 and section 6) which carefully defines resources not as defining a slice but for realizing a slice. Maybe the authors intended it to be an example, but it is too confusing in the context of this document to mix the definition of “isolation” with “dedicated resources”. While an Appendix, it should not clash with the main document. Best is to remove for now.

Thanks,
Deborah
(individual)

From: Teas <teas-bounces@ietf.org<mailto:teas-bounces@ietf.org>> On Behalf Of David Sinicrope
Sent: Friday, August 21, 2020 9:11 AM
To: Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>; Joel Halpern Direct <jmh.direct@joelhalpern.com<mailto:jmh.direct@joelhalpern.com>>; Kiran Makhijani <kiranm@futurewei.com<mailto:kiranm@futurewei.com>>; Vishnu Pavan Beeram <vishnupavan@gmail.com<mailto:vishnupavan@gmail.com>>; TEAS WG <teas@ietf.org<mailto:teas@ietf.org>>
Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition - Appendix

Jie,
You note “isolation has been considered as one of the characteristics of network slicing in most of the related standards and publications, and it would be incomplete if the definition draft does not touch this. And in IETF history isolation has been considered as one requirement of VPNs, the discussion is necessary for explaining the relationship and difference between network slice and VPNs.”

I’m not sure where this is coming from. Do you have references to support these claims?  I’m specifically referring to the claim that “most” related standards and publications consider isolation as a characteristic.  This has not been my experience at all over the last 3 decades including the history of the IETF.

If anything the history of work on VPNs deals with identification of the traffic associated with the VPN not its isolation. Any treatment or characteristic of that traffic has been a function of QoS.

Isolation, in my experience, has not been part of the discussion or texts until the introduction of network slicing and only introduced by a subset of the community.

I agree the text on isolation is confusing and not needed.  I also ask that it be removed.

Thanks,
Dave


________________________________
From: Teas <teas-bounces@ietf.org<mailto:teas-bounces@ietf.org>> on behalf of Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>
Sent: Friday, August 21, 2020 4:26 AM
To: Joel Halpern Direct; Kiran Makhijani; Vishnu Pavan Beeram; TEAS WG
Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition - Appendix

Hi Joel,

Thanks for your clarification about the procedure.

What I meant is to provide some background about the design team's discussion, which may help the WG to review and give comments on this draft. Of course the decision will be made by the WG.

One of the reasons of keeping the isolation discussion in this draft is that isolation has been considered as one of the characteristics of network slicing in most of the related standards and publications, and it would be incomplete if the definition draft does not touch this. And in IETF history isolation has been considered as one requirement of VPNs, the discussion is necessary for explaining the relationship and difference between network slice and VPNs. Also note that in the last paragraph of the appendix, it tries to separate the requirements on isolation from several possible realization mechanism, which makes this description reasonably generic.

Best regards,
Jie


> -----Original Message-----
> From: Joel Halpern Direct [mailto:jmh.direct@joelhalpern.com]
> Sent: Friday, August 21, 2020 11:28 AM
> To: Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>; Kiran Makhijani
> <kiranm@futurewei.com<mailto:kiranm@futurewei.com>>; Vishnu Pavan Beeram
> <vishnupavan@gmail.com<mailto:vishnupavan@gmail.com>>; TEAS WG <teas@ietf.org<mailto:teas@ietf.org>>
> Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition -
> Appendix
>
> The consensus of the design team is relevant as a recommendation to the
> WG, but otherwise is not relevant for whether the WG should agree.  In
> terms of WG adoption, the design team draft has the same status as any
> other individual draft. The WG comes to its conclusion.
>
> There is no obligation for the WG to retain the text from the appendix
> anywhere.  In particular, the WG is under no obligation to retain the last
> paragraph of teh appendix anywhere.
>
> I have not seen any good argument for retaining the text.  It does not seem
> to add to or even fit with the purpose of the definitions draft.
> If anything, it is confusing at it seems to say "this is not a parameter / this is
> a parameter"
>
> Yours,
> Joel
>
> On 8/20/2020 11:17 PM, Dongjie (Jimmy) wrote:
> > Hi Joel,
> >
> > In the design team there were several rounds of discussion about the
> content in the appendix and where it should be placed. The current text in
> the appendix reflects the consensus of the design team, although some
> minor edits were not included yet.
> >
> > As for whether some of the text in appendix will be moved to the
> framework document, currently the design team has no specific opinion
> about this, and feedbacks from WG are appreciated. While as Kiran
> mentioned, description and discussion about isolation is needed in the NS-DT
> documents.
> >
> > Best regards,
> > Jie
> >
> >> -----Original Message-----
> >> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Joel M.
> >> Halpern
> >> Sent: Friday, August 21, 2020 7:00 AM
> >> To: Kiran Makhijani <kiranm@futurewei.com<mailto:kiranm@futurewei.com>>; Vishnu Pavan Beeram
> >> <vishnupavan@gmail.com<mailto:vishnupavan@gmail.com>>; TEAS WG <teas@ietf.org<mailto:teas@ietf.org>>
> >> Subject: Re: [Teas] WG adoption -
> >> draft-nsdt-teas-transport-slice-definition - Appendix
> >>
> >> Since I do not think that the material in the appendix is useful, I
> >> for one will not push for adding it to the Framework.  You are
> >> welcome to dabate adding it to the framework with the rest of the WG.
> >> But it does not belong in the definitions draft.
> >>
> >> Yours,
> >> Joel
> >>
> >> On 8/20/2020 5:20 PM, Kiran Makhijani wrote:
> >>> Hi Joel,
> >>> I am ok to remove some part from Appendix only if it is included in
> >>> the
> >> framework first.
> >>>
> >>> But for the TSRE, I have proposed clearer and shorter text that they
> >>> are not
> >> visible to the consumer of a transport slices. One of the purpose of
> >> definitions document is 'define' common terminology in the scope of
> >> transport slices, and all we are saying is that when realizing a
> >> transport slice, things TSEs will map to are called TSREs.
> >>> I am not able to see the drawback of saying so.
> >>>
> >>> Thanks
> >>> Kiran
> >>>
> >>>> -----Original Message-----
> >>>> From: Joel Halpern Direct <jmh.direct@joelhalpern.com<mailto:jmh.direct@joelhalpern.com>>
> >>>> Sent: Thursday, August 20, 2020 1:19 PM
> >>>> To: Kiran Makhijani <kiranm@futurewei.com<mailto:kiranm@futurewei.com>>; Vishnu Pavan Beeram
> >>>> <vishnupavan@gmail.com<mailto:vishnupavan@gmail.com>>; TEAS WG <teas@ietf.org<mailto:teas@ietf.org>>
> >>>> Subject: Re: [Teas] WG adoption -
> >>>> draft-nsdt-teas-transport-slice-definition
> >>>>
> >>>> No, your replies did not in any way address my concerns.
> >>>>
> >>>> I would suggest removing the references to TSRE and more
> >>>> importantly removing appendix A.1, or at least the last part of the
> appendix.
> >>>>
> >>>> Yours,
> >>>> Joel
> >>>>
> >>>> On 8/20/2020 2:54 PM, Kiran Makhijani wrote:
> >>>>> Hi Joel,
> >>>>> After having replied to your comments, we have not heard further
> >>>>> if they
> >>>> were convincing.
> >>>>> Please let us know.
> >>>>> Thanks
> >>>>> Kiran
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Teas <teas-bounces@ietf.org<mailto:teas-bounces@ietf.org>> On Behalf Of Joel M. Halpern
> >>>>>> Sent: Wednesday, August 19, 2020 9:04 AM
> >>>>>> To: Vishnu Pavan Beeram <vishnupavan@gmail..com<mailto:vishnupavan@gmail..com>>; TEAS WG
> >>>>>> <teas@ietf.org<mailto:teas@ietf.org>>
> >>>>>> Subject: Re: [Teas] WG adoption -
> >>>>>> draft-nsdt-teas-transport-slice-definition
> >>>>>>
> >>>>>> Without repairs to the issues I have raised on the email list, I
> >>>>>> do not think this document should be adopted as a WG document.
> >>>>>> We are close, but not quite there.
> >>>>>>
> >>>>>> Yours,
> >>>>>> Joel
> >>>>>>
> >>>>>> On 8/19/2020 11:50 AM, Vishnu Pavan Beeram wrote:
> >>>>>>> All,
> >>>>>>>
> >>>>>>> This is start of a *three* week poll on making
> >>>>>>> draft-nsdt-teas-transport-slice-definition-03 a TEAS working
> >>>>>>> group
> >>>>>> document.
> >>>>>>> Please send email to the list indicating "yes/support" or "no/do
> >>>>>>> not support". If indicating no, please state your reservations
> >>>>>>> with the document. If yes, please also feel free to provide
> >>>>>>> comments you'd like to see addressed once the document is a WG
> >> document.
> >>>>>>>
> >>>>>>> The poll ends September 9th (extra week to account for vacation
> >> season).
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Pavan and Lou
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Teas mailing list
> >>>>>>> Teas@ietf.org<mailto:Teas@ietf.org>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> https://protect2.fireeye.com/v1/url?k=7d132922-23b3ea8b-7d1369b9-86959e472243-a669baec95ff5981&q=1&e=8a1db88d-cb42-478e-8eb8-da70acca25e3&u=https%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fww<https://urldefense.proofpoint.com/v2/url?u=https-3A__protect2.fireeye.com_v1_url-3Fk-3D7d132922-2D23b3ea8b-2D7d1369b9-2D86959e472243-2Da669baec95ff5981-26q-3D1-26e-3D8a1db88d-2Dcb42-2D478e-2D8eb8-2Dda70acca25e3-26u-3Dhttps-253A-252F-252Fnam11.safelinks.protection.outlook.com-252F-253Furl-253Dhttps-25253A-25252F-25252Fww&d=DwMF-g&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=PIYtUeW125RV0PtLtAB1VkyAsOdbMntl_enBZv4d2qc&s=bUkqIf98ir2n0fhlYgEu_c2k4w8oW1idwDGwyySsfhA&e=>
> w.
> >>>>>>>
> >>>>>>
> >>>>
> >>
> ietf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40
> f
> >>>>>> utur
> >>>>>>>
> >>>>>>
> >>>>
> >>
> ewei.com%7Cf26ab959470747a36b2808d84459a351%7C0fee8ff2a3b24018
> 9
> >>>>>> c753a1d
> >>>>>>>
> >>>>>>
> >>>>
> >>
> 5591fedc%7C1%7C0%7C637334499094612048&amp;sdata=%2FGSlz2Q4%
> 2B
> >>>>>> RAlZTXBv5
> >>>>>>> XlCZ9YKaUKQ7C4IUIgdQDVJ%2Bk%3D&amp;reserved=0
> >>>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Teas mailing list
> >>>>>> Teas@ietf.org<mailto:Teas@ietf.org>
> >>>>>>
> >>>>
> >>
> https://protect2.fireeye.com/v1/url?k=19c50183-4765c22a-19c54118-86959e472243-be7fb3e456e3f9a6&q=1&e=8a1db88d-cb42-478e-8eb8-da70acca25e3&u=https%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fww<https://urldefense.proofpoint.com/v2/url?u=https-3A__protect2.fireeye.com_v1_url-3Fk-3D19c50183-2D4765c22a-2D19c54118-2D86959e472243-2Dbe7fb3e456e3f9a6-26q-3D1-26e-3D8a1db88d-2Dcb42-2D478e-2D8eb8-2Dda70acca25e3-26u-3Dhttps-253A-252F-252Fnam11.safelinks.protection.outlook.com-252F-253Furl-253Dhttps-25253A-25252F-25252Fww&d=DwMF-g&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=PIYtUeW125RV0PtLtAB1VkyAsOdbMntl_enBZv4d2qc&s=VhW4TGe4z7ZeD8qijXBRD9ZkiGcGBi0YJ6buh0kXY6A&e=>
> w
> >>>>>> .i
> >>>>
> >>
> etf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40f
> u
> >>>>>>
> >>>>
> >>
> turewei.com%7Cf26ab959470747a36b2808d84459a351%7C0fee8ff2a3b24
> 01
> >>>>>>
> >>>>
> >>
> 89c753a1d5591fedc%7C1%7C0%7C637334499094612048&amp;sdata=%2F
> G
> >>>>>>
> >>>>
> >>
> Slz2Q4%2BRAlZTXBv5XlCZ9YKaUKQ7C4IUIgdQDVJ%2Bk%3D&amp;reserved=
> 0
> >>>>>
> >>>>> _______________________________________________
> >>>>> Teas mailing list
> >>>>> Teas@ietf.org<mailto:Teas@ietf.org>
> >>>>>
> >>>>
> >>
> https://protect2.fireeye.com/v1/url?k=d37b5edd-8ddb9d74-d37b1e46-86959e472243-a54dacfae536c914&q=1&e=8a1db88d-cb42-478e-8eb8-da70acca25e3&u=https%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fww<https://urldefense.proofpoint.com/v2/url?u=https-3A__protect2.fireeye.com_v1_url-3Fk-3Dd37b5edd-2D8ddb9d74-2Dd37b1e46-2D86959e472243-2Da54dacfae536c914-26q-3D1-26e-3D8a1db88d-2Dcb42-2D478e-2D8eb8-2Dda70acca25e3-26u-3Dhttps-253A-252F-252Fnam11.safelinks.protection.outlook.com-252F-253Furl-253Dhttps-25253A-25252F-25252Fww&d=DwMF-g&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=PIYtUeW125RV0PtLtAB1VkyAsOdbMntl_enBZv4d2qc&s=KontY0Ex6UJRo2EpGG4LrA-TsJBJxvvILb-PVW6PMdI&e=>
> w.
> >>>>>
> >>>>
> >>
> ietf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40
> f
> >>>> utur
> >>>>>
> >>>>
> >>
> ewei.com%7C7bb861e35ac84653b62208d8454659ac%7C0fee8ff2a3b24018
> 9
> >>>> c753a1d
> >>>>>
> >>>>
> >>
> 5591fedc%7C1%7C1%7C637335515772670726&amp;sdata=MZQKraVa8fj3
> BL
> >>>> sLRq9T9a
> >>>>> Ypp3C%2Bu1w9c7DgIVE6kE0%3D&amp;reserved=0
> >>>>>
> >>
> >> _______________________________________________
> >> Teas mailing list
> >> Teas@ietf.org<mailto:Teas@ietf.org>
> >> https://www.ietf.org/mailman/listinfo/teas<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwMF-g&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=PIYtUeW125RV0PtLtAB1VkyAsOdbMntl_enBZv4d2qc&s=OFFFT8ma706KrhOLX304z0qEw74Wg7S_eelu5EONhKs&e=>
_______________________________________________
Teas mailing list
Teas@ietf.org<mailto:Teas@ietf.org>
https://www.ietf.org/mailman/listinfo/teas<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwMF-g&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=PIYtUeW125RV0PtLtAB1VkyAsOdbMntl_enBZv4d2qc&s=OFFFT8ma706KrhOLX304z0qEw74Wg7S_eelu5EONhKs&e=>