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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
