Subject: Re: [netmod] Y26 again, sorry

From: Randy Presuhn <[email-masked]>
Date: Mon, 24 Aug 2015 12:20:36 -0700 (GMT-07:00)

Hi -

>From: Ladislav Lhotka <[email-masked]>
>Sent: Aug 24, 2015 11:44 AM
>To: Andy Bierman <[email-masked]>
>Cc: "[email-masked]" <[email-masked]>
>Subject: Re: [netmod] Y26 again, sorry
...
>> YANG does not provide any mechanism to REQUIRE  modules A and B
>> to both be implemented on a server.  You may think it should, but
>> currently the YANG conformance is for an individual module.
>
>There are sections on conformance and conformance announcement,
>and they say nothing like this. In my view, the data model comprises
>*all* modules advertised by the server. I think your interpretation
>of conformance might be an extrapolation from SNMP/SMI times, but,
>for better or worse, it really has no support in the YANG spec.

It sounds as though you might be talking past each other.
I believe part of Andy's point is that clients will need to deal
with servers that do not implement (and thus do not advertise)
the augmenting module.  But there's (I think) a more interesting
issue beneath this.

Let's start with module M.  Let's say M is for "modem" (to pick
an obsolete but widely understood resource).
Two different augmenting modules, F (for FSK - frequency
shift keying) and Q (for QAM - quadrature amplitude modulation)
are developed.  Let us say that F and Q are mutually incompatible.

A system with multiple Ms could well have both M+F and M+Q modems,
but (if we claim F & Q are incompatible) could not have M+F+Q.
If naked M is to be prohibited in systems (also) supporting F or Q
or both, we don't currently have a mechanism to do so.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 24 Aug 2015 14:05:40 -0700

> or both, we don't currently have a mechanism to do so.
When I examine the module M, I have absolutely no way of knowing
about F or Q.  Where are the instructions to the developers that only
M+F or M+Q is allowed, and never M or M+F+Q?  Where would they
go except M or a stand-alone document describing M+* ?

If these instructions are not in M, F, or Q, then how will
developers find it?  It seems we would need a way to
say that conformance to M is not meaningful.
Only conformance to  M+? is meaningful
(where M can define the requirements for ?)

> Randy
Andy

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

---

From: Robert Wilton <[email-masked]>
Date: Mon, 24 Aug 2015 22:24:05 +0100

Hi Randy,

> or both, we don't currently have a mechanism to do so.
Could this be achieved by augmenting from a choice statement?

M defines the choice statement but with no case statements.

F and Q both implement separate case statements that augment the choice 
statement in M.  The case statements have containers which hold the 
parameters related to F or Q.

M without F or Q is meaningless.
M+F or M+Q works, but the choice statement means that you cannot have M+F+Q.

I can point you to a concrete example if it helps.

Thanks,
Rob

---

From: Andy Bierman <[email-masked]>
Date: Mon, 24 Aug 2015 14:50:49 -0700

> M+F or M+Q works, but the choice statement means that you cannot have
nice solution

This is perhaps the cleanest way to add mandatory nodes to a module.
The old client will not attempt to create the new case.

As I said before, I am OK with changing MUST NOT to SHOULD NOT
add mandatory nodes, and then add MAY when X, Y, Z conditions are met.

Two conditions so far:

    (1)  augment + when <new flag set that old client will not set>

    (2) augment choice with a new case-stmt

(1) is hard to define, but not (2)

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 25 Aug 2015 13:04:35 +0200

> the augmenting module.  But there's (I think) a more interesting

As I understand it, the restriction on mandatory nodes in augments
addresses the opposite situation where the server addresses both the
original and augmenting module, whereas the client supports only the
original one. 

> but (if we claim F & Q are incompatible) could not have M+F+Q.

A solution could be similar to what "ietf-interfaces" does:

list modem {
    key name;
    leaf name { ... }
    leaf type { ... }
    ...
}

F and G would then augment the "modem" list, for example:

augment "/.../M:modem" {
    when "M:type = 'FSK'";
    ...
}

Module M can also implement the concept of system-controlled modem
entries.

The server then may advertise M+F or M+Q or M+F+Q depending on the
supported technologies.

Of course, the author of module M has to anticipate that there may be
multiple modems of different types. If M only has

container modem { ... }

then we are stuck.

The problem with the above approach is that either F or Q may need some
mandatory parameters to be configured for which no (static) defaults
exist - but this condition cannot be properly specified in the data
model. That's what this thread is about.

> or both, we don't currently have a mechanism to do so.

I don't know whether naked M exactly needs to be prohibited (as an
"abstract class"). It causes no harm, as naked "ietf-interfaces", only
it is of limited use because there isn't much to be configured. A server
implementor should have an idea about what needs to be configured, and
will therefore add one or more augmenting modules that will be
advertised along with M.

Lada

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

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 25 Aug 2015 14:01:02 +0200 (CEST)

Hi,

I think this could work (thanks Robert; maybe this is what you
meant!):

  container zones {
    list zone {
      ...
      list rrset {
        ...
        leaf type {
          type identityref { ... }
        }
        list rdata {
          key id;
          ...
          choice type-specific-params {
            mandatory true;
            // to be augmented with type-specific nodes
          }
        }
      }
    }
  }

And then in another module:

  augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata"
        + "/type-specific-parameters" {
    when "derived-from-or-self(../dnsz:type,'iana-dns-parameters',"
       + "'TLSA')";

    leaf certificate-usage {
      mandatory true;
      ...
    }
  }

The empty mandatory choice formally tells the client that additional
cases are expected.

(If the empty choice looks fishy, it is probably often possible to
define at least one case inline...)

This pattern is nice to the client, since there is no way an
additional augmenting module can break a working client.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 25 Aug 2015 14:35:01 +0200

> On 25 Aug 2015, at 14:01, Martin Bjorklund <[email-masked]> wrote:
> 
> Hi,
> 

Yes, I just tried very similar test modules with pyang, and DSDL seems to validate instance data as expected: at least one case has to be present, so no valid instance exists for the “abstract” module alone.

I think it is a better approach to subclassing than augment+when.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 25 Aug 2015 14:48:54 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> Yes, I just tried very similar test modules with pyang, and DSDL seems
> to validate instance data as expected: at least one case has to be
> present, so no valid instance exists for the “abstract” module alone.
> 

It is augemnt-choice+when.

I agree it solves the "subclassing" use case, but it has its
limitations.  For example, you cannot have two separate modules
augment with the same type.  But then, in such a case you can
still to the old augment-p-container+when.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 25 Aug 2015 15:01:29 +0200

> On 25 Aug 2015, at 14:48, Martin Bjorklund <[email-masked]> wrote:
> 

when isn’t strictly necessary here because different cases cannot appear together. The schema is much cleaner, which is also immediately visible on the tree output.

> still to the old augment-p-container+when.

I am not sure I understand exactly what you mean but perhaps the second augmenting module could then augment the case node in the first augment. 

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 25 Aug 2015 16:07:51 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> when isn’t strictly necessary here because different cases cannot
> appear together.

Well, the when statement is needed to make sure that you configure
nodes from a case that matches the specified type.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 25 Aug 2015 18:27:40 +0200

> On 25 Aug 2015, at 16:07, Martin Bjorklund <[email-masked]> wrote:
> 

Yes, if the type has some meaning on its own. In the case of augments without choice, something like type has to be present in any case because otherwise nodes from different cases would get mixed up.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 26 Aug 2015 10:28:58 +0200

Hi,

I changed the DNS zone data model to use this pattern - it looks
good and works great:

- module:
  https://gitlab.labs.nic.cz/llhotka/zone-data-yang/blob/master/dns-zones.yang
  
- tree:
  https://gitlab.labs.nic.cz/llhotka/zone-data-yang/raw/master/model.tree

Lada