Juergen Schoenwaelder <[email protected]> writes: > On Sat, Aug 01, 2015 at 04:51:28PM +0000, Acee Lindem (acee) wrote: >> >> Section 1.1 in >> https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt >> lists the goals of a generic model structure that will accommodate most >> modern network devices. I guess you don’t agree that these are desirable? > > o a common schema to access data related to all aspects of a device > > This is why we produce standards. They are a common schema. > > o an extensible structure that makes it clear where additional > models or data should be fit (e.g., using YANG augmentation or > imports) > > This is why we have /interfaces. Interface related stuff goes here. > It is easy to reference.
But it is only suitable for a single device with its set of interfaces. So the ietf-interfaces module isn't broken but doesn't allow for typical generalizations, e.g. a device comprising a number of virtual devices, each with its own set of interfaces. Lada > > o a place for including metadata that provides useful information > about the corresponding individual models, such as which > organization provides them, which vendors support them, or which > version of the model is deployed > > Not really sure what this means. YANG modules have meta data. A > NETCONF or RESTCONF server exposes which data models it implements. A > list of which vendor supports what is clearly outside the scope of > IETF work. > > o a common infrastructure model layer on which higher layer service > models can be built, for example by specifying which models are > needed to provide the service > > Not sure what this means exactly but I also do not see why any of the > existing RFCs breaks this. > > o an ability to express an instance of the structure consisting of > models that have been validated to work together (i.e., with > information about sources of the models, their versions, etc.), so > that operators can easily identify a set of models that is known > to be mutually consistent > > Not sure what this means exactly but YANG modules published by the > IETF are supposed to work together. YANG 1.1 has even clearer rules > what imports mean etc. > > Bottom line is that I do not get out of these bullets what is _broken_ > with the existing RFCs. I like to see text of the sort > > - RFC 7223 is broken because ... > - RFC 7277 is broken because ... > [...] > > This text is not in section 1.1 as far as I can tell. > > Bottom line is that I do not understand why /interfaces is broken such > that this needs to be redone while /device/interfaces is golden. What do > we do if in two years some group of people find /device/network/interfaces > a brilliant idea? > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > > _______________________________________________ > 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
