Subject: Re: [netmod] New Version Notification for draft-shytyi-opsawg-vysm-02.txt [AKA: A reworking of RFC8334]

From: Martin Bjorklund <[email-masked]>
Date: Tue, 22 Oct 2019 22:20:08 +0200 (CEST)

[since you sent the same email to two WGs, I have added both to Cc in
this reply.  i don't think we should have parallell discussions in
different MLs]

Dmytro Shytyi <[email-masked]> wrote:
> Hello Jurgen,
> 
> 
> 
> Thank you for your comment,
> 
> 
> 
> Yeap I think it is a great idea to explain why do we need the adjustments  of RFC 8343 in the case of draft-shytyi-opsawg-vysm-04.
> 
> 
> 
> What do you think about this:
> 
> 1. uCPE phy interface has "vPorts" to witch "vLinks are
> assigned". "vLinks "connect" the phy interface with  "vPort" of
> vswitch. Thus we may add to the derieved from RFC 8343 module the
> list of "vPorts" for each phy interface.

You should use "augment" if you want to add additional nodes to an
existing module.

> example with 1 phy interface:
> 
> 
> 
>                               +-------------------------------------
> 
>                               |                  UCPE
> 
>                   +------------+
> 
>                   |                        |------vPort 1---vlink---(vport_sw)vswitch(vport_sw)--vlink---.....----WAN
> 
> LAN----|   Phy             |------vPort 2
> 
>                   |   interface     |
> 
>                   +-------------+
> 
>                               |
> 
>                               +----------------------------------------------
> 
> 2. If we include the yang module from the RFC 8343 to the set of yang models by default it goes in the root of config mode. i.e:
> 
> EXAMPLE:
> 
> config t
> 
>       interfaces interface....
> 
> 
> 
> When we have a parent module we need to place the RFC 8343 module to under the parent module (like in the draft draft-shytyi-opsawg-vysm-04). 

Have you looked at the models in RFC 8529 and RFC 8530?  Perhaps you
can use them, rather than creating another special module for this
particular use case?

/martin

> 
> Hence the RFC8343  may be modified to add the augment statement(as it is dome in draft-shytyi-opsawg-vysm-04)  to put the "interfaces interface" under the parent module like
> 
> EXAMPLE:
> 
> conifg t
> 
>       ucpe "ucpe X" interfaces interface...
> 
> 
> 
> Best,
> Dmytro
> ---- On Tue, 22 Oct 2019 20:08:59 +0200 Schönwälder, Jürgen
> 	<mailto:[email-masked]> <mailto:[email-masked]> wrote ----
> 
> 
> I think you need to explain each and every change you make to the 
> ietf-interfaces definitions. Ideally, semantic changes would be 
> limited (or not even needed at all). But nobody can tell unless 
> you clearly document the changes (and why they are needed). 
>  
> /js 
>  
> On Tue, Oct 22, 2019 at 07:57:18PM +0200, Dmytro Shytyi wrote: 
> > Hello Tom, 
> > 
> > I can imagine your birraze. And I would like to add the next thing: the model from RFC 8343 has some code that we are interested in ( not all, but part) IMHO it is impossible/wrong for me to take the code from another ietf rfc and not to give a reference at least somewhere in the yang model , for example module description ( i also will update the references in the bottom if id document). 
> > 
> > Therefore I assume it is a nice to separate things in modules to show what yang models are new and what parts are taken from another RFC and modified. 
> > 
> > 
> > This module " ietf interfaces" is derived from RFC 8343 but the draft module has at least another module name and namespace. Thus I may modify the description to add that we use  base module defined in RFC 8343 and further modify it according to our needs? 
> > 
> > 
> > Can the yang module description ( ucpe-interfaces) change the feeling about the set of yang models? 
> > 
> > Best regards, 
> > Dmytro. 
> > ⁣Get BlueMail for Android ​ 
> > 
> > On Oct 19, 2019, 21:29, at 21:29, tom petch <mailto:[email-masked]> wrote: 
> > >Um no! 
> > > 
> > >   module ietf-interfaces 
> > > 
> > >exists; it is defined in RFC8343.  You cannot create another one! 
> > > 
> > >and when I look at pp15-16 of your I-D, it looks like a copy of the 
> > >text 
> > >of RFC8343, text which is right for RFC8343 but is wrong for something 
> > >which you are creating, regardless of what it is that you are 
> > >augmenting 
> > >be that ietf-interfaces or anything else.. 
> > > 
> > >Hence my 'bizarre'. 
> > > 
> > >Tom Petch 
> > > 
> > > 
> > >----- Original Message ----- 
> > >From: "Dmytro Shytyi" <mailto:[email-masked]> 
> > >To: "tom petch" <mailto:[email-masked]> 
> > >Cc: "opsawg" <mailto:[email-masked]> 
> > >Sent: Saturday, October 19, 2019 1:22 PM 
> > > 
> > > 
> > >Hello Tom, 
> > > 
> > > 
> > > 
> > >>import tailf-ncs { 
> > > 
> > >>which looks inappropriate for an ietf module. 
> > > 
> > > 
> > >WIll be fixed. Notice: the yang validator did not throw any errors 
> > >regarding importing this module. 
> > > 
> > > 
> > > 
> > >Indeed there is <CODE BEGINS> missing for 2 yang modules. 
> > > 
> > >Actually there are 3 yang modules. where: 
> > > 
> > >1.yang module "ietf-vysm-interfaces" autgments "ietf-interfaces" 
> > > 
> > >2. yang module "ietf-interfaces" augments "ietf-vysm-service". 
> > > 
> > >The idea is to use standard module "ietf-interfaces" and add an 
> > >extension leaf: connect interface to virtuali link. 
> > > 
> > > 
> > > 
> > >1. module ietf-vysm-service{ 
> > > 
> > >.... 
> > > 
> > >list ucpe { 
> > > 
> > >... 
> > > 
> > >} 
> > > 
> > >} 
> > > 
> > > 
> > > 
> > >2. module ietf-interfaces { 
> > > 
> > >import ietf-vysm-service { 
> > >     prefix ietf-vysm; 
> > >   } 
> > > 
> > > 
> > >... 
> > > 
> > >augment "/ietf-vysm:ucpe"{ 
> > > 
> > >container interfaces { 
> > > 
> > >description 
> > >         "Interface parameters."; 
> > > 
> > >list interface { 
> > > 
> > >... 
> > > 
> > >} 
> > > 
> > >} 
> > > 
> > >} 
> > > 
> > > 
> > > 
> > >3.module ietf-vysm-interfaces { 
> > > 
> > >import ietf-vysm-service { 
> > >         prefix ietf-nfv; 
> > >       } 
> > > 
> > >import ietf-interfaces { 
> > >         prefix ietf-if; 
> > >       } 
> > > 
> > >.... 
> > > 
> > >augment "/ietf-nfv:ucpe/ietf-if:interfaces/ietf-if:interface" { 
> > > 
> > > 
> > > 
> > >} 
> > > 
> > >} 
> > > 
> > >I think it is a nice idea to add this shot desctiption to the draft. 
> > > 
> > >____________ 
> > >Dmytro SHYTYI 
> > > 
> > > 
> > > 
> > > 
> > > 
> > >---- On Sat, 19 Oct 2019 13:51:19 +0200 tom petch <mailto:[email-masked]> 
> > >wrote ---- 
> > > 
> > > 
> > > 
> > >----- Original Message ----- 
> > >From: "Dmytro Shytyi" <mailto:mailto:[email-masked]> 
> > >Sent: Friday, October 18, 2019 3:30 PM 
> > > 
> > >Hello all, 
> > > 
> > >We updated the draft to version draft-shytyi-opsawg-vysm-03.txt with 
> > >the 
> > >new information. 
> > > 
> > ><tp> 
> > > 
> > >and you do not yet have IANA Considerations or Security Considerations 
> > >as per RFC8407.  And you import 
> > > import tailf-ncs { 
> > >which looks inappropriate for an ietf module. 
> > > 
> > >But as a whole, this looks so bizarre that I went back to the web site 
> > >and downloaded it all over again to try and see what had happened; the 
> > >result remains bizarre. 
> > > 
> > >You have 
> > > 
> > > <CODE ENDS> 
> > > module ietf-vysm-interfaces { 
> > > 
> > >which is wrong - no CODE BEGINS - and then 
> > > 
> > > <CODE ENDS> 
> > > 
> > > module ietf-interfaces { 
> > > 
> > >which is ........ words fail me.  What are you trying to do? 
> > > 
> > >Tom Petch 
> > > 
> > >ps draft-shytyi-netmod-vysm looked like a good start before the switch 
> > >to opsawg. 
> > > 
> > > 
> > >We added a section that describes what could be done with uCPE, 
> > >precisely the advantages that uCPE introduces. 
> > > 
> > >Tehre are sevaral nice figures that describe how we could take an 
> > >advantage of uCPE. 
> > > 
> > > 
> > > 
> > >If needed, we also can introduce the layered architecture of the YANG 
> > >models that are in stacked orchestrators. 
> > > 
> > > 
> > > 
> > >Dear chairs of the wg, I will attend the next IETF meeting and I would 
> > >like to have a 'brief' slot to present the draft. 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > >A new version of I-D, draft-shytyi-opsawg-vysm-03.txt 
> > > 
> > >has been successfully submitted by Dmytro Shytyi and posted to the 
> > > 
> > >IETF repository. 
> > > 
> > > 
> > > 
> > >Name: draft-shytyi-opsawg-vysm 
> > > 
> > >Revision: 03 
> > > 
> > >Title: A YANG Module for uCPE management. 
> > > 
> > >Document date: 2019-10-18 
> > > 
> > >Group: Individual Submission 
> > > 
> > >Pages: 41 
> > > 
> > >URL: 
> > >https://www.ietf.org/internet-drafts/draft-shytyi-opsawg-vysm-03.txt 
> > > 
> > >Status: https://datatracker.ietf.org/doc/draft-shytyi-opsawg-vysm/ 
> > > 
> > >Htmlized: https://tools.ietf.org/html/draft-shytyi-opsawg-vysm-03 
> > > 
> > >Htmlized: 
> > >https://datatracker.ietf.org/doc/html/draft-shytyi-opsawg-vysm 
> > > 
> > >Diff: https://www.ietf.org/rfcdiff?url2=draft-shytyi-opsawg-vysm-03 
> > > 
> > > 
> > > 
> > >Abstract: 
> > > 
> > >This document provides a YANG data model for uCPE management (VYSM) 
> > > 
> > >and definition of the uCPE equipment. The YANG Service Model serves 
> > > 
> > >as a base framework for managing an universal Customer-Premises 
> > > 
> > >Equipment (uCPE) subsystem. The model can be used by a Network 
> > > 
> > >Service Orchestrator. 
> > > 
> > > 
> > > 
> > >______________ 
> > >Dmytro SHYTYI, 
> > >SFR. 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > >---- On Tue, 08 Oct 2019 18:33:13 +0200 Dmytro Shytyi 
> > ><mailto:mailto:mailto:[email-masked]> wrote ---- 
> > > 
> > > 
> > > 
> > >Hello Joe, 
> > > 
> > >Thank you for your comment. 
> > > 
> > > 
> > > 
> > >In the new version: 
> > > 
> > >We updated the existing yang model according to your suggestions(now 
> > >the 
> > >nits and validation logs seem to be clear). 
> > > 
> > >We expanded the uCPE management yang model with interface model from 
> > >RFC 
> > >8343( A YANG Data Model for Interface Management) 
> > > 
> > >Now there are 3 yang files that you may strip from I-D: 
> > > 
> > >vsym-service.yang 
> > > 
> > >modified ietf-interfaces.yang (augments vsym-service.yang) 
> > > 
> > >ietf-vsym-interfaces.yang (augments vsum-service.yang and has ref to 
> > >"vLinks" from vsym-service). 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > >A new version of I-D, draft-shytyi-opsawg-vysm-02.txt 
> > > 
> > >has been successfully submitted by Dmytro Shytyi and posted to the 
> > > 
> > >IETF repository. 
> > > 
> > > 
> > > 
> > >Name: draft-shytyi-opsawg-vysm 
> > > 
> > >Revision: 02 
> > > 
> > >Title: A YANG Module for uCPE management. 
> > > 
> > >Document date: 2019-10-08 
> > > 
> > >Group: Individual Submission 
> > > 
> > >Pages: 40 
> > > 
> > >URL: 
> > >https://www.ietf.org/internet-drafts/draft-shytyi-opsawg-vysm-02.txt 
> > > 
> > >Status: https://datatracker.ietf.org/doc/draft-shytyi-opsawg-vysm/ 
> > > 
> > >Htmlized: https://tools.ietf.org/html/draft-shytyi-opsawg-vysm-02 
> > > 
> > >Htmlized: 
> > >https://datatracker.ietf.org/doc/html/draft-shytyi-opsawg-vysm 
> > > 
> > >Diff: https://www.ietf.org/rfcdiff?url2=draft-shytyi-opsawg-vysm-02 
> > > 
> > > 
> > > 
> > >Abstract: 
> > > 
> > >This document provides a YANG data model for uCPE management (VYSM) 
> > > 
> > >and definition of the uCPE equipment. The YANG Service Model serves 
> > > 
> > >as a base framework for managing an universal Customer-Premises 
> > > 
> > >Equipment (uCPE) subsystem. The model can be used by a Network 
> > > 
> > >Service Orchestrator. 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > >Please note that it may take a couple of minutes from the time of 
> > >submission 
> > > 
> > >until the htmlized version and diff are available at tools.ietf.org. 
> > > 
> > > 
> > > 
> > >The IETF Secretariat 
> > > 
> > > 
> > > 
> > >---- On Mon, 07 Oct 2019 15:50:40 +0200 Joe Clarke (jclarke) 
> > ><mailto:mailto:mailto:[email-masked]> wrote ---- 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > >_______________________________________________ 
> > > 
> > >OPSAWG mailing list 
> > > 
> > >mailto:mailto:mailto:[email-masked] 
> > > 
> > >https://www.ietf.org/mailman/listinfo/opsawg 
> > > 
> > > 
> > > 
> > > 
> > > 
> > >On Sep 30, 2019, at 17:17, Dmytro Shytyi 
> > ><mailto:mailto:mailto:[email-masked]> 
> > >wrote: 
> > > 
> > > 
> > > 
> > >Dear members of opsawg, 
> > > 
> > > 
> > > 
> > >Recently we uploaded a draft about uCPE management. 
> > > 
> > > 
> > >You are invited to answer few questions regarding the draft 
> > >https://www.ietf.org/internet-drafts/draft-shytyi-opsawg-vysm-01.txt. 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > >One thing that would help with reviews is if you cleaned up this YANG 
> > >module. Consider using pyang -f yang --keep-comments to generate 
> > >something well-formatted, and —canonical to check ordering. In 
> > >particular, your 
> > > revisions are out of order. 
> > > 
> > > 
> > > 
> > > 
> > > 
> > >Question1: Do you find a difinition of uCPE is well explained? If no 
> > >what could be improved? 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > >I think it is, but as a vendor that makes such a device, I may not be 
> > >the right person to ask. What I mean is that I inherently understand 
> > >the 
> > >concept. 
> > > 
> > > 
> > > 
> > >It would be good if others perhaps that use such devices could weigh 
> > >in. 
> > > 
> > > 
> > > 
> > >Joe 
> > > 
> > > 
> > > 
> > >You may answer: I agree with definition. OR I think it could be 
> > >modified... 
> > > 
> > >Question2: Do you think there is enough examples of internal uCPE 
> > >service and usecases that are well depicted. 
> > > 
> > > 
> > > 
> > > 
> > > 
> > >You may answer: The examples and usecases are well explained. OR The 
> > >usecases need improvements. 
> > > 
> > >Question3: Do you find that yang model should stay unchanged regarding 
> > >the phy interfaces. Maybe one may think about "ietf interface" instead 
> > >of "phyInterface". 
> > > 
> > >You may answer: The yang model looks good for me.  OR The yang model 
> > >needs more improvements(which improvements). 
> > > 
> > > 
> > >______________ 
> > > 
> > >Best Regards, 
> > > 
> > >Dmytro SHYTYI 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > >---- On Thu, 26 Sep 2019 18:01:14 +0200 
> > ><mailto:mailto:mailto:[email-masked]> wrote ---- 
> > > 
> > > 
> > > 
> > > 
> > >A new version of I-D, draft-shytyi-opsawg-vysm-01.txt 
> > > has been successfully submitted by Dmytro Shytyi and posted to the 
> > > IETF repository. 
> > > 
> > > Name: draft-shytyi-opsawg-vysm 
> > > Revision: 01 
> > > Title: A YANG Module for uCPE management. 
> > > Document date: 2019-09-26 
> > > Group: Individual Submission 
> > > Pages: 15 
> > > URL: 
> > >https://www.ietf.org/internet-drafts/draft-shytyi-opsawg-vysm-01.txt 
> > > Status: https://datatracker.ietf.org/doc/draft-shytyi-opsawg-vysm/ 
> > > Htmlized: https://tools.ietf..org/html/draft-shytyi-opsawg-vysm-01 
> > > Htmlized: 
> > >https://datatracker.ietf.org/doc/html/draft-shytyi-opsawg-vysm 
> > > Diff: https://www.ietf.org/rfcdiff?url2=draft-shytyi-opsawg-vysm-01 
> > > 
> > > Abstract: 
> > > This document provides a YANG data model for uCPE management (VYSM) 
> > > and definition of the uCPE equipment. The YANG Service Model serves 
> > > as a base framework for managing an universal Customer-Premises 
> > > Equipment (uCPE) subsystem. The model can be used by a Network 
> > > Service Orchestrator. 
> > > 
> > > 
> > > 
> > > 
> > > Please note that it may take a couple of minutes from the time of 
> > >submission 
> > > until the htmlized version and diff are available at 
> > >http://tools.ietf.org.. 
> > > 
> > > The IETF Secretariat 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > >_______________________________________________ 
> > > 
> > >OPSAWG mailing list 
> > > 
> > >mailto:mailto:mailto:[email-masked] 
> > > 
> > >https://www.ietf.org/mailman/listinfo/opsawg 
> > > 
> > > 
> > >------------------------------------------------------------------------ 
> > >-------- 
> > > 
> > > 
> > >> _______________________________________________ 
> > >> OPSAWG mailing list 
> > >> mailto:mailto:[email-masked] 
> > >> https://www.ietf.org/mailman/listinfo/opsawg 
> > >> 
>  
> > _______________________________________________ 
> > OPSAWG mailing list 
> > mailto:[email-masked] 
> > https://www.ietf.org/mailman/listinfo/opsawg 
>  
>  
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH 
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany 
> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>