Re: [netmod] New Version Notification for draft-shytyi-opsawg-vysm-02.txt [AKA: A reworking of RFC8334]
Martin Bjorklund <mbj@tail-f.com> Tue, 22 October 2019 20:20 UTC
Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9031F1200EF; Tue, 22 Oct 2019 13:20:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-iaZ1MHjrUV; Tue, 22 Oct 2019 13:20:10 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C5B38120041; Tue, 22 Oct 2019 13:20:09 -0700 (PDT)
Received: from localhost (h-4-44.A165.priv.bahnhof.se [158.174.4.44]) by mail.tail-f.com (Postfix) with ESMTPSA id 3DA781AE03DD; Tue, 22 Oct 2019 22:20:08 +0200 (CEST)
Date: Tue, 22 Oct 2019 22:20:08 +0200
Message-Id: <20191022.222008.1996173917468761051.mbj@tail-f.com>
To: ietf.dmytro@shytyi.net
Cc: J.Schoenwaelder@jacobs-university.de, opsawg@ietf.org, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <16df513c531.10662af9796265.3387327717024632289@shytyi.net>
References: <f9e64e58-2a69-453e-a0b4-5bcbb3f134cd@shytyi.net> <20191022180858.ytek5zv2utmfsato@anna.jacobs.jacobs-university.de> <16df513c531.10662af9796265.3387327717024632289@shytyi.net>
X-Mailer: Mew version 6.8 on Emacs 25.2
Mime-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/ZVyAfF7i_t4s3NFQxHYUI9YhT-U>
Subject: Re: [netmod] New Version Notification for draft-shytyi-opsawg-vysm-02.txt [AKA: A reworking of RFC8334]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Oct 2019 20:20:14 -0000
[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 <ietf.dmytro@shytyi.net> 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:J.Schoenwaelder@jacobs-university.de> <mailto:J.Schoenwaelder@jacobs-university.de> 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:ietfc@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.dmytro@shytyi.net>
> > >To: "tom petch" <mailto:ietfc@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:ietfc@btconnect.com>
> > >wrote ----
> > >
> > >
> > >
> > >----- Original Message -----
> > >From: "Dmytro Shytyi" <mailto:mailto:ietf.dmytro@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.dmytro@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:jclarke@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.dmytro@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-drafts@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
> > mailto:OPSAWG@ietf.org
> > 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/>
- Re: [netmod] New Version Notification for draft-s… Martin Bjorklund