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

From: Randy Presuhn <[email-masked]>
Date: Sun, 16 Aug 2015 15:45:01 -0700 (GMT-07:00)

Hi -

>From: Ladislav Lhotka <[email-masked]>
>Sent: Aug 16, 2015 12:52 AM
>To: Randy Presuhn <[email-masked]>, "[email-masked]" <[email-masked]>
>Subject: Re: [netmod] Constraint on mandatory on nodes as part of augmentation in RFC6020bis
...
>> 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.
>
>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.

In the CMIP world, GDMO has very strict rules for maintaining
compatibility, in some regards even stricter than those of SNMP
SMI.  But the CMIP environment is explicitly object-oriented,
and relies heavily on inheritance and notions of class compatibility
through explicitly shared semantics both at the level of class
definitions and of the bits and pieces used to compose class definitions.

...
>> 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.
>
>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.

It's pretty straightforward in the case where clients always request
creation of well-formed new instances (pardon my CMIP-ish vocabulary)
and supplies a coherent set of augmenting bits.  A challenge is
for client or server code to know from the Yang definition whether
there are constraints on the set of augments that may appear within
a given instance (recognizing that the actual set that appears
may differ from instance to instance within a given installation)
and to do so in such a way that doesn't torpedo vendor extensions.
The current discussion is looking to express "exactly one of set X"
where "X" is defined as the set of "subclassing" augmentations, but
does not include "extension" augmentations, and is complicated
by the fact that set X is open-ended.  Placeholder containers
for the subclassing augmentations are the beginning of a hack to
address this, growing out of a (perhaps dimly) recognized need to
use augments to do two very different things, and that perhaps
a structural convention might be enough to spackle over the real
problem in modeling.

Randy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 17 Aug 2015 10:34:16 +0200

> does not include "extension" augmentations, and is complicated

Right, extension augmentations are a slightly different issue but IMO
they will be needed as well because we can't hope to have all modules
forever perfect as soon as they become RFCs, so some amount of patching
will be necessary, and this may include adding mandatory nodes. However,
the augmentation rules and also the update rules in sec. 10 of 6020bis
effectively prevent such patches or updates.

Then there are IMO two alternatives:

- some schema constraints will only be coded in server's backend and won't
  appear in the data model, or

- a completely new module has to be started that will replace the original
  one.

Both alternatives can hardly be considered backward-compatible or more
gentle to old clients.

> a structural convention might be enough to spackle over the real

Yes, that's my view. The pattern introduced in RFC 7223 (list + type and
augment + when based on type), combined with the new XPath functions and
multiple inheritance of identities in YANG 1.1, is able to simulate object
orientation, and I don't think it is a big hack.

Lada

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

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