Subject: Re: [OPSAWG] New Version Notification for draft-shytyi-opsawg-vysm-01.txt

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Mon, 7 Oct 2019 13:50:40 +0000

On Sep 30, 2019, at 17:17, Dmytro Shytyi <[email-masked]<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 <[email-masked]<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<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 tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

_______________________________________________
OPSAWG mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/opsawg

---

From: Dmytro Shytyi <[email-masked]>
Date: Tue, 08 Oct 2019 18:33:13 +0200

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

IETF repository.

Revision:    02

Document date:    2019-10-08

Pages:        40

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

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

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

Abstract:

Service Orchestrator.

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) <[email-masked]> wrote ----

On Sep 30, 2019, at 17:17, Dmytro Shytyi <mailto:[email-masked]> wrote:

Dear members of opsawg,

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.

Joe

______________

Best Regards,

Dmytro SHYTYI

---- On Thu, 26 Sep 2019 18:01:14 +0200  <mailto:[email-masked]> wrote ----

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

 
 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:[email-masked]

---

From: Dmytro Shytyi <[email-masked]>
Date: Fri, 18 Oct 2019 16:30:17 +0200

Hello all,

We updated the draft to version draft-shytyi-opsawg-vysm-03.txt with the new information.

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

IETF repository.

Revision:    03

Document date:    2019-10-18

Pages:        41

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

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

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

Abstract:

Service Orchestrator.

______________
Dmytro SHYTYI,
SFR.

---- On Tue, 08 Oct 2019 18:33:13 +0200 Dmytro Shytyi <mailto:[email-masked]> wrote ----

Hello Joe,

In the new version:

vsym-service.yang

IETF repository.

Revision:    02

Pages:        40

Abstract:

Service Orchestrator.

The IETF Secretariat

---- On Mon, 07 Oct 2019 15:50:40 +0200 Joe Clarke (jclarke) <mailto:[email-masked]> wrote ----

OPSAWG mailing list 

mailto:[email-masked] 

Dear members of opsawg,

Joe

______________

Best Regards,

Dmytro SHYTYI

---- On Thu, 26 Sep 2019 18:01:14 +0200  <mailto:[email-masked]> wrote ----

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

 
 
 The IETF Secretariat 

OPSAWG mailing list

mailto:[email-masked]

---

From: tom petch <[email-masked]>
Date: Sat, 19 Oct 2019 11:51:19 +0000

----- Original Message -----
From: "Dmytro Shytyi" <[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.

IETF repository.

Revision: 03

Pages: 41

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

Abstract:

Service Orchestrator.

______________
Dmytro SHYTYI,
SFR.

---- On Tue, 08 Oct 2019 18:33:13 +0200 Dmytro Shytyi
<mailto:[email-masked]> wrote ----

Hello Joe,

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)

vsym-service.yang

ietf-vsym-interfaces.yang (augments vsum-service.yang and has ref to
"vLinks" from vsym-service).

IETF repository.

Revision: 02

Pages: 40

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

Abstract:

Service Orchestrator.

Please note that it may take a couple of minutes from the time of
submission

The IETF Secretariat

---- On Mon, 07 Oct 2019 15:50:40 +0200 Joe Clarke (jclarke)
<mailto:[email-masked]> wrote ----

OPSAWG mailing list

mailto:[email-masked]

On Sep 30, 2019, at 17:17, Dmytro Shytyi <mailto:[email-masked]>
wrote:

Dear members of opsawg,

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.

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:[email-masked]> wrote ----

 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:

 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:[email-masked]

------------------------------------------------------------------------
--------

> [email-masked]

---

From: Dmytro Shytyi <[email-masked]>
Date: Sat, 19 Oct 2019 14:22:44 +0200

Hello Tom,

>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 <[email-masked]> wrote ----

----- Original Message ----- 
From: "Dmytro Shytyi" <mailto:[email-masked]> 
Sent: Friday, October 18, 2019 3:30 PM 
 
Hello all, 

<tp> 

 
You have 
 
 <CODE ENDS> 

 <CODE ENDS> 
 
 module ietf-interfaces { 

Tom Petch 

 

 

 

 
 
IETF repository. 

 
Revision: 03 

 
 
Pages: 41 
 
URL: 

 

 
Abstract: 

 

Service Orchestrator. 

______________ 
Dmytro SHYTYI, 
SFR. 

 
---- On Tue, 08 Oct 2019 18:33:13 +0200 Dmytro Shytyi 
<mailto:mailto:[email-masked]> wrote ---- 

Hello Joe, 

 
In the new version: 

 
 
vsym-service.yang 

 

 
 
IETF repository. 

 
Revision: 02 

 
 
Pages: 40 
 
URL: 

 

 
Abstract: 

 

Service Orchestrator. 

 

 

The IETF Secretariat 

---- On Mon, 07 Oct 2019 15:50:40 +0200 Joe Clarke (jclarke) 
<mailto:mailto:[email-masked]> wrote ---- 

 

 
 
OPSAWG mailing list 
 
mailto:mailto:[email-masked] 

 

On Sep 30, 2019, at 17:17, Dmytro Shytyi <mailto:mailto:[email-masked]> 
wrote: 

Dear members of opsawg, 

 

 

 

 

 
Joe 

 

 

______________ 
 
Best Regards, 
 
Dmytro SHYTYI 

 
---- On Thu, 26 Sep 2019 18:01:14 +0200 
<mailto:mailto:[email-masked]> wrote ---- 

 

 Abstract: 

 
 
 The IETF Secretariat 

 

 
 
OPSAWG mailing list 
 
mailto:mailto:[email-masked]

---

From: Dmytro Shytyi <[email-masked]>
Date: Sat, 19 Oct 2019 18:03:21 +0200

Hi Tom,

We updated the draft according to your comments(https://www.ietf.org/internet-drafts/draft-shytyi-opsawg-vysm-04.txt).

We separated the yang modules by sections. And also we added a description of augmentation between modules.

Also we checked that modules stripped from I-D could be successfully compiled.

The report of validators and analysers shows no errors and warnings.

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

IETF repository.

Revision:    04

Document date:    2019-10-19

Pages:        42

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

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

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

Abstract:

Service Orchestrator.

______________
Dmytro SHYTYI

---- On Sat, 19 Oct 2019 14:22:44 +0200 Dmytro Shytyi <[email-masked]> wrote ----

Hello Tom,

....

      list ucpe {

      ...

      }

}

...

            container interfaces {

                  description
         "Interface parameters.";

                  list interface {

                        ...

                  }

      }

}

      import ietf-interfaces {
         prefix ietf-if;
       }

      ....

      }

}

____________
Dmytro SHYTYI

---- On Sat, 19 Oct 2019 13:51:19 +0200 tom petch <mailto:[email-masked]> wrote ----

----- Original Message ----- 
From: "Dmytro Shytyi" <mailto:[email-masked]> 
Sent: Friday, October 18, 2019 3:30 PM 
 
Hello all, 

<tp> 

 
You have 
 
 <CODE ENDS> 

 <CODE ENDS> 
 
 module ietf-interfaces { 

Tom Petch 

 

 

 

 
 
IETF repository. 

 
Revision: 03 

 
 
Pages: 41 
 
URL: 

 

 
Abstract: 

 

Service Orchestrator. 

______________ 
Dmytro SHYTYI, 
SFR. 

 

Hello Joe, 

 
In the new version: 

 
 
vsym-service.yang 

 

 
 
IETF repository. 

 
Revision: 02 

 
 
Pages: 40 
 
URL: 

 

 
Abstract: 

 

Service Orchestrator. 

 

 

The IETF Secretariat 

 

 

 
OPSAWG mailing list 

 

 
Dear members of opsawg, 

 

 

 

 

 
Joe 

 

 

______________ 
 
Best Regards, 
 
Dmytro SHYTYI 

 

 

 Abstract: 

 
 
 The IETF Secretariat 

 

 
 
OPSAWG mailing list

---

From: tom petch <[email-masked]>
Date: Sat, 19 Oct 2019 19:29:41 +0000

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" <[email-masked]>
To: "tom petch" <[email-masked]>
Cc: "opsawg" <[email-masked]>
Sent: Saturday, October 19, 2019 1:22 PM

Hello Tom,

>which looks inappropriate for an ietf module.

WIll be fixed. Notice: the yang validator did not throw any errors
regarding importing this module.

The idea is to use standard module "ietf-interfaces" and add an
extension leaf: connect interface to virtuali link.

....

list ucpe {

...

}

}

...

container interfaces {

description
         "Interface parameters.";

list interface {

...

}

}

}

import ietf-interfaces {
         prefix ietf-if;
       }

....

}

}

____________
Dmytro SHYTYI

---- On Sat, 19 Oct 2019 13:51:19 +0200 tom petch <[email-masked]>
wrote ----

----- Original Message -----
From: "Dmytro Shytyi" <mailto:[email-masked]>
Sent: Friday, October 18, 2019 3:30 PM

Hello all,

<tp>

You have

 <CODE ENDS>

 <CODE ENDS>

 module ietf-interfaces {

Tom Petch

IETF repository.

Revision: 03

Pages: 41

URL:

Abstract:

Service Orchestrator.

______________
Dmytro SHYTYI,
SFR.

Hello Joe,

In the new version:

vsym-service.yang

IETF repository.

Revision: 02

Pages: 40

URL:

Abstract:

Service Orchestrator.

The IETF Secretariat

OPSAWG mailing list

On Sep 30, 2019, at 17:17, Dmytro Shytyi
<mailto:mailto:[email-masked]>
wrote:

Dear members of opsawg,

Joe

______________

Best Regards,

Dmytro SHYTYI

 Abstract:

 The IETF Secretariat

OPSAWG mailing list

---

From: Dmytro Shytyi <[email-masked]>
Date: Tue, 22 Oct 2019 19:57:18 +0200

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 ​

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Tue, 22 Oct 2019 18:08:59 +0000

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

-- 
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/>

---

From: Dmytro Shytyi <[email-masked]>
Date: Tue, 22 Oct 2019 22:06:16 +0200

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.

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

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

/js 
 
On Tue, Oct 22, 2019 at 07:57:18PM +0200, Dmytro Shytyi wrote: 
> On Oct 19, 2019, 21:29, at 21:29, tom petch <mailto:[email-masked]> wrote: 
> >Um no! 
> > 
> >   module ietf-interfaces 
> > 
> >To: "tom petch" <mailto:[email-masked]> 
> >Cc: "opsawg" <mailto:[email-masked]> 
> >From: "Dmytro Shytyi" <mailto:mailto:[email-masked]> 
> ><mailto:mailto:mailto:[email-masked]> wrote ---- 
> > 
> > 
> > 
> >Hello Joe, 
> > 
> ><mailto:mailto:mailto:[email-masked]> wrote ---- 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >mailto:mailto:mailto:[email-masked] 
> > 
> ><mailto:mailto:mailto:[email-masked]> 
> >wrote: 
> > 
> > 
> > 
> >Dear members of opsawg, 
> > 
> > 
> > 
> ><mailto:mailto:mailto:[email-masked]> wrote ---- 
> > 
> > 
> > 
> > 
> >mailto:mailto:mailto:[email-masked] 
> >

---

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:
> 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:

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

---

From: tom petch <[email-masked]>
Date: Fri, 25 Oct 2019 12:04:38 +0000

----- Original Message -----
From: "Dmytro Shytyi" <[email-masked]>
To: "tom petch" <[email-masked]>
Cc: "opsawg" <[email-masked]>
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

---

From: Dmytro Shytyi <[email-masked]>
Date: Tue, 29 Oct 2019 22:06:52 +0100

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 

IETF repository. 

Revision:    06 

Document date:    2019-10-29 

Pages:        17 

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

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

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

Abstract: 

Service Orchestrator. 

______________
Dmytro SHYTYI

---- On Fri, 25 Oct 2019 14:04:38 +0200 tom petch <mailto:[email-masked]> wrote ----

----- Original Message ----- 
From: "Dmytro Shytyi" <mailto:[email-masked]> 
To: "tom petch" <mailto:[email-masked]> 
Cc: "opsawg" <mailto:[email-masked]> 
Sent: Tuesday, October 22, 2019 6:57 PM 
 
Hello Tom, 

<tp> 

 

Tom Petch 

 
Best regards, 
Dmytro.