Subject: [netmod] YANG conformance for augments

From: Andy Bierman <[email-masked]>
Date: Sun, 15 Mar 2015 09:10:24 -0700

Hi,

Assume 3 simple YANG modules, aug1, aug2, and aug3.

module aug1 {
    namespace "http://yumaworks.com/ns/aug1";
    prefix "aug1";
    revision 2015-03-15;

    container A { }
    leaf L1 { type string; }
}

module aug2 {
    namespace "http://yumaworks.com/ns/aug2";
    prefix "aug2";
    import aug1 { prefix aug1; }
    revision 2015-03-15;

    augment /aug1:A {
      container B { }
    }
    leaf L2 { type string; }
     /* could also have aug2 augmenting more modules
      *  augment /foo:X {  .... }
      */
}

module aug3 {
    namespace "http://yumaworks.com/ns/aug3";
    prefix "aug3";
    import aug1 { prefix aug1; }
    import aug2 { prefix aug2; }
    revision 2015-03-15;

    augment /aug1:A/aug2:B {
      container C { }
    }
}

According to some proposals, a server MUST implement all of aug1
in order to advertise conformance to aug2 and aug3.  So in order for
module aug2 to extend the NP container /aug1:A it MUST implement
/aug1:L1 as well.

Module aug3 MUST implement all of module aug1 and aug2,
adding 'B' and 'C'.  If aug2 augmented another external module
like 'foo:/X' then aug3 MUST implement the entire foo module.

IMO the direct coupling of YANG module contents to conformance
is not a good idea.  The simplistic conformance rules for augment
(especially for NP containers) are not going to work.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 18 Mar 2015 13:06:26 +0100

> module aug2 to extend the NP container /aug1:A it MUST implement

An augment makes sense only if the augmented module is included in hello
or otherwise declared to be a part of the data model. And yes, this then
implies that the augmented module must be implemented.

Lada

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

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Wed, 18 Mar 2015 06:53:14 -0700

> implies that the augmented module must be implemented.

Why is the advertisement of aug1 or aug2 required, instead
of just the import-stmt in the augmenting module?

Are you suggesting the way that new functionality is attached to
old functionality changes the YANG conformance?

Let's say to fiztest module provides some config parameters
to run some packet tests over an interface.

   container fizbin-parms { .... }

There are 3 ways I can attach this container to an interface

1) augment

    augment /if:interfaces/if:interface {
        container fizbin-parms { ... }
    }

2) leafref coupling

   container fizbin-parms {
        leaf itf-name { type if:interface-ref; }
        ...
    }

3) type coupling

    container fizbin-parms {
        leaf itf-name { type stringf; }
         ...
    }

Note that (2) only requires importing a typedef and (3) does not require
an import-stmt at all.  In every case (1 - 3) the implementation
requirements for fizbin-parms are exactly the same (i.e.,
ability to send and receive packets on the specified interface.
Probably needs to understand the 'type' and 'enabled' leafs).

IMO the conformance requirements to implement the fizbin module
should not depend on how it is coupled to the interfaces module.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 18 Mar 2015 16:25:32 +0100

> of just the import-stmt in the augmenting module?

Because the server has to implement the augment's target node, otherwise
the augment doesn't make sense. An import only gives the importing module
access to (some) nodes in the imported module, without side effects.

> old functionality changes the YANG conformance?

I don't think so.

> should not depend on how it is coupled to the interfaces module.

If the server doesn't implement ietf-interfaces, then IMO both (1) and
(2) mean that fiztest alone is invalid. I believe pyang will emit an
error message in both cases.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Wed, 18 Mar 2015 09:39:44 -0700

> error message in both cases.

How does pyang know what the server is advertising, just from the YANG module?
What is the error?

In all cases the example module needs to identify which interface
to apply the fiztest parameters. The "augment",  "leafref"
and "type string" mechanisms do not really change the
implementation relationship between these 2 modules.
However, it seems the conformance specification is directly coupled
to the particular YANG statements used.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 18 Mar 2015 19:25:25 +0100

> On 18 Mar 2015, at 17:39, Andy Bierman <[email-masked]> wrote:
> 

See https://github.com/mbj4668/pyang/wiki/Tutorial#yang-data-model

In fact, I think we should talk about a data model, which is the substance of the contract between the server and client, rather than about what the server implements or not.

The error is that (1) the target node for an augment doesn’t exist in the data model, and (2) a leafref’s path doesn’t exist in the data model.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Wed, 18 Mar 2015 12:29:23 -0700

>> to the particular YANG statements used.

OK -- I am ready to drop the whole issue of YANG conformance.
My experience on IETF and Cisco MIB Police has been that
if a developer wants to reuse existing objects, but the conformance
required more than what the new application really needed,
then the new work cut-and-paste or did something else to
avoid proper reuse.

It is fairly difficult to reliably predict 2 - 5 years in advance how a module
will be reused later for new use-cases that were never considered
in the initial module.  Perhaps YANG developers will be better at that
than SMIv2 developers have been in the past.

Andy