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

From: Randy Presuhn <[email-masked]>
Date: Sat, 15 Aug 2015 12:20:59 -0700 (GMT-07:00)

Hi -

> From: Andy Bierman
> Sent: Aug 15, 2015 10:55 AM
> To: Randy Presuhn
> Cc: "[email-masked]"
> Subject: Re: [netmod] Constraint on mandatory on nodes as part of augmentation in RFC6020bis
...
> I have been trying to change the meta-model (with YANG packages). But that
> does not fix the problem here -- the notion of what is mandatory for a given
> data structure can change over time.  Yet YANG absolutely does not allow that
> to happen.  It doesn't matter whether 1 module, 2 modules, or submodules are
> used.  All mandatory data must be defined in the first release.

It seems to be a little bit worse than that.  It sounds like at least some
folks would like to be able to define a superclass as an abstract (non-
instantiable) class - that is, it could *only* be instantiated with some
combination of augmentations.  I say it's worse because they appear to
have a use case which is incompatible with how augment was intended to
work.

> SNMP never had this problem because a client can just ignore new monitoring
> data it receives.  A NETCONF client cannot create or replace configuration
> data that has unknown mandatory nodes.

I think a better analogy would be to how row creation works in SNMP, specifically
with the RowStatus textual convention.  The constraints of the SMI force the
modeler using AUGMENTS to provide DEFAULTs or DESCRIPTION text to provide
the correct values in the AUGMENTS portions of a row, and provide no ability
to select *which* of multiple AUGMENTS to instantiate.  Whatever an implementation
supports MUST be instantiated in a 1:1 relationship with the rows of the
base MIB module.  Lada's example needs something substantially more powerful,
and would not be a good candidate for AUGMENTS in SMI.  One question is
whether Yang's augment construct is (or can be) the right tool for the job,
but another important question is whether this particular type of constraint
needs to be represented in machine-interpetable form, or whether this falls in
with the host of other constraints on configurations that are only specified
in human-readable form, and require hand-coding on the client, server, or both.

> In your analogy, there is an assumed super-class, and the mandatory augments
> is creating a new sub-class.

And in some cases, there seems to be an assumption that for *some* use cases
instantiating *just* the superclass without any extension is an invalid
configuration.

> The problem is the datai s all mixed together so a client using the old
> derived class needsto be insulated from the new derived class (w/ new
> mandatory nodes).

Alternatively, one might say that another way of looking at the problem
is that the client cannot distinguish an attempt to instantiate the
superclass (which by itself may be operationally forbidden) from a
mal-formed attempt to instantiate the subclass.

> The problem is specifying the rules for insulating the old client.
> One design pattern we have come up with assumes that the old client
> does not know about new identityref values, so it won't try to create
> or replace an entry using a new identity.

This assumes that creating an un-augmented instance was *ever* a meaningful
thing to do.  I think part of the challenge here is that given the tools
we currently have, the alternative is create a bunch of data definitions
(classes) that look suspisciously similar, but with no formal representation
of their common heritage.

Randy

---

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

On Sat, Aug 15, 2015 at 12:20 PM, Randy Presuhn <
[email-masked]> wrote:

> ......
This is the the core issue.
YANG has no way to describe the design pattern Lada wants to use.

How about if MUST is changed to SHOULD?
Plus add some text saying new mandatory nodes can break
old clients using the parent data structure,
so care should be taken...etc.

It will be up to vendors to keep it sane,  or pay the penalty with customers
for breaking their applications.

Randy

Andy

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

---

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

Randy Presuhn <[email-masked]> writes:

> folks would like to be able to define a superclass as an abstract
> (non-instantiable) class - that is, it could *only* be instantiated with some

It's no more at "would like" stage - "ietf-interfaces" and
"ietf-routing" are designed this way.

> have a use case which is incompatible with how augment was intended to

Yes, I think so. The "augment" mechanism wasn't probably designed for
such a heavy lifting. I think though it works fine - in fact, it is IMO
an important mechanism that makes a gradual development of a large
number of modules possible.

> in human-readable form, and require hand-coding on the client, server,

I fully agree, backward compatibility is an important principle for data
model design, but it shouldn't be hardwired in the data modelling
language. No schema language I am aware of has such rules.

> instantiating *just* the superclass without any extension is an invalid

I think it is up to the server data model designer to select a set of
modules that make sense for the particular device. Packages can help
but I think it's not that difficult to perform the selection even now.

Lada

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