Re: [Teas] New Version Notification for draft-wd-teas-ietf-network-slice-nbi-yang-03.txt

[[e-mail]]

Hi Kenichi, 

Thanks for the follow-up. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Ogaki, Kenichi [mailto:[e-mail]]
> Envoyé : mardi 13 juillet 2021 06:26
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>;
> [e-mail]
> Objet : RE: New Version Notification for draft-wd-teas-ietf-network-
> slice-nbi-yang-03.txt
> 
> Hi Med and All,
> 
> Thanks for your comments.
> 
> >(1) I don't expect draft-wd-teas-ietf-network-slice-nbi-yang to
> enter to specifics about how to realize a slice but to focus on the
> required data nodes to manage (including request) slices.
> 
> We totally agree with your opinion, but the solution is definitely
> similar as the existing solution, actn-vn-yang. The characteristics
> of most of data nodes are same and just renamed for ietf-network-
> slice.

[Med] This is a fair observation. I still don't think it is not sufficient to have an "ns-" prefix but have only generic data nodes. 

> In such a case, reinventing the wheel is allowed or the existing
> solution should be augmented.
> Which is correct approach as IETF procedure? That's our question.

[Med] Fair. This is why it is important to step back and try to answer: what are we trying to model? If this is just connectivity, then are there slice specifics? Etc. 

> 
> >(2) It is true that the data nodes that characterize the slice
> service within the slice provider are technology-agnostic, but
> aren't for the CE-PE attachment as this conditions how the service
> is delivered.
> 
> We totally agree with you. Inside a slice, technology should be
> agnostic, but the demarcation point inside/outside the slice cannot
> avoid being technology specific.

[Med] Glad to see we are in agreement. 

> 
> >(3) The applicability of ACTN should IMHO be more part of I-Ds such
> as draft-barguil-teas-network-slices-instantation, not draft-wd-
> teas-ietf-network-slice-nbi-yang.
> 
> We will check.
> 
> 
> Thanks,
> Kenichi
> 
> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: Monday, July 12, 2021 4:59 PM
> To: 大垣 健一 <[e-mail]>; [e-mail]
> Subject: RE: New Version Notification for draft-wd-teas-ietf-
> network-slice-nbi-yang-03.txt
> 
> Hi Kenichi, all,
> 
> All good points, but I will focus on you first point below:
> 
> (1) I don't expect draft-wd-teas-ietf-network-slice-nbi-yang to
> enter to specifics about how to realize a slice but to focus on the
> required data nodes to manage (including request) slices.
> 
> (2) It is true that the data nodes that characterize the slice
> service within the slice provider are technology-agnostic, but
> aren't for the CE-PE attachment as this conditions how the service
> is delivered.
> 
> (3) The applicability of ACTN should IMHO be more part of I-Ds such
> as draft-barguil-teas-network-slices-instantation, not draft-wd-
> teas-ietf-network-slice-nbi-yang.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Teas [mailto:[e-mail]] De la part de Ogaki,
> Kenichi
> > Envoyé : lundi 12 juillet 2021 09:03 À : [e-mail] Objet : Re:
> > [Teas] New Version Notification for draft-wd-teas-ietf-
> > network-slice-nbi-yang-03.txt
> >
> > Hi Authors and All,
> >
> > We have some questions how to proceed this work.
> >
> > 1. How should we create a new solution where the solution is
> similar
> > to an existing solution?
> >  As Dhruv, co-author of both drafts, should know well, the many
> > functionalities of this nbi are same as those of actn-vn-yang. As
> > described in B.1, we agree that actn-vn-yang is only focusing on
> ACTN
> > and this nbi is technology agnostic.
> > However, draft-ietf-teas-ietf-network-slices definitely addresses
> the
> > applicability of ACTN. So, this nbi should at least import actn-
> > vn-yang and refer the nodes defined in actn-vn-yang?
> > I'm not sure how to create a new solution for such a case.
> >
> 
> 
> ____________________________________________________________________
> _____________________________________________________
> 
> 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.


_________________________________________________________________________________________________________________________

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.