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

[Joel Halpern Direct <[e-mail]>]

I think Kiran that you are missing the point.
What actually matters are the measurables, not the inferences.

Sure, in the sales discussions if a customer asks "will my traffic be 
protected from competing traffic?" the answer will be "Yes, of course." 
When it comes time to write the contract and the SLA, which uses the 
SLOs, the contract terms will say things like
     Traffic X will always have avaiable bandwidth Y.
        [unstated, but assumed is "regardless of competing traffic"]
or
     Traffic Z will be delivered with delay variation less than A.
         [unstated, but assumed is "regardless of competing traffic"]

Isolation is not something special.  And it is not something that can be 
written into a customer agreement as a freestanding term.  Unless it is 
related to a measurable, none of the customer, the operator, or a judge 
trying to enforce the contract will know whether it has been met.

Similarly, what goes over the (northbound) interface this document is 
concerned with has to be measurables.  Otherwise they are not 
deliverable.  (And this applies to any derived southbound as well.)

The text in Appendix A simply sserves to confuse readers as to what we 
are doing.  Please, remove it.

Yours,
Joel


On 8/21/2020 9:28 PM, Kiran Makhijani wrote:
> Please see inline
> 
> *From:* Greg Mirsky <[e-mail]>
> *Sent:* Friday, August 21, 2020 4:21 PM
> *To:* Kiran Makhijani <[e-mail]>
> *Cc:* Joel M. Halpern <[e-mail]>; Luis M. Contreras 
> <[e-mail]>; Dongjie (Jimmy) <[e-mail]>; LUIS 
> MIGUEL CONTRERAS MURILLO <[e-mail]>; 
> Vishnu Pavan Beeram <[e-mail]>; TEAS WG <[e-mail]>
> *Subject:* Re: [Teas] WG adoption - 
> draft-nsdt-teas-transport-slice-definition - Appendix
> 
> Hi Kiran,
> 
> I have to admit that I'm confused by the last paragraph in your note.
> 
> First, you agree that isolation interpreted is not observable (though I 
> am not sure what quote marks around directly signify). But then you add 
> "will rely on other means of monitoring". Isn't any type of monitoring, 
> in fact, a method of a direct observation?
> 
> */[KM] It is not direct monitoring, it is an inference from some other 
> piece of information. (I was just thinking out loud, how could you prove 
> it)/*
> 
> Also, I sense that one of the motivations behind using the term 
> isolation is to differentiate between physical and virtual instances 
> that provide a service, e.g., physical link vs. a link in the overlay 
> network. If that is the case, perhaps we can avoid the contention around 
> the use of the term isolation as SLO
> 
> */[KM] it is not an SLO, it is an additional ask or specification./*
> 
> and instead add a parameter that can have two values, physical and virtual?
> 
> */[KM] Yes, it could work but it is too specific to the example, what if 
> there were others. I prefer something along the lines of 
> traffic-separation./*
> 
> Regards,
> 
> Greg
> 
> On Fri, Aug 21, 2020 at 3:53 PM Kiran Makhijani <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     Hi Joel,
>     Looks like your main concern is that text seem to say that isolation
>     is observable.
> 
>     That's not the intent. We just wanted to scope 'isolation' with in
>     the context of transport slices not define it. During IETF 107 you
>     gave a feedback that isolation is not directly observable, and we
>     all completely agreed, dropped a lot of text accordingly.
> 
>     In this text, the important piece is to capture that customer could
>     also be very specific about asking "my traffic should be separated
>     from (or should have no interference with) other traffic".
>     This is not covered in the document and without such clarification,
>     we cannot scope NBI properly. I was thinking if we define
>     'isolation' then that can be a container in NBI. One common use case
>     where customer could ask this is financial institutions or critical
>     infrastructure explicitly asking for a (or a set of) physical ports
>     or links.
> 
>     The last para simply says there are 3 related things that customer
>     could explicitly ask for (termed as 'isolation') and when realizing
>     transport slices operators could possibly do so & so to meet those asks.
> 
>     An alternative to deleting the text maybe  - don’t use term
>     isolation but describe explicit requirement of traffic separation.
>     And maybe clearly say this is not 'directly' observable and will
>     rely on other means of monitoring that are case specific such as
>     mapping physical port counters to service counters etc.
> 
>     -Kiran
> 
>      > -----Original Message-----
>      > From: Joel M. Halpern <[e-mail]
>     <mailto:[e-mail]>>
>      > Sent: Friday, August 21, 2020 8:42 AM
>      > To: Luis M. Contreras <[e-mail]
>     <mailto:[e-mail]>>; Dongjie (Jimmy)
>      > <[e-mail] <mailto:[e-mail]>>
>      > Cc: Kiran Makhijani <[e-mail]
>     <mailto:[e-mail]>>; Vishnu Pavan Beeram
>      > <[e-mail] <mailto:[e-mail]>>; TEAS WG
>     <[e-mail] <mailto:[e-mail]>>; LUIS MIGUEL
>      > CONTRERAS MURILLO <[e-mail]
>     <mailto:[e-mail]>>
>      > Subject: Re: [Teas] WG adoption -
>     draft-nsdt-teas-transport-slice-definition -
>      > Appendix
>      >
>      > Luis, I think I disagree with you.
>      > Not of course, about the question of whether operators care about
>     isolation
>      > properties.
>      > But about whether it belongs in this document.
>      >
>      > I am quite sure that when designing services for customers, you
>     and your team
>      > worry about many forms of isolation.  Many of which do not appear
>     in the
>      > eventual SLA (even if they do occur in informal discussion).  And
>     many of which
>      > do not appear as explicit parameters on any of the interfaces.
>      >
>      > The authors attempted t provide an observable definition of
>     isolation.
>      > They were not able to do so.  The text they now have tries to
>     claim utility,
>      > claims relevance to the customer, but is not actually usable in
>     designing a
>      > service.
>      >
>      > "Isolation" as a network property probably is actually many different
>      > properties.  For example, a bandwidth commitment (which we do
>     have in the
>      > definitions) is a form of isolation.  A delay variation
>     commitment is a form of
>      > isolation.  But as a term on its own, separate from these
>     parameters, "isolation"
>      > does not add value to this document.
>      >
>      > Also remember that no document we produce will be or can bee
>     complete.
>      > We produce useful pieces.  You put them together.  As an operator
>     you add
>      > your many constraints, your customers goals and constraints, and
>     you build and
>      > deliver service.
>      >
>      > Yours,
>      > Joel
>      >
>      > On 8/21/2020 4:49 AM, Luis M. Contreras wrote:
>      > > Hi Jie, Joel, all,
>      > >
>      > > Just to share my view. The idea of isolation is intrinsically
>     related
>      > > to the notion of slice in the industry, and as such it should be
>      > > covered in the definitions draft when referring to transport
>     slices.
>      > >
>      > > The development of what isolation implies, in practical terms,
>     could
>      > > go to the framework draft or to any other specific document,
>     and for
>      > > sure we can expect references to degrees of isolation achieved
>     in the
>      > > mapping of slicing mechanisms to distinct transport technologies
>      > > through the SBI of the TSC.
>      > >
>      > > Not covering isolation at all, basically makes the work on
>     transport
>      > > slicing incomplete from an operator’s perspective.
>      > >
>      > > In that sense I support keeping the text on isolation (as an
>     annex or
>      > > in the main part of the document). For sure the text can be always
>      > > improved, but as it is now is a sufficiently generic definition to
>      > > facilitate the development of its scope when applied to transport
>      > > slicing in any other document.
>      > >
>      > > Best regards,
>      > >
>      > > Luis
>      > >
>      > >
>      > > El vie., 21 ago. 2020 a las 10:26, Dongjie (Jimmy)
>      > > (<[e-mail] <mailto:[e-mail]>
>      > > <mailto:[e-mail] <mailto:[e-mail]>>>)
>     escribió:
>      > >
>      > >     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:[e-mail] <mailto:[e-mail]>
>      > >     <mailto:[e-mail]
>     <mailto:[e-mail]>>]
>      > >      > Sent: Friday, August 21, 2020 11:28 AM
>      > >      > To: Dongjie (Jimmy) <[e-mail]
>     <mailto:[e-mail]>
>      > >     <mailto:[e-mail] <mailto:[e-mail]>>>;
>     Kiran Makhijani
>      > >      > <[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>>; Vishnu
>      > >     Pavan Beeram
>      > >      > <[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>>; TEAS WG
>      > >     <[e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>>
>      > >      > 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 the 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:[e-mail]
>     <mailto:[e-mail]>
>      > >     <mailto:[e-mail]
>     <mailto:[e-mail]>>] On Behalf Of Joel M.
>      > >      > >> Halpern
>      > >      > >> Sent: Friday, August 21, 2020 7:00 AM
>      > >      > >> To: Kiran Makhijani <[e-mail]
>     <mailto:[e-mail]>
>      > >     <mailto:[e-mail]
>     <mailto:[e-mail]>>>; Vishnu Pavan Beeram
>      > >      > >> <[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>>; TEAS
>      > >     WG <[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>>
>      > >      > >> 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
>     <[e-mail] <mailto:[e-mail]>
>      > >     <mailto:[e-mail]
>     <mailto:[e-mail]>>>
>      > >      > >>>> Sent: Thursday, August 20, 2020 1:19 PM
>      > >      > >>>> To: Kiran Makhijani <[e-mail]
>     <mailto:[e-mail]>
>      > >     <mailto:[e-mail]
>     <mailto:[e-mail]>>>; Vishnu Pavan Beeram
>      > >      > >>>> <[e-mail]
>     <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>>;
>      > TEAS
>      > >     WG <[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>>
>      > >      > >>>> 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 <[e-mail]
>     <mailto:[e-mail]>
>      > >     <mailto:[e-mail]
>     <mailto:[e-mail]>>> On Behalf Of Joel M. Halpern
>      > >      > >>>>>> Sent: Wednesday, August 19, 2020 9:04 AM
>      > >      > >>>>>> To: Vishnu Pavan Beeram <[e-mail]
>     <mailto:[e-mail]>
>      > >     <mailto:[e-mail]
>     <mailto:[e-mail]>>>; TEAS WG
>      > >      > >>>>>> <[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>>
>      > >      > >>>>>> 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
>      > >      > >>>>>>> [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>      > >      > >>>>>>>
>      > >      > >>>>>>
>      > >      > >>>>
>      > >      > >>
>      > >      >
>      > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
>      > >      > w.
>      > >      > >>>>>>>
>      > >      > >>>>>>
>      > >      > >>>>
>      > >      > >>
>      > >      > ietf.org
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.org%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488898959798&sdata=i%2FH%2Fm%2FGG4ritzVpp08xIzXIK4YNiMj6Bqinei%2F7mGiI%3D&reserved=0>
>      > >
>      >
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.or
>      > g%2F&amp;data=02%7C01%7Ckiranm%40futurewei.com
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F40futurewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488898969798&sdata=0vi%2FPjQDQF784ogZ3pZMeGneN4bceuPPuihcHOoeBTU%3D&reserved=0>%7C6e84819cea1748c
>      > 9f64308d845e8c14b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63
>      > 7336213276038270&amp;sdata=YEYEYBqLKk3v%2BrBZ%2FvEqYRqPq9m1eITo
>      > eHak5DEVtDQ%3D&amp;reserved=0>%2Fmailman%2Flistinfo%2Fteas&amp;da
>      > ta=02%7C01%7Ckiranm%40
>      > >      > f
>      > >      > >>>>>> utur
>      > >      > >>>>>>>
>      > >      > >>>>>>
>      > >      > >>>>
>      > >      > >>
>      > >      > ewei.com
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488898969798&sdata=k49Ao2avtmNlZZSLxFrtYPkzSSJ12W6dcAnSZfR6IGA%3D&reserved=0>
>      > >
>      >
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fewei.c
>      > om%2F&amp;data=02%7C01%7Ckiranm%40futurewei.com
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F40futurewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488898979787&sdata=OPhISgDytgKqV7i9r2sIcriQd6XIt0eBZYZi7B0HYt4%3D&reserved=0>%7C6e84819cea174
>      > 8c9f64308d845e8c14b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C
>      > 637336213276038270&amp;sdata=PDkVSDt7Cr1L01rmtnysaKRRafqOmKfrr9sN
>      > G%2BmbpcA%3D&amp;reserved=0>%7Cf26ab959470747a36b2808d84459a35
>      > 1%7C0fee8ff2a3b24018
>      > >      > 9
>      > >      > >>>>>> c753a1d
>      > >      > >>>>>>>
>      > >      > >>>>>>
>      > >      > >>>>
>      > >      > >>
>      > >      >
>      > 5591fedc%7C1%7C0%7C637334499094612048&amp;sdata=%2FGSlz2Q4%
>      > >      > 2B
>      > >      > >>>>>> RAlZTXBv5
>      > >      > >>>>>>> XlCZ9YKaUKQ7C4IUIgdQDVJ%2Bk%3D&amp;reserved=0
>      > >      > >>>>>>>
>      > >      > >>>>>>
>      > >      > >>>>>> _______________________________________________
>      > >      > >>>>>> Teas mailing list
>      > >      > >>>>>> [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>      > >      > >>>>>>
>      > >      > >>>>
>      > >      > >>
>      > >      >
>      > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
>      > >      > w
>      > >      > >>>>>> .i
>      > >      > >>>>
>      > >      > >>
>      > >      > etf.org
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fetf.org%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488898989785&sdata=qk3DEhb0CDuMWuv5Bvby5v8hASoBaedDVA5KWyaVvUU%3D&reserved=0>
>      > >
>      >
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fetf.org
>      > %2F&amp;data=02%7C01%7Ckiranm%40futurewei.com
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F40futurewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488898989785&sdata=nwlLNsIR4YHNSqH6FkKSmiY9RQr3v4AqNc8oJm2JpaI%3D&reserved=0>%7C6e84819cea1748c
>      > 9f64308d845e8c14b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63
>      > 7336213276038270&amp;sdata=He3XPdNABefXKOz92Z0QYR2Va2KIe43lclCTD7
>      > 12p5M%3D&amp;reserved=0>%2Fmailman%2Flistinfo%2Fteas&amp;data=02
>      > %7C01%7Ckiranm%40f
>      > >      > u
>      > >      > >>>>>>
>      > >      > >>>>
>      > >      > >>
>      > >      > turewei.com
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fturewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488898999777&sdata=gmGb4yQzcuu%2Ba3gy2Vk7g9ArOPYJEJ2nuEKV0dPV97Q%3D&reserved=0>
>      > >
>      >
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fturew
>      > ei.com
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488898999777&sdata=NqB51hPKoN7hh7lCvTw4EZ8jc%2Bp86Wz4ydg0uI2K%2BVM%3D&reserved=0>%2F&amp;data=02%7C01%7Ckiranm%40futurewei.com
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F40futurewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899009773&sdata=A6VwFF%2BX9vWDkDbubs6ZwJ5yWecRxCH27Il1chW3fGE%3D&reserved=0>%7C6e84819cea
>      > 1748c9f64308d845e8c14b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0
>      > %7C637336213276038270&amp;sdata=7PuKdwn1Yyw9PIxiIfj62%2Bya%2FBPG
>      > fkCKgMnpTNbtAPs%3D&amp;reserved=0>%7Cf26ab959470747a36b2808d844
>      > 59a351%7C0fee8ff2a3b24
>      > >      > 01
>      > >      > >>>>>>
>      > >      > >>>>
>      > >      > >>
>      > >      >
>      > 89c753a1d5591fedc%7C1%7C0%7C637334499094612048&amp;sdata=%2F
>      > >      > G
>      > >      > >>>>>>
>      > >      > >>>>
>      > >      > >>
>      > >      >
>      > Slz2Q4%2BRAlZTXBv5XlCZ9YKaUKQ7C4IUIgdQDVJ%2Bk%3D&amp;reserved=
>      > >      > 0
>      > >      > >>>>>
>      > >      > >>>>> _______________________________________________
>      > >      > >>>>> Teas mailing list
>      > >      > >>>>> [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>      > >      > >>>>>
>      > >      > >>>>
>      > >      > >>
>      > >      >
>      > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
>      > >      > w.
>      > >      > >>>>>
>      > >      > >>>>
>      > >      > >>
>      > >      > ietf.org
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.org%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899009773&sdata=YtwHjHJMdexxmf%2FgOtni7FuMCK%2BoN1tEzO83sKs39vQ%3D&reserved=0>
>      > >
>      >
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.or
>      > g%2F&amp;data=02%7C01%7Ckiranm%40futurewei.com
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F40futurewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899019770&sdata=Ebx7iTH1ZHOZYHLJRPJkiTOq2f101QGxoj7diCDpLy0%3D&reserved=0>%7C6e84819cea1748c
>      > 9f64308d845e8c14b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63
>      > 7336213276038270&amp;sdata=YEYEYBqLKk3v%2BrBZ%2FvEqYRqPq9m1eITo
>      > eHak5DEVtDQ%3D&amp;reserved=0>%2Fmailman%2Flistinfo%2Fteas&amp;da
>      > ta=02%7C01%7Ckiranm%40
>      > >      > f
>      > >      > >>>> utur
>      > >      > >>>>>
>      > >      > >>>>
>      > >      > >>
>      > >      > ewei.com
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899029764&sdata=L6TlRSA7R%2FUEhvbO1G7ILnBQrB6v%2BE4HKXwZrep8MnE%3D&reserved=0>
>      > >
>      >
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fewei.c
>      > om%2F&amp;data=02%7C01%7Ckiranm%40futurewei.com
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F40futurewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899029764&sdata=Srzj8P8Wtu%2BjzqWJraL01gfMDOQPos%2F6ld8NWW4xT%2BI%3D&reserved=0>%7C6e84819cea174
>      > 8c9f64308d845e8c14b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C
>      > 637336213276038270&amp;sdata=PDkVSDt7Cr1L01rmtnysaKRRafqOmKfrr9sN
>      > G%2BmbpcA%3D&amp;reserved=0>%7C7bb861e35ac84653b62208d8454659a
>      > c%7C0fee8ff2a3b24018
>      > >      > 9
>      > >      > >>>> c753a1d
>      > >      > >>>>>
>      > >      > >>>>
>      > >      > >>
>      > >      >
>      > 5591fedc%7C1%7C1%7C637335515772670726&amp;sdata=MZQKraVa8fj3
>      > >      > BL
>      > >      > >>>> sLRq9T9a
>      > >      > >>>>> Ypp3C%2Bu1w9c7DgIVE6kE0%3D&amp;reserved=0
>      > >      > >>>>>
>      > >      > >>
>      > >      > >> _______________________________________________
>      > >      > >> Teas mailing list
>      > >      > >> [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>      > >      > >>
>      >
>     https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
>      > etf.org
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fetf.org%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899039761&sdata=Hj%2B1D5kmLTUoVvYkj1MfuXhJvEP62dzttTslX7mFFdQ%3D&reserved=0>%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40fut
>      > urewei.com
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Furewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899039761&sdata=Vmir%2FW4ezf1i5fEseTzWYPycP%2FYBEERhEY031WZLWf8%3D&reserved=0>%7C6e84819cea1748c9f64308d845e8c14b%7C0fee8ff2a3b240189c
>      > 753a1d5591fedc%7C1%7C0%7C637336213276038270&amp;sdata=7y5PXKjGP
>      > WZBvHzDObgm3N64pexXe8yeS8zH0YpWfNw%3D&amp;reserved=0
>      > >     _______________________________________________
>      > >     Teas mailing list
>      > > [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>      > >
>      > >
>      >
>     https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
>      > >
>      > ietf.org
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.org%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899049755&sdata=tvLFMHdzMdqH6k9k977HSkSpfcTmCKZoXrdo7cwW9AQ%3D&reserved=0>%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40fut
>      > ur
>      > >
>      > ewei.com
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899049755&sdata=ZW9NvXJ6ux5gcNvgjWII%2BQsGaL3YRKS32Q8Bh1uFseg%3D&reserved=0>%7C6e84819cea1748c9f64308d845e8c14b%7C0fee8ff2a3b240189c75
>      > 3a1d
>      > >
>      > 5591fedc%7C1%7C0%7C637336213276038270&amp;sdata=7y5PXKjGPWZBvHz
>      > DObgm3N
>      > > 64pexXe8yeS8zH0YpWfNw%3D&amp;reserved=0
>      > >
>      > >
>      > >
>      > > --
>      > > ___________________________________________
>      > > Luis M. Contreras
>      > > [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>      > > [e-mail]
>     <mailto:[e-mail]>
>      > > <mailto:[e-mail]
>     <mailto:[e-mail]>>
>      > > Global CTIO unit / Telefonica
>     _______________________________________________
>     Teas mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/teas
>     <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899059751&sdata=KzFInnEA4Q3bmCD1NXkAX6dCxrzJwT%2BKv1NbOAcYX1o%3D&reserved=0>
>