Subject: [netmod] Constraint on mandatory on nodes as part of augmentation in RFC6020bis

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Sat, 15 Aug 2015 14:50:06 +0000

Team,

Section 7.17 The augment statement has verbiage
If the target node is in another module, then nodes added by the
augmentation MUST NOT be mandatory nodes (see Section 3.1).

We are seeing situations where this constraint is invalid - Situations where a standard builds on another standard and makes parts of the new standard mandatory.

It seems this was an issue in the past where the decision was to get around this statement with a presence container.

Since 6020bis is in progress - would it be possible to simply remove this phrase and allow mandatory nodes as part of the augmentation so we don't have to have this artificial workaround?

Thanks,
Tim

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 15 Aug 2015 17:25:18 +0200

> On 15 Aug 2015, at 16:50, Carey, Timothy (Timothy) <[email-masked]> wrote:
> 
> Team,
>  
>  
> We are seeing situations where this constraint is invalid – Situations where a standard builds on another standard and makes parts of the new standard mandatory.
>  
> Since 6020bis is in progress – would it be possible to simply remove this phrase and allow mandatory nodes as part of the augmentation so we don’t have to have this artificial workaround?

This is exactly what’s currently being discussed in this thread:

https://mailarchive.ietf.org/arch/search/?email_list=netmod&gbt=1&index=ES2ogm1wabzZVIIBlrRor0fn3rk

Lada

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

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

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Sat, 15 Aug 2015 15:39:27 +0000

Lada,

Yes sorry - I just saw that thread after I submitted mine.

BR,
Tim
-----Original Message-----
From: Ladislav Lhotka [mailto:[email-masked]] 
Sent: Saturday, August 15, 2015 10:25 AM
To: Carey, Timothy (Timothy)
Cc: [email-masked]
Subject: Re: [netmod] Constraint on mandatory on nodes as part of augmentation in RFC6020bis

> Section 7.17 The augment statement has verbiage If the target node is 
> in another module, then nodes added by the augmentation MUST NOT be 
> mandatory nodes (see Section 3.1).
>  
>  

Lada

---

From: Andy Bierman <[email-masked]>
Date: Sat, 15 Aug 2015 09:00:23 -0700

Hi,

If you are using mandatory nodes in augment, it is because you expect
that all clients will know and implement both modules.
However YANG has no way to require that.
A server is NEVER required to implement the augmenting module.

It doesn't really matter that you are writing these illegal YANG modules
all at once. A server is not required to implement them all at once,
or all of them ever.

It is rather naive to think that the client must understand every YANG
module
implemented on a server.  Even if this were useful, the client will
certainly
not support modules written after the client code was released.

You should be using submodules (written all at once) if you want
to augment with mandatory nodes.

Andy

On Sat, Aug 15, 2015 at 8:39 AM, Carey, Timothy (Timothy) <
[email-masked]> wrote:

> > We are seeing situations where this constraint is invalid – Situations
> where a standard builds on another standard and makes parts of the new
> standard mandatory.
> >
> > It seems this was an issue in the past where the decision was to get
> around this statement with a presence container.
> >
> > Since 6020bis is in progress – would it be possible to simply remove
> this phrase and allow mandatory nodes as part of the augmentation so we
> don’t have to have this artificial workaround?
>

---

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

> On 15 Aug 2015, at 18:00, Andy Bierman <[email-masked]> wrote:
> 
> Hi,
> 

Are you saying that a server isn’t required to implement modules that it advertises?

There is no text in 6020(bis) supporting this theory. An augmenting module is an integral part of the data model as any other.  

> It is rather naive to think that the client must understand every YANG module
> implemented on a server.  Even if this were useful, the client will certainly

Such a client is unsafe because the modules that the client ignores may imply some important semantics. YANG modules are not perfectly isolated from each other, and a client may break things if it doesn’t understand the interactions. And again, I am not aware of any text in 6020 supporting such cherry-picking clients.

> to augment with mandatory nodes.

In many use cases this is impossible - e.g. for interface types.

Lada

> 
> Andy
> 
> 
> 
> 
> On Sat, Aug 15, 2015 at 8:39 AM, Carey, Timothy (Timothy) <[email-masked]> wrote:
> Lada,
>

---

From: Andy Bierman <[email-masked]>
Date: Sat, 15 Aug 2015 10:37:22 -0700

> Are you saying that a server isn’t required to implement modules that it

Of course not.
The server is allowed to implement the base module without the augmenting
module.
It is not required to advertise the augmenting module.

A system working this way cannot just add a module later that breaks old
clients.
The RFC can hand-wave around this, but the tech-support team will still get
calls
if already deployed code stops working.

I suggested a solution called YANG packages. If multiple YANG modules are
required to be used together, then the current YANG conformance model is
broken.

>
> There is no text in 6020(bis) supporting this theory. An augmenting module
> is an integral part of the data model as any other.
>
> >
> Such a client is unsafe because the modules that the client ignores may
> imply some important semantics. YANG modules are not perfectly isolated
> from each other, and a client may break things if it doesn’t understand the
> interactions. And again, I am not aware of any text in 6020 supporting such
> cherry-picking clients.
>
>
There is no text that says if  a base module is implemented,
then some other modules that augment that module must also be implemented.
It is not practical to re-implement a client app every time a new module is
added.

If you don't like how YANG conformance works then fix it.
Just breaking old clients and expecting them to re-code constantly
to keep up with every server release is not a solution.

> In many use cases this is impossible - e.g. for interface types.

There are no augments in the interface types module

Andy

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Sat, 15 Aug 2015 23:58:42 +0000

Andy,

The example we have is a module that we are standardizing that is augmenting another standards organization module (e.g., RFC 7223). We didn’t develop the module but we want to reuse the good work of other bodies as much as possible. So using sub-modules doesn’t seem feasible as the models are already published as a module.

These new modules are indeed standardized so the client and server know the specification and the ‘contract’ and the client interacts with the server knowing how to manage the server with this module name.

Indeed we look at backward compatibility within the context of the module when we revise the module for the very reason you suggest. We don’t want to break old clients. I just don’t think that is valid for the first revision of a module.

BR,
Tim

From: Andy Bierman [mailto:[email-masked]]
Sent: Saturday, August 15, 2015 12:37 PM
To: Ladislav Lhotka
Cc: Carey, Timothy (Timothy); [email-masked]
Subject: Re: [netmod] Constraint on mandatory on nodes as part of augmentation in RFC6020bis

On Sat, Aug 15, 2015 at 10:10 AM, Ladislav Lhotka <[email-masked]<mailto:[email-masked]>> wrote:

> On 15 Aug 2015, at 18:00, Andy Bierman <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi,
>

Of course not.
The server is allowed to implement the base module without the augmenting module.
It is not required to advertise the augmenting module.

A system working this way cannot just add a module later that breaks old clients.
The RFC can hand-wave around this, but the tech-support team will still get calls
if already deployed code stops working.

I suggested a solution called YANG packages. If multiple YANG modules are
required to be used together, then the current YANG conformance model is broken.

There is no text that says if  a base module is implemented,
then some other modules that augment that module must also be implemented.
It is not practical to re-implement a client app every time a new module is added.

Lada

Andy

>
>
>
> On Sat, Aug 15, 2015 at 8:39 AM, Carey, Timothy (Timothy) <[email-masked]<mailto:[email-masked]>> wrote:
> Lada,
>
> From: Ladislav Lhotka [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: [email-masked]<mailto:[email-masked]>
> > On 15 Aug 2015, at 16:50, Carey, Timothy (Timothy) <[email-masked]<mailto:[email-masked]>> wrote:
> >
> > Team,
> >
> >
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: Andy Bierman <[email-masked]>
Date: Sat, 15 Aug 2015 17:33:29 -0700

On Sat, Aug 15, 2015 at 4:58 PM, Carey, Timothy (Timothy) <
[email-masked]> wrote:

> Andy,
>
>
>
> The example we have is a module that we are standardizing that is
> augmenting another standards organization module (e.g., RFC 7223). We
> didn’t develop the module but we want to reuse the good work of other
> bodies as much as possible. So using sub-modules doesn’t seem feasible as
> the models are already published as a module.
>
>
>
> These new modules are indeed standardized so the client and server know
> the specification and the ‘contract’ and the client interacts with the
> server knowing how to manage the server with this module name.
>
>
>
> Indeed we look at backward compatibility within the context of the module
> when we revise the module for the very reason you suggest. We don’t want to
> break old clients. I just don’t think that is valid for the first revision
> of a module.
>
>
>

Implementations of RFC 7223 don't know about your new module.
It is compatibility with that module that is the issue, not your new module.

Andy

>
>
> *From:* Andy Bierman [mailto:[email-masked]]
> *Sent:* Saturday, August 15, 2015 12:37 PM
> *To:* Ladislav Lhotka
> *Cc:* Carey, Timothy (Timothy); [email-masked]
> *Subject:* Re: [netmod] Constraint on mandatory on nodes as part of
> augmentation in RFC6020bis
>
>
>
>
>
>
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 16 Aug 2015 09:28:00 +0200

Andy Bierman <[email-masked]> writes:

> Of course not.  The server is allowed to implement the base module
> without the augmenting module.  It is not required to advertise the
> augmenting module.

Sure, but that's the point of the concept that was introduced in RFC
7223: there will be a (large) number of modules for different interface
types, all of them augmenting "ietf-interfaces". A server implementor
will choose a collection of these modules depending on what interface
types the device is expected to support. All these modules then become
part of the data model and are advertised by the server.

> I suggested a solution called YANG packages. If multiple YANG modules
> are required to be used together, then the current YANG conformance
> model is broken.

That's a different problem. It is true that modules like
"ietf-interfaces" or "ietf-routing" are pretty much useless without
other modules augmenting it, and I think this has to be clear to every
server implementor already now (otherwise our RFCs and I-Ds do a poor
job). Packages would formalize this information, which would of course
be useful, but it has nothing to do with mandatory nodes in augments:
even with packages, it will be possible for a server to support
"ietf-interfaces" with, e.g., "ietf-ethernet" in revision 1, and
"ietf-ethernet" + "ieee-802.1q" in revision 2.

The problem this thread is about is that "ieee-802.1q" might need some
parameters to be mandatory, such as the VLAN tag or reference to the
"base" physical interface. Without such parameters, the VLAN interface
is incomplete and has to be rejected by the server, but the data model
cannot express this condition because of the restriction on "augment"
contents.

> to keep up with every server release is not a solution.

Backward compatibility is important but it mustn't be an absolute
requirement. The client receives complete information about the server's
data model. If it doesn't understand parts of it, it may be a problem or
not, depending on what actions the client wants to perform.

> There are no augments in the interface types module

There are several examples in RFC 7223 that illustrate how
"ietf-interfaces" is supposed to be augmented.

Lada