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