Re: [netmod] A reworking of RFC8343

[Schönwälder, Jürgen <[e-mail]>]

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 
> 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 interoperability 
> promise. 
>  
> /js
> 
> 
> [Dmytro]. 
> 
> I find the task much easier if we could just augment the interfaces module without changing it. I see it the next way . The "ietf-interfaces" yang module initially was created  for the config, when you have:
> 
> config t 
> 
>       interfaces interface ...
> 
> Here we have different condition of "nesting"... when module "ucpe-ietf-interfaces" (not "ietf-interfaces") shout augment another module ("ietf-ucpe")
> 
> 
> 
> We augment vPorts to phy interfaces.

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

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

I have no idea what you mean with "(by referencing them) to the new
module". You can of course refer to definitions 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 understand but you can of course augment
ietf-interfaces with additional nodes that refer to ietf-ucpe
definitions if that is what you are looking for.

> 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?
> 
> augment "/ietf-nfv:ucpe/ietf-if:interfaces/ietf-if:interface" {
>        list ports {
>          key "port";
>          leaf port {
>            type string;
>            description
>              "Name of the connector";
>          }
>          leaf link {
>            type leafref {
>              path "../../../../ietf-nfv:links/ietf-nfv:link";
>            }
>            description
>              "Link that is connected to the port
>               via connector";
>          }
>          description
>            "Set of the connectors the physical
>             interface has";
>        }
>        description
>          "ucpe ports of the interface";
>      }
>    }

I think it is possible to have a path contraint on a leafref that
refers to definitions in other modules (see the ABNF definition
path-arg which resolves to absolute-path and relative-path and
descendant-path and in there you find node-identifier which can carry
an optional prefix that allows to refer to definitions in other
namespaces).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>