Subject: [netmod] leafref and identityref

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 21 Oct 2019 13:27:02 +0200

Hi,

consider the following situation:

module A {
  ...
  prefix a
  identity X;
  leaf foo {
    type identityref {
      base X;
    }
  }
}

module B {
  ...
  import A {
    prefix a;
  }
  leaf fooref {
    type leafref {
      path "/a:foo";
    }
  }
}

What is now a correct lexical form of fooref's value? Could it be just 'X', or is the prefix required, i.e. 'a:X'?

This is not very clear from RFC 7950 (sections 9.9.4 and 9.10.3). I am inclined to require the prefix.

Lada

-- 
Ladislav Lhotka 
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 21 Oct 2019 13:40:14 +0200 (CEST)

Hi,

Ladislav Lhotka <[email-masked]> wrote:
> What is now a correct lexical form of fooref's value? Could it be just
> 'X', or is the prefix required, i.e. 'a:X'?
> 

9.10.3 says:

   If the prefix is not
   present, the namespace of the identityref is the default namespace
   in effect on the element that contains the identityref value.

so the interpretation of a missing prefix in "fooref" is that the
identity is defined in module B.

(a missing prefix in "foo" means that the identity is defined in
module A)

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 21 Oct 2019 13:58:01 +0200

> (a missing prefix in "foo" means that the identity is defined in

To be more specific, here is an example instance:

<foo xmlns="...namespace of A...">X</foo>
<fooref xmlns="...namespace of B...">X</fooref>

It can be argued that this is correct because (sec. 9.9.4):

   A leafref value is lexically represented the same way as the leaf it
   references represents its value.

That is, the same lexical representation is assumed, which is exactly what we
have in the example.

It seems that we agree that it is incorrect, but then sec. 9.9.4 should be
clarified.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 21 Oct 2019 14:01:50 +0200 (CEST)

> That is, the same lexical representation is assumed, which is exactly what we

It doesn't say that the lexical value is exactly the same, but
"represented the same way" - so when the lexical representation is
context dependent we have this situation.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 21 Oct 2019 14:59:20 +0200

> context dependent we have this situation.

OK, but still: foo represents its value using the default namespace on <foo>,
which is "...namespace of A...". That's why

is correct. And if the fooref value is LEXICALLY represented the same way, then
it has to be "X" as well (this is what lexical space value means in XML).

What we probably mean is something like

   The rules for a leafref value are obtained by pretending that the leaf has 
   the same type as the referenced leaf.

Lada

---

From: tom petch <[email-masked]>
Date: Tue, 22 Oct 2019 10:25:51 +0000

Martin

I am wondering how much you know about a module that says
      WG List:  <mailto:[email-masked]>
      Editor:   Martin Bjorklund
                <mailto:[email-masked]>";

The module is
  module ietf-ucpe-interfaces {
in
  draft-shytyi-opsawg-vysm-04

The author appears to have taken RFC8343, changed the module and prefix
name (but not the Editor) and added, at the top level,
   augment "/ietf-vysm:ucpe" {
(ucpe also appears in this I-D).  I have commented on the OPSAWG list
about this approach not being one I have seen before and the response is
that the yang validator is fine with it.

Thoughts?

An earlier version of this module had
  import tailf-ncs
which also had me wondering.

Tom Petch

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 22 Oct 2019 13:31:31 +0200 (CEST)

>   draft-shytyi-opsawg-vysm-04

Haha!  I don't know anything about it.

> that the yang validator is fine with it.

Clearly unacceptable.  Unclear why a ucpe can't implement
ietf-interfaces from 8343.

> which also had me wondering.

Hmm.

/martin

---

From: tom petch <[email-masked]>
Date: Tue, 22 Oct 2019 11:59:51 +0000

----- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
Sent: Tuesday, October 22, 2019 12:31 PM

Martin

Thanks for that; I was rather thinking that that was the case:-)

Tom Petch

---

From: Dmytro Shytyi <[email-masked]>
Date: Tue, 22 Oct 2019 21:53:42 +0200

Hello Martin,

We are interested in  some specific functionality provided by RFC 8343 yang model. 

So we derivied the yang model from RFC 8343, modified it and gave module name , prefix with some modifications like "ucpe-interfaces",

but in description we kept the reference to original RFC(in future we wil modify the description to say that it is not original RFC 8343 yang module.)

IMHO it is wrong to not presice in the description(reference) of the module / RFC that was we find usefull in our work.

>Clearly unacceptable.  Unclear why a ucpe can't implement 

ietf-interfaces from RFC 8343. 
I will try to give some ideas here.  

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

______________
Dmytro SHYTYI

---- On Tue, 22 Oct 2019 13:31:31 +0200 Martin Bjorklund <mailto:[email-masked]> wrote ----

tom petch <mailto:[email-masked]> wrote: 
>       WG List:  <mailto:mailto:[email-masked]> 
>       Editor:   Martin Bjorklund 
>                 <mailto:mailto:[email-masked]>"; 
> 
> The module is 

 

Hmm. 

/martin 
 
_______________________________________________ 
netmod mailing list 
mailto:[email-masked] 
https://www.ietf.org/mailman/listinfo/netmod

---

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

> example with 1 phy interface:

You can augment a model without having to copy it. Whether your
augmentation makes sense I can't tell, not also that interface can be
layered.

>       ucpe "ucpe X" interfaces interface...

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

-- 
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:28:03 +0200

Hello,

[Dmytro] Yes I agree, it is exatly what we did in the  draft-shytyi-opsawg-vysm-04. We augmented "vPorts" to the interfaces :)

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

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

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?

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";
     }
   }

Thanks!

---

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

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

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

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

---

From: Dmytro Shytyi <[email-masked]>
Date: Tue, 22 Oct 2019 23:42:44 +0200

Hello,

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

The same "augment i think it could be appropriate to use in the derived module from "ietf-interfaces" (RFC 8343) to agment the yang model "ietf-ucpe"

>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 this 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 assign more than one (>1) LNE to the interface (both for rfc 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 

>be found on page 5 of RFC 8343. You can augment additional nodes into 

[Dmytro] Yes  we can augment additional nodes into "ietf-interfaces" it is what we do in the draft-shytyi-opsawg-vysm-04 :

We wold like to have this:

module: ietf-ucpe
+--rw ietf-ucpe:ucpe* [name]
   +--rw ietf-ucpe:Name              string
   |
   +--rw ucpe-if:interfaces

            ....

 
>definitions if that is what you are looking for.

[Dmytro] Yes we can augment the "ietf-interfaces" with new modules. Hovewer in the draft-shytyi-opsawg-vysm-04 we are looking to augment module "ietf-ucpe" with modified "ietf-interfaces".  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 module (ietf-interfaces) while creating a new("ietf-ucpe-interfaces) how we can get the result similar to scheme#1?

Could you suggest something? 

/js

---

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

> augment "/ietf-nfv:ucpe/ietf-if:interfaces/ietf-if:interface" {

This is _not_ augmenting into ietf-interfaces.

>    +--rw ietf-ucpe:Name              string
 
If 'ucpe-if:interfaces' is supposed to be RFC 8343 interfaces, then
(1) you can't do this and (2) you do not want to do this.

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

You are not composing and reusing models, you cut and paste models,
creating modified copies that do not interoperate. This is not what
the IETF tries to do.

The standard interfaces model is in /if:interfaces. There is likely no
point of replicating it elsewhere.

> Could you suggest something? 

I have not seen a reason why scheme#1 is a good idea, I have given
reasons why copying is a bad idea. It appears to me like you are
trying to invent a different tree structure for a specific kind of
devices but having per device class different trees is not what we aim
for in the IETF. We aim for reuse of models across a wide range of
different devices.

/js