Randy Presuhn <[email protected]> writes: > 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
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. > 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. 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 protected] > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
