Hi - >From: Ladislav Lhotka <[email protected]> >Sent: Aug 16, 2015 12:52 AM >To: Randy Presuhn <[email protected]>, "[email protected]" ><[email protected]> >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 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
