Subject: [Teas] I-D Action: draft-ietf-teas-ietf-network-slice-nbi-yang-01.txt

From: [email-masked]
Date: Fri, 04 Mar 2022 01:59:44 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Traffic Engineering Architecture and Signaling WG of the IETF.

        Title           : IETF Network Slice Service YANG Model
        Authors         : Bo Wu
                          Dhruv Dhody
                          Reza Rokui
                          Tarek Saad
                          Liuyan Han
	Filename        : draft-ietf-teas-ietf-network-slice-nbi-yang-01.txt
	Pages           : 61
	Date            : 2022-03-04

Abstract:
   This document defines a YANG model for the IETF Network Slice service
   model.  The model can be used by a IETF Network Slice customer to
   manage IETF Network Slice from an IETF Network Slice Controller
   (NSC).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slice-nbi-yang/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slice-nbi-yang-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-ietf-network-slice-nbi-yang-01

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

---

From: <[email-masked]>
Date: Fri, 4 Mar 2022 14:44:44 +0000

Hi Bo, all, 

A discussion I had this morning with some colleagues that reminded me a comment made during the call of adoption vs. 9181. They prefer reusing as much as possible from stable modules. 

I thus reiterate my comment to add an formal import of RFC9181 rather than grabbing some nodes for it. The import approach will also ease grafting the various pieces for those who will rely upon LxNMs to realize network slices. 

For example, there is no need to redefine identity ns-connectivity-type as this maps what is in 9181, idem for endpoint-role. You can reuse service-status and many other nodes as the module is getting mature.

Thank you.
 
Cheers,
Med

> -----Message d'origine-----
> De : Teas <[email-masked]> De la part de [email-masked]
> Envoyé : vendredi 4 mars 2022 11:00
> À : [email-masked]
> Cc : [email-masked]
> Objet : [Teas] I-D Action: draft-ietf-teas-ietf-network-slice-nbi-yang-
> 01.txt
> 
> 
> _______________________________________________
> Teas mailing list
> [email-masked]
> 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.

---

From: John E Drake <[email-masked]>
Date: Fri, 4 Mar 2022 14:50:06 +0000

I completely agree with this.

Yours Irrespectively,

John

Juniper Business Use Only

> -----Original Message-----
> From: Teas <[email-masked]> On Behalf Of
> [email-masked]
> Sent: Friday, March 4, 2022 9:45 AM
> To: [email-masked]
> Subject: Re: [Teas] I-D Action: draft-ietf-teas-ietf-network-slice-nbi-yang-01.txt
> 
> [External Email. Be cautious of content]
> 
> 
> Hi Bo, all,
> 
> A discussion I had this morning with some colleagues that reminded me a
> comment made during the call of adoption vs. 9181. They prefer reusing as
> much as possible from stable modules.
> 
> I thus reiterate my comment to add an formal import of RFC9181 rather than
> grabbing some nodes for it. The import approach will also ease grafting the
> various pieces for those who will rely upon LxNMs to realize network slices.
> 
> For example, there is no need to redefine identity ns-connectivity-type as this
> maps what is in 9181, idem for endpoint-role. You can reuse service-status and
> many other nodes as the module is getting mature.
> 
> Thank you.
> 
> Cheers,
> Med
> 
> > De : Teas <[email-masked]> De la part de
> > [email-masked] Envoyé : vendredi 4 mars 2022 11:00 À :
> > [email-masked] Cc : [email-masked] Objet : [Teas] I-D Action:
> > draft-ietf-teas-ietf-network-slice-nbi-yang-
> > 01.txt
> >
> >
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-iet
> > f-teas-ietf-network-slice-nbi-__;!!NEt6yMaO-gk!XdoItMjCalIkvz-IbApH6i4
> > xKbJVlr51c9Kp8Ji7rh3H7DcPJcPokKpUWdKjVNE$
> > yang/
> >
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draf
> > t-ietf-teas-ietf-network-__;!!NEt6yMaO-gk!XdoItMjCalIkvz-IbApH6i4xKbJV
> > lr51c9Kp8Ji7rh3H7DcPJcPokKpU8axUFQU$
> > slice-nbi-yang-01
> >
> > https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-ie
> > tf-teas-ietf-network-slice-__;!!NEt6yMaO-gk!XdoItMjCalIkvz-IbApH6i4xKb
> > JVlr51c9Kp8Ji7rh3H7DcPJcPokKpUNl4ep1E$
> > nbi-yang-01
> >
> >
> > Internet-Drafts are also available by rsync at
> > rsync.ietf.org::internet- drafts
> >
> >
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas
> > __;!!NEt6yMaO-gk!XdoItMjCalIkvz-IbApH6i4xKbJVlr51c9Kp8Ji7rh3H7DcPJcPok
> > KpUAKx3ld4$
> 
> _________________________________________________________________
> ________________________________________________________
> 
> 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.
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N
> Et6yMaO-gk!XdoItMjCalIkvz-
> IbApH6i4xKbJVlr51c9Kp8Ji7rh3H7DcPJcPokKpUAKx3ld4$