Hi - > From: Andy Bierman > Sent: Aug 15, 2015 10:55 AM > To: Randy Presuhn > Cc: "[email protected]" > 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 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
