Return-Path: 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 67DD01200FD; Tue, 22 Oct 2019 14:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=shytyi.net 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 xcB2eN7Ydy4P; Tue, 22 Oct 2019 14:42:55 -0700 (PDT) Received: from sender11-of-o52.zoho.eu (sender11-of-o52.zoho.eu [185.20.211.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17C4F1200FB; Tue, 22 Oct 2019 14:42:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571780564; cv=none; d=zohomail.eu; s=zohoarc; b=a6JaiEfemg/3/NGoXkeYVQYy82brBT3p3z6Qr92e2U/er27uhouctxsHHoi1tFe98EO6V2ScEQKRS7mAjeDJMuQ2gRORn+Rwnkx8k49hwpt5i4opkfrUG1Kj+9wlwP3qJ/SX8FPQ03w72hK3wgFhFYeLgixF7SCphlGcYYjwiAA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.eu; s=zohoarc; t=1571780564; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=TyG/7D5qQrFVqbQMa0eaha7R9/P0Zf6TUAr7hQWaNMU=; b=KS7tE2P9DwLAQOhivSyhpBuAZ8ZmXDDWiRoh4YdiklYZKrB+DWCqTL4ykZqLwOCes4e3HFoREhB2i9kT7rDTm6iJlvhsEumvJ3HnPtef0e/A5lxiCoOPMRxQDIqcjdL+rSIvVXh8Hn1HStNelZ1O/h8UecbROVeUKUILLLJBU48= ARC-Authentication-Results: i=1; mx.zohomail.eu; dkim=pass header.i=shytyi.net; spf=pass smtp.mailfrom=ietf.dmytro@shytyi.net; dmarc=pass header.from= header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1571780564; s=hs; d=shytyi.net; i=ietf.dmytro@shytyi.net; h=Date:From:To:Cc:Message-Id:In-Reply-To:References:Subject:MIME-Version:Content-Type; l=42859; bh=TyG/7D5qQrFVqbQMa0eaha7R9/P0Zf6TUAr7hQWaNMU=; b=HibSrmT/c5GrPWiR9EJYQh6qh71tfOujfHDs7Ej27SQ7WPc9z8p56so+p0s2nKmC GhDQA2zzq3hsn5qj7spPTzmD8rEnROEv3f78R75h9HO7XhCa75ZYhlMFh4tfXz+M+0m uKdwr8yDGLQ6WSM9807Vdy+x3Obxj8SJLajxgnMU= Received: from mail.zoho.eu by mx.zoho.eu with SMTP id 1571780564112127.56383192439819; Tue, 22 Oct 2019 23:42:44 +0200 (CEST) Date: Tue, 22 Oct 2019 23:42:44 +0200 From: Dmytro Shytyi To: =?UTF-8?Q?=22Sch=C3=B6nw=C3=A4lder=2C_J=C3=BCrgen=22?= Cc: "Martin Bjorklund" , "netmod" , "opsawg" Message-Id: <16df56c1488.12bf5b05d97805.101466112881248875@shytyi.net> In-Reply-To: <20191022204302.5me6qb65f3zkrqad@anna.jacobs.jacobs-university.de> References: <8736fmtk3d.fsf@nic.cz> <20191021.134014.40553165389352172.mbj@tail-f.com> <039001d588c2$bb3d7e20$4001a8c0@gateway.2wire.net> <20191022.133131.983827662033885262.mbj@tail-f.com> <16df50844b1.bbb67c6096091.5644334168758722892@shytyi.net> <20191022200554.dt6x57eksvqbvngj@anna.jacobs.jacobs-university.de> <16df527b509.f1eff96d96574.7542135600963858099@shytyi.net> <20191022204302.5me6qb65f3zkrqad@anna.jacobs.jacobs-university.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_275998_583245835.1571780564105" X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: Subject: Re: [netmod] [OPSAWG] draft-shytyi-opsawg-vysm-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2019 21:42:58 -0000 ------=_Part_275998_583245835.1571780564105 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, >[since you sent the same email to two WGs, I have added both to Cc in=C2= =A0 >this reply. i don't think we should have parallell discussions in=C2=A0 >different MLs]=C2=A0 Dmytro Shytyi wrote:=C2=A0 > Hello Jurgen,=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 > Thank you for your comment,=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 > Yeap I think it is a great idea to explain why do we need the adjustments= =C2=A0 of RFC 8343 in the case of=C2=A0draft-shytyi-opsawg-vysm-04.=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 > What do you think about this:=C2=A0 >=C2=A0 > 1. uCPE phy interface has "vPorts" to witch "vLinks are=C2=A0 > assigned". "vLinks "connect" the phy interface with=C2=A0 "vPort" of=C2= =A0 > vswitch. Thus we may add to the derieved from RFC 8343 module the=C2=A0 > list of "vPorts" for each phy interface.=C2=A0 >>You should use "augment" if you want to add additional nodes to an=C2=A0 >>existing module.=C2=A0 [Dmytro] Yes I agree, it is exatly what we did in the=C2=A0=C2=A0draft-shyt= yi-opsawg-vysm-04. We augmented "vPorts" to the interfaces :) The same "augment i think it could be appropriate to use in the derived mod= ule from "ietf-interfaces" (RFC 8343) to agment the yang model "ietf-ucpe" > example with 1 phy interface:=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0+-------------------------------------=C2= =A0 >=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 UCPE=C2=A0 >=C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +---------= ---+=C2=A0 >=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |------vPort 1---vlink---(vpo= rt_sw)vswitch(vport_sw)--vlink---.....----WAN=C2=A0 >=C2=A0 > LAN----|=C2=A0 =C2=A0Phy=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= ------vPort 2=C2=A0 >=C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 = =C2=A0interface=C2=A0 =C2=A0 =C2=A0|=C2=A0 >=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0+-------------+=C2=A0 >=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 |=C2=A0 >=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0+-----------------------------------------= -----=C2=A0 >=C2=A0 > 2. If we include the yang module from the RFC 8343 to the set of yang mod= els by default it goes in the root of config mode. i.e:=C2=A0 >=C2=A0 > EXAMPLE:=C2=A0 >=C2=A0 > config t=C2=A0 >=C2=A0 > =C2=A0 =C2=A0 =C2=A0 interfaces interface....=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 > When we have a parent module we need to place the RFC 8343 module to unde= r the parent module (like in the draft=C2=A0draft-shytyi-opsawg-vysm-04).= =C2=A0=C2=A0 >Have you looked at the models in RFC 8529 and RFC 8530? Perhaps you=C2=A0 >can use them, rather than creating another special module for this=C2=A0 >particular use case?=C2=A0 [Dmytro] Thank you for this suggestion, @Martin. I can imagine that we could=C2=A0 assing "ietf-interfaces" to VSI as descri= bed in the RFC 8529. @Martin, looging the schema of yang models for rfc 852= 9(below) can we assign more than one (>1) LNE to the interface (both for rf= c 8529 and 8530)? In the uCPE usecase you may have multiple swithes assigned to the same port= . +--rw network-instances +--rw network-instance* [name] +--rw name string +--rw enabled? boolean +--rw description? string +--rw (ni-type)? +--rw (root-type) +--:(vrf-root) | +--mp vrf-root +--:(vsi-root) | +--mp vsi-root +--:(vv-root) +--mp vv-root module: ietf-interfaces +--rw interfaces | +--rw interface* [name] | +--rw name string | +--rw ip:ipv4! | | +--rw ip:enabled? boolean | | +--rw ip:forwarding? boolean | | +--rw ip:mtu? uint16 | | +--rw ip:address* [ip] | | | +--rw ip:ip inet:ipv4-address-no-zone | | | +--rw (ip:subnet) | | | +--:(ip:prefix-length) | | | | +--rw ip:prefix-length? uint8 | | | +--:(ip:netmask) | | | +--rw ip:netmask? yang:dotted-quad | | +--rw ip:neighbor* [ip] | | | +--rw ip:ip inet:ipv4-address-no-zone | | | +--rw ip:link-layer-address yang:phys-address | | +--rw ni:bind-network-instance-name? string | +--rw ni:bind-network-instance-name? string /martin=C2=A0 On Tue, Oct 22, 2019 at 10:28:03PM +0200, Dmytro Shytyi wrote:=20 >=20 > Cut and paste to change the 'nesting' is _not_ proper usage of=20 > YANG. The value of YANG is that objects with the same semantics are=20 > predictable, this gives you interoperability. By copying modules to=20 > other places (and tweaking semantics), you break the interoperability=20 > promise.=20 >=20 > /js=20 >=20 >=20 > [Dmytro].=20 >=20 > I find the task much easier if we could just augment the interfaces modul= e without changing it. I see it the next way . The "ietf-interfaces" yang m= odule initially was created=C2=A0 for the config, when you have:=20 >=20 > config t=C2=A0=20 >=20 > =C2=A0 =C2=A0 =C2=A0 interfaces interface ...=20 >=20 > Here we have different condition of "nesting"... when module "ucpe-ietf-i= nterfaces" (not "ietf-interfaces") shout augment another module ("ietf-ucpe= ")=20 >=20 >=20 >=20 > We augment vPorts to phy interfaces.=20 =20 >I do not understand your explanation. The ietf-interfaces hierarchy can=20 >be found on page 5 of RFC 8343. You can augment additional nodes into=20 >it. [Dmytro] Yes=C2=A0 we can augment additional nodes into "ietf-interfaces" i= t is what we do in the=C2=A0draft-shytyi-opsawg-vysm-04 : augment "/ietf-nfv:ucpe/ietf-if:interfaces/ietf-if:interface" { list ports { key "port"; leaf port { type string; description "Name of the connector"; } We wold like to have this: module: ietf-ucpe +--rw ietf-ucpe:ucpe* [name] +--rw ietf-ucpe:Name string | +--rw ucpe-if:interfaces =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 .... > >Cut and paste to change the 'nesting' is _not_ proper usage of=20 >=20 > YANG.=20 >=20 > [Dmytro]=20 >=20 > If I understood correctly I can't just derive the parts from the exisitin= g module=C2=A0 (by referencing them) to the new module.=20 >=20 =20 I have no idea what you mean with "(by referencing them) to the new=20 module". You can of course refer to definitions in ietf-interfaces.=20 =20 > So I have two questions:=20 >=20 > If i cant derive the parts from existing module while creating a new, how= to address this issue(when we want "ucpe-ietf-interfaces" to augment "ietf= -ucpe"). Could you suggest something?=20 >I likely do not understand but you can of course augment=20 >ietf-interfaces with additional nodes that refer to ietf-ucpe=20 >definitions if that is what you are looking for. [Dmytro] Yes we can augment the "ietf-interfaces" with new modules. Hovewer= in the=C2=A0draft-shytyi-opsawg-vysm-04 we are looking to augment module "= ietf-ucpe" with modified "ietf-interfaces".=C2=A0 Example SCHEME #1 module: ietf-ucpe +--rw ietf-ucpe:ucpe* [name] +--rw ietf-ucpe:Name string | +--rw ucpe-if:interfaces =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 .... To have a result similar to the scheme#1 (above) we derived the "ietf-inter= faces" to "ietf-ucpe-interfaces". And "ietf-ucpe-interfaces" was modified (= ex. with augment statement,etc..): module ietf-ucpe-interfaces { import ietf-ucpe { prefix ietf-vysm; } ... augment "/ietf-vysm:ucpe"{ container interfaces { description "Interface parameters."; list interface { ... } } } If i cant derive the parts from existing module (ietf-interfaces) while cre= ating a new("ietf-ucpe-interfaces) how we can get the result similar to sch= eme#1? Could you suggest something?=20 =20 > So the=C2=A0 here I have a question: How we will resolve the leafref in t= he=C2=A0draft-shytyi-opsawg-vysm-04. if we will not do the augmentation of = "ietf-ucpe" in the ""ucpe-ietf-interfaces?=20 >=20 > augment "/ietf-nfv:ucpe/ietf-if:interfaces/ietf-if:interface" {=20 > list ports {=20 > key "port";=20 > leaf port {=20 > type string;=20 > description=20 > "Name of the connector";=20 > }=20 > leaf link {=20 > type leafref {=20 > path "../../../../ietf-nfv:links/ietf-nfv:link";=20 > }=20 > description=20 > "Link that is connected to the port=20 > via connector";=20 > }=20 > description=20 > "Set of the connectors the physical=20 > interface has";=20 > }=20 > description=20 > "ucpe ports of the interface";=20 > }=20 > }=20 =20 >I think it is possible to have a path contraint on a leafref that=20 >refers to definitions in other modules (see the ABNF definition=20 >path-arg which resolves to absolute-path and relative-path and=20 >descendant-path and in there you find node-identifier which can carry=20 >an optional prefix that allows to refer to definitions in other=20 >namespaces).=20 /js=20 =20 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH=20 Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany=20 Fax: +49 421 200 3103 ------=_Part_275998_583245835.1571780564105 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Hello,


>[s= ince you sent the same email to two WGs, I have added both to Cc in&n= bsp;
>this reply. i don't thin= k we should have parallell discussions in <= /span>
>different MLs] 

Dmytro Shytyi <<= /span>ietf.dmytro@shytyi.net> wrote: <= /span>
> Hello Jurgen, 
> 
> 
> 
> Thank you for you= r 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. 
<= span class=3D"colour" style=3D"color:rgb(0, 0, 0)">><= span> 
> 
> =
> What do you think about this: =
> <= /span>
> 1. uCPE phy interface has "vPorts" to witch "vLin= ks are 
> assigned"= . "vLinks "connect" the phy interface with  "vPort" of 
> vswitch. Thus we may add to the= derieved from RFC 8343 module the <= /span>
> list of "vPorts" for each phy interface. 

>>You should us= e "augment" if you want to add additional nodes to an 
>>existing module. 

[Dmytro] Yes I= agree, it is exatly what we did in the  draft-shytyi-opsawg-vysm= -04. We augmented "vPorts" to the interfaces :)
The same "aug= ment i think it could be appropriate to use in the derived module from "iet= f-interfaces" (RFC 8343) to agment the yang model "ietf-ucpe"

> example with 1 phy interface: 
> <= br>
> 
<= span class=3D"highlight" style=3D"background-color:rgb(255, 255, 255)">> 
>    =             &nb= sp;            =   +------------------------------------- 
> <= /span>
>          &n= bsp;            = ;        |      &nbs= p;           UCPE =
> 
>                  = +------------+ 
<= span class=3D"colour" style=3D"color:rgb(0, 0, 0)">><= span> 
>   &nbs= p;            &= nbsp;  |                &= nbsp;       |------vPort 1---vlink---(vport_sw)vswitch(vport= _sw)--vlink---.....----WAN 
> 
<= span class=3D"highlight" style=3D"background-color:rgb(255, 255, 255)">> LA= N----|   Phy             |----= --vPort 2 
>&= nbsp;
>       &= nbsp;           |   interface  &nbs= p;  | 
>=  
>    &nb= sp;            =   +-------------+ <= br>
> 
<= span class=3D"highlight" style=3D"background-color:rgb(255, 255, 255)">> &n= bsp;             &nb= sp;            =    | 
> 
>    = ;            &n= bsp;            = ;  +---------------------------------------------- 
> 
> 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 mod= e. i.e: 
>&nb= sp;
= > EXAMPLE: 
> 
> config t 
> 
= >       interfaces interface.... 
> <= /span>
> 
=
&g= t; 
> When we have = a parent module we need to place the RFC 8343 module to under the parent mo= dule (like in the draft draft-shytyi-opsawg-vysm-04).  = ;


&= gt;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? =

[Dmytro] Thank you for t= his suggestion, @Martin.

I can imagine that we= could  assing "ietf-interfaces" to VSI as described in the RFC 8529. = @Martin, looging the schema of yang models for rfc 8529(below) can we assig= n more than one (>1) LNE to the interface (both for rfc 8529 and 8530)?<= br>
In the uCPE usecase you may have multiple swithes assigned to= the same port.

+--rw network-instances
        +--rw network-instance* [name]
           +--rw name           string
           +--rw enabled?       boolean
           +--rw description?   string
           +--rw (ni-type)?
           +--rw (root-type)
              +--:(vrf-root)
              |  +--mp vrf-root
              +--:(vsi-root)
              |  +--mp vsi-root
              +--:(vv-root)
                 +--mp vv-root

   module: ietf-int=
erfaces
      +--rw interfaces
      |  +--rw interface* [name]
      |     +--rw name                        string
      |     +--rw ip:ipv4!
      |     |  +--rw ip:enabled?                      boolean
      |     |  +--rw ip:forwarding?                   boolean
      |     |  +--rw ip:mtu?                          uint16
      |     |  +--rw ip:address* [ip]
      |     |  |  +--rw ip:ip               inet:ipv4-address-no-zone
      |     |  |  +--rw (ip:subnet)
      |     |  |     +--:(ip:prefix-length)
      |     |  |     |  +--rw ip:prefix-length?   uint8
      |     |  |     +--:(ip:netmask)
      |     |  |        +--rw ip:netmask?         yang:dotted-quad
      |     |  +--rw ip:neighbor* [ip]
      |     |  |  +--rw ip:ip                  inet:ipv4-address-no-zone
      |     |  |  +--rw ip:link-layer-address yang:phys-address
      |     |  +--rw ni:bind-network-instance-name?   string
      |     +--rw ni:bind-network-instance-name?   string

/martin 




= On Tue, Oct 22, 2019 at 10:28:03PM +0200, Dmytro Shytyi wrote:
> > Cut and paste to change the 'nesting' is _not_ proper usage of
&g= t; YANG. The value of YANG is that objects with the same semantics are
= > predictable, this gives you interoperability. By copying modules to > other places (and tweaking semantics), you break the interoperabilit= y
> promise.
>
> /js
>
>
> [Dmytr= o].
>
> I find the task much easier if we could just augment = the interfaces module without changing it. I see it the next way . The "iet= f-interfaces" yang module initially was created  for the config, when = you have:
>
> config t 
>
>     =   interfaces interface ...
>
> Here we have different co= ndition of "nesting"... when module "ucpe-ietf-interfaces" (not "ietf-inter= faces") shout augment another module ("ietf-ucpe")
>
>
&g= t;
> We augment vPorts to phy interfaces.

>I do not unde= rstand your explanation. The ietf-interfaces hierarchy can
>be found= on page 5 of RFC 8343. You can augment additional nodes into
>it.

[Dmytro] Yes  we can augment additional nodes = into "ietf-interfaces" it is what we do in the draft-shytyi-opsawg-vys= m-04 :
augment "/ietf-nfv:ucpe/=
ietf-if:interfaces/ietf-if:interface" {
       list ports {
         key "port";
         leaf port {
           type string;
           description
             "Name of the connector";
         }

We wold like to have this:
module: ietf-ucpe
+--rw ietf-ucpe:ucpe* [name]
   +--rw ietf-ucpe:Name              string
   |
   +--rw ucpe-if:interfaces
         = ;   ....



> >Cut and paste to ch= ange the 'nesting' is _not_ proper usage of
>
> YANG.
>= ;
> [Dmytro]
>
> If I understood correctly I can't jus= t derive the parts from the exisiting module  (by referencing them) to= the new module.
>

I have no idea what you mean with "(by r= eferencing them) to the new
module". You can of course refer to definit= ions in ietf-interfaces.

> So I have two questions:
> > If i cant derive the parts from existing module while creating a new= , how to address this issue(when we want "ucpe-ietf-interfaces" to augment = "ietf-ucpe"). Could you suggest something?
>I likely do not understa= nd but you can of course augment
>ietf-interfaces with additional no= des that refer to ietf-ucpe
>definitions if that is what you are loo= king for.

[Dmytro] Yes we can augment the "ietf-in= terfaces" with new modules. Hovewer in the draft-shytyi-opsawg-vysm-04= we are looking to augment module "ietf-ucpe" with modified "ietf-interface= s".  Example
SCHEME #1
module: ietf-ucpe
+--rw ietf-ucpe:ucpe* [name]
   +--rw ietf-ucpe:Name              string
   |
   +--rw ucpe-if:interfaces
         = ;   ....

To have a result similar to the = scheme#1 (above) we derived the "ietf-interfaces" to "ietf-ucpe-interfaces"= . And "ietf-ucpe-interfaces" was modified (ex. with augment statement,etc..= ):
module ietf-ucpe-interfaces {
         import ietf-ucpe { prefix ietf-vysm; }
         ...
         augment "/ietf-vysm:ucpe"{
               container interfaces {
                     description "Interface parameters.";
                     list interface {
                     ...
                     }
         }
   }

If i cant derive the parts from existing modu= le (ietf-interfaces) while creating a new("ietf-ucpe-interfaces) how we can= get the result similar to scheme#1?
Could you suggest someth= ing?

> So the  here I have a question: How we will resolve= the leafref in the draft-shytyi-opsawg-vysm-04. if we will not do the= augmentation of "ietf-ucpe" in the ""ucpe-ietf-interfaces?
>
&g= t; augment "/ietf-nfv:ucpe/ietf-if:interfaces/ietf-if:interface" {
>= list ports {
> key "port";
> leaf p= ort {
> type string;
> description
= > "Name of the connector";
> }
> = leaf link {
> type leafref {
> = path "../../../../ietf-nfv:links/ietf-nfv:link";
> }
= > description
> "Link that is connected t= o the port
> via connector";
> }
&= gt; description
> "Set of the connectors the phy= sical
> interface has";
> }
> = description
> "ucpe ports of the interface";
> = }
> }

>I think it is possible to have a path contra= int on a leafref that
>refers to definitions in other modules (see t= he ABNF definition
>path-arg which resolves to absolute-path and rel= ative-path and
>descendant-path and in there you find node-identifie= r which can carry
>an optional prefix that allows to refer to defini= tions in other
>namespaces).


/js <= br>
--
Juergen Schoenwaelder Jacobs University Bremen gGm= bH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germa= ny
Fax: +49 421 200 3103 <https://www.jacobs-university.de/> <= br>


------=_Part_275998_583245835.1571780564105--