Subject: [netmod] Y26 again, sorry

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 13 Aug 2015 16:07:49 +0200

Hi,

although YANG 1.1 issue Y26 [1] is marked as DONE, I think the adopted
solution Y26-02 is really horrible, so at least I want to make sure the
WG is aware of the consequences.

I am currently working on a data model for DNS zone data and the schema
is like this:

module: dns-zones
   +--rw zones
      +--rw zone* [name]
         +--rw name           inet:domain-name
         +--rw description?   string
         +--rw class?         ianadns:class
         +--rw rrset* [owner type]
            +--rw owner          inet:domain-name
            +--rw type           identityref
            +--rw description?   string
            +--rw ttl            positive-int32
            +--rw rdata* [id]
               +--rw id             string
               +--rw description?   string

The idea is that specific RDATA will be added for each RR type (with a
"when" condition based on "type"). Data for essential RR Types (SOA, NS,
A, AAAA, ...) can be defined in the same module but for some types they
need to be defined in other modules and added via augmenting the target
node "rdata". Typically, some (or all) of RDATA is mandatory, and this
is where Y26 comes into play. The solution recommended by Y26-02 would
look like this:

augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" {
    when "derived-from-or-self(../dnsz:type,'iana-dns-parameters',"
       + "'TLSA')";
    container rdata {            // <=================
        presence "TLSA data";
        leaf certificate-usage {
            mandatory true;
            ...
        }
        ...
    }
}

Note the superfluous presence container "rdata". It that just adds a
useless level of hierarchy and still doesn't enforce the correct
constraints: the data model allows the presence container to be missing
so that RDATA will be empty. Defining this extra container for all ~75
RR types is a nuisance and it certainly won't make the modules more
readable.

As this situation is likely to be very common, I wonder: do we really
want to do that?

[1] https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-27

Thanks, Lada

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

---

From: Robert Wilton <[email-masked]>
Date: Thu, 13 Aug 2015 15:44:54 +0100

Hi Lada,

I agree with you in that I don't really understand how having a 
p-container solves the problem of a mandatory node, since as you say the 
p-container could just be left out so to me it seems that any child node 
marks as mandatory isn't truly mandatory anyway!

I have a similar issue in the YANG that I have defined in 
draft-wilton-netmod-intf-ext-yang-00 (reproduced below) for defining the 
nature of a sub-interface.

Basically, I would like the model to enforce the rule that every child 
sub-interface must have a parent, but I can't currently really see a 
satisfactory solution to this problem.  My working assumption is that I 
would end up describing the field as being mandatory, but not mark it as 
mandatory in YANG (obviously), and assume that backend servers would 
enforce that the leaf is present when the configuration is verified.  
But I'm open to any better suggestions that folks may have on how to 
model this :-)

<snip from draft-wilton-netmod-intf-ext-yang-00

   /*
    * Add generic support for sub-interfaces.
    *
    * This should be extended to cover all interface types that are
    * child interfaces of other interfaces.
    */
   augment "/if:interfaces/if:interface" {
     when "if:type = 'ianaift:l2vlan' or
           if:type = 'ianaift:atmSubInterface' or
           if:type = 'ianaift:frameRelay'"  {
       description
         "Any ianaift :types that represent sub-interfaces";
     }
     if-feature "sub-interfaces";
     description "Add a parent interface field to interfaces to model
                  sub-interfaces";
     leaf parent-interface {
       type if:interface-ref;
       /*
        * TODO - How to make this mandatory without using the
        * mandatory keyword.
        * - Current options appear to be:
        *   - Create a sub-interface container with presence.
        *   - Enforce the constraint with a must statement.
        */
       //mandatory true;
       description
         "This is the mandatory reference to the parent interface of
          this sub-interface.";
     }
   }

Thanks,
Rob

---

From: Andy Bierman <[email-masked]>
Date: Thu, 13 Aug 2015 07:46:10 -0700

Hi,

I'm not sure how many times we need to go over this issue...

YANG conformance is based on the YANG module.
YANG has no concept of conformance beyond this
simplistic approach,  You cannot assume (ever, under any conditions)
that module foo AND bar will both be present on a server.

Therefore if a client is written to work with "foo", it has no
responsibility at all to know that "bar" adds a mandatory
node to a "foo" subtree.

The extra P-container is needed to make sure clients written
to work with module "foo" do not break when new nodes are
added via augments.

We already decided not to do anything useful wrt/ Y45,
so we are stuck with the YANG module as the unit of conformance.

Andy

On Thu, Aug 13, 2015 at 7:07 AM, Ladislav Lhotka <[email-masked]> wrote:

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

---

From: Robert Wilton <[email-masked]>
Date: Thu, 13 Aug 2015 16:39:59 +0100

Hi Andy, Lada,

> to work with module "foo" do not break when new nodes are

I still don't see how a P-container really solves the problem since any 
child mandatory nodes aren't really mandatory, or at least not in the 
way that is actually intended.

E.g. in Lada's example having the P-container implies that for a given 
RR type it is acceptable to either not provide any extra RR specific 
config (i.e. no P-container), or if RR specific config is provided then 
some fields must always be provided, and others can be left out.  I.e. 
the P-container also needs to be mandatory for the configuration to be sane.

To me, in this scenario, it feels that you might as well forego both the 
P-container and mandatory marking.

Thanks,
Rob

> On Thu, Aug 13, 2015 at 7:07 AM, Ladislav Lhotka <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     [1]
>     https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-27
>
>     Thanks, Lada
>
>     --
>     [email-masked] <mailto:[email-masked]>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 13 Aug 2015 09:08:31 -0700

On Thu, Aug 13, 2015 at 8:39 AM, Robert Wilton <[email-masked]> wrote:

> child mandatory nodes aren't really mandatory, or at least not in the way
> that is actually intended.
>
>

The concepts behind old-manager/new-agent protection mechanisms go back
a couple decades (with SNMP).  There is no way that a vendor can control all
the applications using a particular module, and therefore mandate a flag-day
upgrade on all clients, in order to upgrade some servers.

YANG is very limited wrt/ adding new functionality,
A designer must guess correctly on all mandatory nodes
on the first version.  If this a bug, then it should be fixed
properly, instead of just pretending it's OK to break
existing client apps.

(YANG packages do not fix this problem BTW)

Perhaps we need a new module-level "release" statement.

   release stable;
   release unstable;
   release experimental;

Then all the very strict YANG change control rules can be relaxed on
unstable and experimental modules.

E.g. in Lada's example having the P-container implies that for a given RR
> type it is acceptable to either not provide any extra RR specific config
> (i.e. no P-container), or if RR specific config is provided then some
> fields must always be provided, and others can be left out.  I.e. the
> P-container also needs to be mandatory for the configuration to be sane.
>
>
A P-container insulates the old client because it would not know to
create it, and the mandatory child nodes are only checked if
the P-container exists.

Andy

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

---

From: Robert Wilton <[email-masked]>
Date: Thu, 13 Aug 2015 18:44:16 +0100

Hi Andy,

On 13/08/2015 17:08, Andy Bierman wrote:
>
>
> On Thu, Aug 13, 2015 at 8:39 AM, Robert Wilton <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Andy, Lada,
>
>     I still don't see how a P-container really solves the problem
>     since any child mandatory nodes aren't really mandatory, or at
>     least not in the way that is actually intended.
>
>
>
Yes, I agree in principle, but I'm not sure whether the default set of 
YANG modules has yet reaches the maturity that enforcing this rule truly 
makes sense.  It feels that many of the YANG modules (even those have 
been standardized) are still some what at the experimental stage.  This 
is effectively the same point that you make below.

> properly, instead of just pretending it's OK to break

In Lada's case there is no base version, all of his modules are being 
newly defined.  So, in this scenario, ideally that RR-type specific 
modules should be allowed to augment with mandatory nodes since this 
must effectively be backwards compatible.

> unstable and experimental modules.

Yes, this may make sense for other scenarios, but I don't see that it 
helps with either of the problems that Lada or I have described.

>
>
>
>     E.g. in Lada's example having the P-container implies that for a
>     given RR type it is acceptable to either not provide any extra RR
>     specific config (i.e. no P-container), or if RR specific config is
>     provided then some fields must always be provided, and others can
>     be left out.  I.e. the P-container also needs to be mandatory for
>     the configuration to be sane.
>
>
Yes, but in Lada's example, the P-container doesn't really help anyone, 
since the server has to now handle the case that the RR-type has been 
specified but the corresponding P-container isn't present. If it is 
possible for the server to handle this scenario then the mandatory child 
fields don't have to be mandatory either because some sensible default 
must exist.  This implies that all servers would likely reject the 
configuration as being invalid if the P-container isn't also present.

As I see it, having a P-container here only protects a old client in the 
scenario that it was mis-configured in the first place, i.e. using a 
particular RR-type without the corresponding mandatory nodes being 
specified ... which a sane server should have rejected the config for 
previously.

I don't really want to flog a dead horse, but I do think that the 
mandatory rule could be relaxed to state that it cannot be used to 
introduce non backwards compatible nodes.  The text could specify the 
specific conditions where it is allowed to be used in a augmentation.

Or, alternatively, perhaps allow for a must statement to simulate a 
mandatory keyword in these cases - although I don't think that this 
solution is particularly clear or clean.

Thanks,
Rob

>
>
>     To me, in this scenario, it feels that you might as well forego
>     both the P-container and mandatory marking.
>
>     Thanks,
>     Rob
>
>
>
>
> Andy
>
>>
>>             when
>>         "derived-from-or-self(../dnsz:type,'iana-dns-parameters',"
>>                + "'TLSA')";

---

From: Andy Bierman <[email-masked]>
Date: Thu, 13 Aug 2015 11:11:07 -0700

On Thu, Aug 13, 2015 at 10:44 AM, Robert Wilton <[email-masked]> wrote:

> makes sense.  It feels that many of the YANG modules (even those have been
> standardized) are still some what at the experimental stage.  This is
> effectively the same point that you make below.
>
>
> newly defined.  So, in this scenario, ideally that RR-type specific modules
> should be allowed to augment with mandatory nodes since this must
> effectively be backwards compatible.
>

That's really too bad because YANG has no way of saying
"this group of 4 YANG modules are intended to be used together".
You can pretend it does, but the RFC says differently.

It is difficult if not impossible to write guidelines that insure that
an individual YANG module is updated with mandatory nodes in a way that
does not make assumptions about how the previous module revision
was used.

Since there is no way in YANG to say "the server MUST provide the
base module plus augments module X and Y", there is no way
to do what Lada wants.

With the 'unstable' or 'experimental' attribute, it would be OK to
update the base module directly and add mandatory nodes.
There is no reason augment has to be used.  That is a subjective design
choice.

Andy

> fields don't have to be mandatory either because some sensible default must
> exist.  This implies that all servers would likely reject the configuration
> as being invalid if the P-container isn't also present.
>
>> On Thu, Aug 13, 2015 at 7:07 AM, Ladislav Lhotka < <[email-masked]>
>> [email-masked]> wrote:
>>
>>> Hi,
>>>

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 13 Aug 2015 21:22:26 +0200

> On 13 Aug 2015, at 19:44, Robert Wilton <[email-masked]> wrote:
> 
> Hi Andy,
> 
>> I still don't see how a P-container really solves the problem since any child mandatory nodes aren't really mandatory, or at least not in the way that is actually intended. 
>> 
>> 
>> 
> Yes, I agree in principle, but I'm not sure whether the default set of YANG modules has yet reaches the maturity that enforcing this rule truly makes sense.  It feels that many of the YANG modules (even those have been standardized) are still some what at the experimental stage.  This is effectively the same point that you make below.

Right. Another thing is that augment was IMO originally intended to allow for adding optional or vendor-specific parameters to a base data model. However,  as it turned out, it is in fact used as an essential tool for developing *base* data models in a modular fashion.

I have also argued several times that a client cherry-picking modules advertised by the server is fundamentally unsafe - it may work but may also break things. 

> In Lada's case there is no base version, all of his modules are being newly defined.  So, in this scenario, ideally that RR-type specific modules should be allowed to augment with mandatory nodes since this must effectively be backwards compatible.
> 
> 
>> 
> Yes, this may make sense for other scenarios, but I don't see that it helps with either of the problems that Lada or I have described.

It doesn’t, it is just hand-waving.

> 
>> 
>> 
>> 
>> E.g. in Lada's example having the P-container implies that for a given RR type it is acceptable to either not provide any extra RR specific config (i.e. no P-container), or if RR specific config is provided then some fields must always be provided, and others can be left out.  I.e. the P-container also needs to be mandatory for the configuration to be sane.
>> 
>> 
> Yes, but in Lada's example, the P-container doesn't really help anyone, since the server has to now handle the case that the RR-type has been specified but the corresponding P-container isn't present.  If it is possible for the server to handle this scenario then the     mandatory child fields don't have to be mandatory either because some sensible default must exist.  This implies that all servers would likely reject the configuration as being invalid if the P-container isn't also present.
> 
> As I see it, having a P-container here only protects a old client in the scenario that it was mis-configured in the first place, i.e. using a particular RR-type without the corresponding mandatory nodes being specified ... which a sane server should have rejected the config for previously.
> 
> I don't really want to flog a dead horse, but I do think that the mandatory rule could be relaxed to state that it cannot be used to introduce non backwards compatible nodes.  The text could specify the specific conditions where it is allowed to be used in a augmentation.

We tried to identify such situations but it is not that easy. I think the restriction should be removed and explain backward compatibility issues in 6087bis. Module authors then have to decide whether a certain node needs to be defined as mandatory.

If we clutter new modules with unnecessary p-containers, there will be no way back. 

> 
> Or, alternatively, perhaps allow for a must statement to simulate a mandatory keyword in these cases - although I don't think that this solution is particularly clear or clean.

Exactly, it is an ugly hack to the same effect.

Lada 

> 
> Thanks,
> Rob
> 
> 
>> 
>>  
>> To me, in this scenario, it feels that you might as well forego both the P-container and mandatory marking.
>> 
>> Thanks,
>> Rob
>> 
>> 
>> 
>> 
>> Andy
>> 
>>  
>>>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 13 Aug 2015 12:31:59 -0700

Hi,

IMO this is issue is closed.
I see no reason to re-open it.
YANG does not allow augments to add mandatory nodes.

Andy

On Thu, Aug 13, 2015 at 12:22 PM, Ladislav Lhotka <[email-masked]> wrote:

> Right. Another thing is that augment was IMO originally intended to allow
> for adding optional or vendor-specific parameters to a base data model.
> However,  as it turned out, it is in fact used as an essential tool for
> developing *base* data models in a modular fashion.
>
> I have also argued several times that a client cherry-picking modules
> advertised by the server is fundamentally unsafe - it may work but may also
> break things.
>
> >
> >>
> RR type it is acceptable to either not provide any extra RR specific config
> possible for the server to handle this scenario then the     mandatory
> child fields don't have to be mandatory either because some sensible
> default must exist.  This implies that all servers would likely reject the
> We tried to identify such situations but it is not that easy. I think the
> restriction should be removed and explain backward compatibility issues in
> 6087bis. Module authors then have to decide whether a certain node needs to
> be defined as mandatory.
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 13 Aug 2015 21:43:30 +0200

> On 13 Aug 2015, at 21:31, Andy Bierman <[email-masked]> wrote:
> 
> Hi,
> 

I strongly disagree with this attitude, this is a normal IETF procedure. Things can be changed even during WGLC.

Virtual interims aren’t good for discussing non-trivial technical issues.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Thu, 13 Aug 2015 13:15:09 -0700

> Virtual interims aren’t good for discussing non-trivial technical issues.
I am not hearing any new arguments for changing this rule for augments.
It's up to the co-chairs whether they want to re-open this issue.

Andy

> > >> I still don't see how a P-container really solves the problem since
> any child mandatory nodes aren't really mandatory, or at least not in the
> > Right. Another thing is that augment was IMO originally intended to
> allow for adding optional or vendor-specific parameters to a base data
> model. However,  as it turned out, it is in fact used as an essential tool
> for developing *base* data models in a modular fashion.
> >
> given RR type it is acceptable to either not provide any extra RR specific
> some fields must always be provided, and others can be left out.  I.e. the
> > > Yes, but in Lada's example, the P-container doesn't really help
> anyone, since the server has to now handle the case that the RR-type has
> been specified but the corresponding P-container isn't present.  If it is
> > > As I see it, having a P-container here only protects a old client in
> the scenario that it was mis-configured in the first place, i.e. using a
> > We tried to identify such situations but it is not that easy. I think
> the restriction should be removed and explain backward compatibility issues
> in 6087bis. Module authors then have to decide whether a certain node needs
> to be defined as mandatory.
> >

---

From: Nadeau Thomas <[email-masked]>
Date: Thu, 13 Aug 2015 16:24:03 -0400

Speaking as co-chair:

	Hold on a minute.  As a point of order, our process with the Yang 1.1 issue processing has been very clear: we debate/discuss the issues on the interim calls in order, then propose the outcome that the design team came up with to the list each time. There is a “last call” period when debate/discussion with the NETMOD WG can take place after which the issue is closed and will 
not be debated again.

	Looking at this issue, it was discussed/debated and is now closed as of 2015-04-17.

http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-27

	Let us please stop debating this issue as it is closed.

	—Tom

> On Aug 13, 2015:3:43 PM, at 3:43 PM, Ladislav Lhotka <[email-masked]> wrote:
> 
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 13 Aug 2015 22:25:14 +0200

> On 13 Aug 2015, at 22:15, Andy Bierman <[email-masked]> wrote:
> 
> 
> 

The argument isn’t new, I just hope to find more support for it. And the argument is: With the way how augments are used in existing modules, it is not reasonable to used restricted YANG inside them. And the p-container solves nothing.

Lada

---

From: heasley <[email-masked]>
Date: Fri, 14 Aug 2015 16:32:13 -0700

> > Virtual interims aren?t good for discussing non-trivial technical issues.
> >
> >

This might be ignorance of detail, but doesn't this approach essentially force 
vendors to publish [what i've been calling] enterprise yang models for models
that they might otherwise just augment to support proprietary features?

if so, what is the point of defining *any* models?

---

From: Andy Bierman <[email-masked]>
Date: Fri, 14 Aug 2015 16:40:07 -0700

On Fri, Aug 14, 2015 at 4:32 PM, heasley <[email-masked]> wrote:

> > > I strongly disagree with this attitude, this is a normal IETF
> procedure.
> > > Things can be changed even during WGLC.
> > >

The issue here is that augment cannot directly add mandatory nodes.
They must be inside a list or a P-container.

    augment /foo:bar {
       leaf NOT_ALLOWED {
          mandatory true;
          type string;
       }
    }

    augment /foo:bar {
       container THIS_IS_ALLOWED {
          presence "new feature enabled";
          leaf THIS_IS_NOW_ALLOWED {
             mandatory true;
             type string;
          }
       }
    }

IMO this extra P-container is not a burden and it serves
an important purpose, which is to allow clients that
know the base structure to keep working.  Otherwise
when they create or replace the node, the edit will be
rejected because a mandatory node is missing.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 15 Aug 2015 09:26:08 +0200

> On 15 Aug 2015, at 01:40, Andy Bierman <[email-masked]> wrote:
> 
> 
> 

In both examples, the augments are applied inside a list, only the list is defined in the module that’s being augmented. 

> know the base structure to keep working.  Otherwise

But it also allows clients to create invalid DNS resource records in my example, or invalid if:interface entries in Rob’s example, because the p-container can be omitted entirely.

> rejected because a mandatory node is missing.

The client has no good reason to create list entries with types that it doesn’t support. 

My workaround in the dns-zones module is a must statement in the “rdata” list that requires the p-container to be always present:

    must “count(*) > 2”;

This is a tricky and brittle solution though.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 15 Aug 2015 10:35:52 +0200

> On 15 Aug 2015, at 01:32, heasley <[email-masked]> wrote:
> 

I think there are two aspects here. On the one hand, we probably don’t want vendors to augment a standard interface type with mandatory parameters because this breaks interoperability and creates a silo.

On the other hand, vendors (or anybody) can create a new interface type (or derive its identity from a standard type), and then they should be able to use full power of YANG to specify schema constraints including mandatory parameters where necessary.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 18 Aug 2015 13:09:19 +0200 (CEST)

Hi,

>     container rdata {            // <=================

Working with what we currently have, I think this would look a bit
better if you instead did:

  augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" {
    when "derived-from-or-self(../dnsz:type,'iana-dns-parameters',"
       + "'TLSA')";
    container tlsa { // name change
        presence "TLSA data";
        leaf certificate-usage {
            mandatory true;
            ...
  
I think the model itself is quite ok with this design, but the
instance data contains the type information encoded twice; once in the
the 'type' leaf and once in the container 'tlsa'.  Since the 'type'
leaf is part of the key, it cannot easily be removed.

As for this issue in general, I think we all agreed that it would be
nice if we could allow such data to be mandatory, but noone came up
with any proposal for how to do this.  The "safe" use case we
discussed was when the identity was defined in the same module as the
augment, but that is not the case in you module, where all identities
are defined in a central module.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 18 Aug 2015 14:11:32 +0200

> On 18 Aug 2015, at 13:09, Martin Bjorklund <[email-masked]> wrote:
> 
> Hi,
> 
>            …

Right, using the same name for the presence container won’t work if rdata for multiple rr types are defined in the same module.

But the main problem still remains: container “tlsa” needn’t be present, which leads to an invalid resource record. The server would have no choice but reject such configuration. I don’t get how this helps old clients.

> are defined in a central module.

… as it is with interface types.

I think it would be better to remove the restriction altogether. If a parameter is mandatory by its substance, it should be defined as mandatory in the data model. And if somebody wants to break old (or someone else’s) clients, there are other ways for achieving it.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 18 Aug 2015 15:42:23 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> Right, using the same name for the presence container won’t work if
> rdata for multiple rr types are defined in the same module.
> 
> But the main problem still remains: container “tlsa” needn’t be
> present, which leads to an invalid resource record. The server would
> have no choice but reject such configuration. I don’t get how this
> helps old clients.

Well, if it doesn't make any sense to configure an rrset of e.g. type
'TLSA' without the 'tlsa' container, I don't expect such clients to be
deployed in the network.

The rule about not augmenting mandatory nodes is there to protect
properly functioning clients.  For example, suppose you have your tlsa
module and a client that knows this and works well.  Then some vendor
writes a new module that also augments some mandatory nodes when the
type is 'TLSA'.  Then the client that used to work doesn't work
anymore.

/martin

> I think it would be better to remove the restriction altogether. If a
> parameter is mandatory by its substance, it should be defined as
> mandatory in the data model. And if somebody wants to break old (or
> someone else’s) clients, there are other ways for achieving it.
> 
> Lada
> 
> > 
> > 
> > /martin
> 
> --

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 18 Aug 2015 16:32:39 +0200

> On 18 Aug 2015, at 15:42, Martin Bjorklund <[email-masked]> wrote:
> 

Then it would be better at least to define TLSA identity together with rdata for TLSA rr, rather than having all identities defined in one place.

> type is 'TLSA'.  Then the client that used to work doesn't work

It seems we all agree that, using Randy’s terminology, subclassing augments are OK. We only can’t reliably identify such augments because YANG uses “poor man’s” subclassing.

You are arguing against mandatory extension augments but then:

1. A standard module might need to be patched by adding a mandatory parameter, which is currently impossible via both augment and module update,

2. The rogue vendor can use a must statement to achieve the same effect (or perhaps just state it in a description?). What’s important    is whether the server that advertises such an extension rejects a configuration where the new parameter is missing or not.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 18 Aug 2015 16:35:49 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> Then it would be better at least to define TLSA identity together with
> rdata for TLSA rr, rather than having all identities defined in one
> place.

Yes, and *maybe* it would be possible to come up with either text that
allows such an augmentation, or a new YANG statement to handle this
situation.

/martin

> It seems we all agree that, using Randy’s terminology, subclassing
> augments are OK. We only can’t reliably identify such augments because
> YANG uses “poor man’s” subclassing.
> 
> 1. A standard module might need to be patched by adding a mandatory
> parameter, which is currently impossible via both augment and module
> update,
> 
> 2. The rogue vendor can use a must statement to achieve the same
> effect (or perhaps just state it in a description?). What’s important
> is whether the server that advertises such an extension rejects a
> configuration where the new parameter is missing or not.
> 
> Lada
> 
> > 
> > 
> > /martin
> > 
> > 
> > 
> > 
> >> 
> >>>

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 24 Aug 2015 18:35:07 +0200

Ladislav Lhotka <[email-masked]> writes:
Hi,

> configuration where the new parameter is missing or not.

As a follow-up to the discussion during the interim call, here is an
example of a module snippet that augments "ietf-interfaces" with a
mandatory node:

import ietf-interfaces {
  prefix if;
}

augment "/if:interfaces" {
  container top {
    must "foo";
    leaf accept {
      type boolean;
      default true;
    }
    leaf foo {
      type empty;
    }
  }
}

If a server advertises this module along with "ietf-interfaces", then,
according to the rules of YANG 1.0, a datastore without the "foo"
instance is invalid.

Therefore, I think it really makes no practical sense to insist on
restricting augments to non-mandatory nodes.

Lada

---

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

> according to the rules of YANG 1.0, a datastore without the "foo"

   When a datastore is validated, all "must" constraints are
   conceptually evaluated once for each data node in the data tree, and
   for all leafs with default values in use (see Section 7.6.1).  If a
   data node does not exist in the data tree, and it does not have a
   default value, its "must" statements are not evaluated.

According to sec. 7.5.3, para 2, the must statement is not evaluated
for a missing NP container because it has no default-stmt.

> restricting augments to non-mandatory nodes.
It does because the current YANG conformance model does not
require the augmenting modules to be present. They are considered
optional so a client can be written to work with the base module
and not break every time a new augments is added.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 24 Aug 2015 19:53:21 +0200

> On 24 Aug 2015, at 18:42, Andy Bierman <[email-masked]> wrote:
> 
> 
> 

OK, so the the must statement can be moved under “accept”:

must “../foo”;

In YANG 1.1, NP containers exist for validation purposes, see issue Y41.

> and not break every time a new augments is added.

No text in 6020(bis) supports this interpretation.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 24 Aug 2015 11:17:12 -0700

> In YANG 1.1, NP containers exist for validation purposes, see issue Y41.

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.

As long as there is no server requirement to implement 2 modules together,
then YANG must allow for the possibility that the augmenting module
in not present.  Therefore a client which only
supports the base module is valid.

IMO this issue is closed.
The WG decided the only problem to solve with YANG conformance
is import-by-revision.  This is a conformance issue.  You want to
force the old client to support every augmenting module a server
may add to this base module.

Current YANG conformance rules do not work this way for good reason.

> No text in 6020(bis) supports this interpretation.
Show me the text that says if a server implements a module
it must also implement other modules that augment this module.
There is none.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 24 Aug 2015 20:44:29 +0200

> On 24 Aug 2015, at 20:17, Andy Bierman <[email-masked]> wrote:
> 
> 
> 

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 must also implement other modules that augment this module.

Well, if the server *advertises* such a module, then I guess it has to implement it.

I think it comes down to the definition of the “data model”, which is the substance of the client-server contract. It looks like it needs to be clarified, if we can disagree on such a fundamental thing.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 24 Aug 2015 21:01:09 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> There are sections on conformance and conformance announcement, and
> they say nothing like this.

No Andy is correct, except that if module A augments module B, then a
server that implements A MUST also implement B.

But I don't understand what this has to do with the issue.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 24 Aug 2015 21:13:13 +0200

> On 24 Aug 2015, at 21:01, Martin Bjorklund <[email-masked]> wrote:
> 

Of course, there is no way how to learn about all modules in the known universe that augment B, but I’ve been always talking about the situation where the server advertises *both* A and B. 

I hope we all agree that the server then does implement A and B, and both modules are part of the data model. 

> But I don't understand what this has to do with the issue.

Right, so what’s your answer to my question? Is the datastore where “foo” is missing valid or not?

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 24 Aug 2015 12:24:47 -0700

> But I don't understand what this has to do with the issue.

I think Lada is saying it is OK to add mandatory nodes in module A
because the client should know about module A.

The YANG conformance model does not at all support the concept
of a placeholder subtree that will be augmented by modules,
based on device capabilities like interface types supported).

In this design pattern, there is nothing really to implement in
the base module.  In this design pattern it is very restrictive
to only define optional nodes.  It is clear that "augment+when"
is a powerful tool that is diminished if mandatory nodes
cannot be added.

The problem is there is no cookie-cutter formula for a safe "when"
statement.  The common use-case is pick-an-identity from iana-if-type.
Clearly we do not intend for a server to support every interface type
just because it advertises the iana-if-types module.  Also, we
cannot assume the client knows about module A just because it
knows about iana-if-type.

IMO YANG Packages could at least convey the requirement
that N of M augmenting modules MUST be present if
the augmented module is supported.  But it does not
solve the problem of breaking old clients because new mandatory
nodes are added to a new revision of a server.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 24 Aug 2015 21:25:53 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> Of course, there is no way how to learn about all modules in the known
> universe that augment B, but I’ve been always talking about the
> situation where the server advertises *both* A and B.
> 

The data model was:

and with current 6020bis, which includes Y41-01, this indeed has the
same effect as augmenting a mandatory node.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 25 Aug 2015 10:12:37 +0200

> knows about iana-if-type.

It might help if we go back to the issues list and the meeting
documentation. It seems we are redoing a discussion we already had.

  2014-07-09 meeting action: There is agreement that the current text
             is overly restrictive. The proposal is to add general
             guiding rules that backwards compatibility needs to be
             maintained. Lets see whether someone can write more
             concrete rules when mandatory nodes in augment are
             allowed.

  2015-03-23 ietf 92 meeting: The opinion after discussion at the meeting
             was leaning towards Y26-02.

See the meeting minutes and recordings for more details. Are there any
fundamentally new insights that should change the conclusion of the
IETF 92 meeting (which was verified on the mailing list in April)?
Has someone meanwhile managed to produce text that clearly defines
when mandatory nodes in augments are 'safe' in the sense that they do
not break clients that are not aware of the augmentation? If not, we
should perhaps not waste cycles rehashing an old and closed issue.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>