Dear All, As suggested by WG chairs, we would like to spin one more version to address the comments during the adoption call and in that process will reach out to Joel and Hannu (separately) for specific inputs where terminology alignment has to happen w.r.t TEAS slicing definition draft.
Will keep you updated on the WG soon. -- Uma C. On Wed, Jan 6, 2021 at 2:40 PM Joel M. Halpern <j...@joelhalpern.com> wrote: > In line, > Joel > > On 1/6/2021 5:29 PM, Kaippallimalil John wrote: > > Joel, > > This draft is not attempting to lay out a new architecture. The figure > and architecture section are there to provide context for the reader. > > > > The draft is also not asserting that these are the only ways to solve > the issue. > > The last portion of the draft only refers to applicability since several > IETF technology (and even non IETF data plane like L2) may be used E2E in > the transport underlay corresponding to a 3GPP overlay (F1/W1, N3, N9). > > The draft is agnostic to any specific underlay. It is concerned with how > the slice type/QoS properties between 3GPP provider and subscriber (UE) is > realized as the data plane GTP packets (overlay) traverse one or more > transport underlay segments on path. > > At the veyr least, the draft needs significant rewording so taht it > clealry explains what you are saying here. As currently worded, it does > not lead the reader to that understanding. And as such, calls into > doubt what the supporters of adoption believe they are adopting. > > > > > The dmm working group seems to be a natural choice as folks there have > background and expertise in both IETF and 3GPP technologies. > > A WG looking like "the natural place" for something does not mean that > said working group actually has the given work in its charter. For > example, there were quite a number of drafts which were presented in the > SFC WG as the natural place for initial discussion, but which did not > fit within the SFC charter and therefore were not adopted by SFC as work > items. > > > > > Best Regards, > > John > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm >
_______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
