Re: [Teas] WG adoption poll: draft-contreras-teas-slice-nbi-06

[Adrian Farrel <[e-mail]>]

OK, this is also reasonable.

 

What we need, IMHO, is a better statement in the document about the purpose of the document.

Whether or not it advances for publication as an RFC may be less important to state, although I think it is important to understand that “support documents” don’t always progress.

 

Cheers,

Adrian

 

From: Teas <[e-mail]> On Behalf Of LUIS MIGUEL CONTRERAS MURILLO
Sent: 05 July 2022 12:06
To: [e-mail]; [e-mail]; 'Vishnu Pavan Beeram' <[e-mail]>; 'TEAS WG' <[e-mail]>
Cc: 'TEAS WG Chairs' <[e-mail]>
Subject: Re: [Teas] WG adoption poll: draft-contreras-teas-slice-nbi-06

 

Hi Adrian, Med, all,

 

Let me share my view in this specific point. I see the value on progressing this document separately as well as advancing it as potential RFC for several reasons. Certainly it intends to identify parameters to be taken into account by the NBI YANG model for making such NBI comprehensive (and not limited to few situations), but it can also provide referential material for other documents such as the framework document (some use cases are listed at the beginning without further elaboration), solutions documents (e.g., draft-srld-teas-5g-slicing, draft-barguil-teas-network-slices-instantiation, …), as well as others. 

 

Furthermore, it also provides a way of understanding how different use cases can make use of IETF Network Slices for solving the connectivity part, with adaptation of parameters and procedures not defined in IETF to those defined in IETF, then providing exemplary guidance on how to consume IETF Network Slices. Finally, it can help other WGs in IETF to provide overall context on the usage of IETF Network Slices.

 

A document like this was one of the objectives of the old Design Team, and the discussion on the mailing list just before IETF 113 made evident the need of having a reference in this respect. 

 

Best regards

 

Luis

 

De: Adrian Farrel <[e-mail] <mailto:[e-mail]> > 
Enviado el: martes, 5 de julio de 2022 12:15
Para: [e-mail] <mailto:[e-mail]> ; 'Vishnu Pavan Beeram' <[e-mail] <mailto:[e-mail]> >; 'TEAS WG' <[e-mail] <mailto:[e-mail]> >
CC: 'TEAS WG Chairs' <[e-mail] <mailto:[e-mail]> >
Asunto: RE: [Teas] WG adoption poll: draft-contreras-teas-slice-nbi-06

 

That’s a reasonable argument, Med. Thanks.

 

Might be nice to include a statement of intent in the Abstract/Introduction along the lines of “This document is intended to provide motivation and support for work on YANG models for the IETF Network Slice Service interface. As such, it might not be necessary to advance it to publication as an RFC.”

 

Cheers,

Adrian

 

From: [e-mail] <mailto:[e-mail]>  <[e-mail] <mailto:[e-mail]> > 
Sent: 05 July 2022 10:30
To: [e-mail] <mailto:[e-mail]> ; 'Vishnu Pavan Beeram' <[e-mail] <mailto:[e-mail]> >; 'TEAS WG' <[e-mail] <mailto:[e-mail]> >
Cc: 'TEAS WG Chairs' <[e-mail] <mailto:[e-mail]> >
Subject: RE: [Teas] WG adoption poll: draft-contreras-teas-slice-nbi-06

 

Hi Adrian, all,

 

(focusing on this specific comment below)

 

As you known, adopting does not mean that the document will make it to the RFC stage. IMO, this document is a good ** support document **. As such, it falls under https://www.ietf.org/about/groups/iesg/statements/support-documents/ and the WG may decide to let it expire when it serves its purposes or not. 

 

The merit I see in formally adopting is to have a WG reference to assess the slice service model against a set of cases and capture consensus about any missing attributes that need to be reflected in the service model itself. 

 

Cheers,

Med

 

De : Teas <[e-mail] <mailto:[e-mail]> > De la part de Adrian Farrel
Envoyé : dimanche 3 juillet 2022 01:33
À : 'Vishnu Pavan Beeram' <[e-mail] <mailto:[e-mail]> >; 'TEAS WG' <[e-mail] <mailto:[e-mail]> >
Cc : 'TEAS WG Chairs' <[e-mail] <mailto:[e-mail]> >
Objet : Re: [Teas] WG adoption poll: draft-contreras-teas-slice-nbi-06

 

Hi,

 

(Not late with this review!)

 

I only have one question about supporting the adoption of this document

and that is to wonder whether the work is overtaken by events. We

already have work progressing developing and specifying the IETF Network

Slice Service Interface YANG model in draft-ietf-teas-ietf-network-

slice-nbi-yang. That YANG model is surely based on discussions that 

arise from this work, and I am not doubting the value of those 

discussions. But I don't quite understand why we need to pursue this I-D

towards an RFC when it's principal purpose is surely to shape the 

content of the YANG model. Have I missed the purpose of this draft?

 

 

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

 

  _____  


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