Hello,


We updated a draft-shytyi-opsawg-vysm-06.txt. It includes the modification 
according to the comments received from participants of opsawg and netmod.
Many thanks to Tom Petch, Martin Bjorklund, Schönwälder Jürgen.
Currently the I-D draft includes the uCPE definition and YANG model to manage 
this equipment. 





A new version of I-D, draft-shytyi-opsawg-vysm-06.txt 

has been successfully submitted by Dmytro Shytyi and posted to the 

IETF repository. 



Name:        draft-shytyi-opsawg-vysm 

Revision:    06 

Title:        A YANG Module for uCPE management. 

Document date:    2019-10-29 

Group:        Individual Submission 

Pages:        17 

URL: https://www.ietf.org/internet-drafts/draft-shytyi-opsawg-vysm-06.txt 

Status: https://datatracker.ietf.org/doc/draft-shytyi-opsawg-vysm/ 

Htmlized: https://tools.ietf.org/html/draft-shytyi-opsawg-vysm-06 

Htmlized: https://datatracker.ietf.org/doc/html/draft-shytyi-opsawg-vysm 

Diff: https://www.ietf.org/rfcdiff?url2=draft-shytyi-opsawg-vysm-06 



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





---- On Fri, 25 Oct 2019 14:04:38 +0200 tom petch <mailto:ie...@btconnect.com> 
wrote ----



----- Original Message ----- 
From: "Dmytro Shytyi" <mailto:ietf.dmy...@shytyi.net> 
To: "tom petch" <mailto:ie...@btconnect.com> 
Cc: "opsawg" <mailto:opsawg@ietf.org> 
Sent: Tuesday, October 22, 2019 6:57 PM 
 
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). 
 
<tp> 
 
It is possible to take code (text etc) from any IETF RFC or I-D and use 
it in any other I-D as part of the IETF standards process; when you 
submit an I-D, that is what you agree to.  (I would expect to see a 
mention of this in an Acknowledgements section) 
 
But here there seems no reason to do this.  You have 
 augment "/ietf-nfv:ucpe/ietf-if:interfaces/ietf-if:interface" { 
which instead should be 
 augment "/ietf-if:interfaces/ietf-if:interface" { 
Any box with YANG and interfaces can be expected to implement RFC8343 so 
the definitions are all there ready and waiting to be used, as-is or 
with an augmentation. 
 
What you are doing is creating lots of duplicate definitions of objects 
that many will already be using; yes, YANG caters for this by allowing 
the same name with different prefixes but when it is unnecesary, as 
seems the case here, confusion and/or chaos will follow. 
 
I realise that I have sparked a parallel discussion on the netmod WG 
list but did not want this point to be left unanswered on the OPSAWG 
list. 
 
Tom Petch 
 
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:ie...@btconnect.com> 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:ietf.dmy...@shytyi.net> 
>To: "tom petch" <mailto:ie...@btconnect.com> 
>Cc: "opsawg" <mailto:opsawg@ietf.org> 
>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:ie...@btconnect.com> 
>wrote ---- 
> 
> 
> 
>----- Original Message ----- 
>From: "Dmytro Shytyi" <mailto:mailto:ietf.dmy...@shytyi.net> 
>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:ietf.dmy...@shytyi.net> 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:jcla...@cisco.com> wrote ---- 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>_______________________________________________ 
> 
>OPSAWG mailing list 
> 
>mailto:mailto:mailto:OPSAWG@ietf.org 
> 
>https://www.ietf.org/mailman/listinfo/opsawg 
> 
> 
> 
> 
> 
>On Sep 30, 2019, at 17:17, Dmytro Shytyi 
><mailto:mailto:mailto:ietf.dmy...@shytyi.net> 
>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:internet-dra...@ietf.org> 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:OPSAWG@ietf.org 
> 
>https://www.ietf.org/mailman/listinfo/opsawg 
> 
> 
>----------------------------------------------------------------------- 
- 
>-------- 
> 
> 
>> _______________________________________________ 
>> OPSAWG mailing list 
>> mailto:mailto:OPSAWG@ietf.org 
>> https://www.ietf.org/mailman/listinfo/opsawg 
>>
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Reply via email to