Andy Bierman <[email protected]> wrote: > On Thu, Apr 7, 2016 at 5:33 AM, Martin Bjorklund <[email protected]> wrote: > > > Andy Bierman <[email protected]> wrote: > > > On Thu, Apr 7, 2016 at 3:45 AM, Juergen Schoenwaelder < > > > [email protected]> wrote: > > > > > > > On Thu, Apr 07, 2016 at 08:55:19AM +0000, Scharf, Michael (Nokia - DE) > > > > wrote: > > > > > > I come at this from the classification angle, so my interest is if > > the > > > > assumption that > > > > > > a YANG model can only be classified as a network service model XOR > > a > > > > network device model > > > > > > according to the definitions in > > > > draft-ietf-netmod-yang-model-classification (sections 2.1 > > > > > > and 2.2). Based on this discussion I take it that some models are > > > > intended to be able to > > > > > > serve in both roles. And we should make sure that it’s supported in > > > > our catalog structure. > > > > > > > > > > Regarding the XOR assumption for classification: > > > > > > > > > > You may also want to think about YANG models that are NEITHER device > > NOR > > > > service models. For instance, what about RFC 6991? And I think other, > > more > > > > technical models presented this week may fall into a similar category > > > > ("generic"?). > > > > > > > > > > > > > RFC 6991 is not really defining a data model, while ietf-yang-types > > > > and ietf-inet-types are both YANG modules they do not define any data > > > > nodes that can be implemented. Lets look at RFC 6020bis: > > > > > > > > o data model: A data model describes how data is represented and > > > > accessed. > > > > > > > > Anyway, the point is that RFC 6991 do not define any data nodes and > > > > hence nothing that can be accessed. Perhaps it helps to import > > > > terminology into the model classification document and to be explicit > > > > that not all YANG modules define YANG data models. > > > > > > > > > > > > > > I brought this issue up for YANG 1.1 but there was no interest > > > or agreement that there is any problem or confusion. > > > > > > http://www.netconfcentral.org/modulereport/iana-crypt-hash > > > > > > Consider iana-crypt-hash that only contains 1 typedef and 3 features > > > that relate to implementation of that typedef. According to YANG 1.1 > > > and the YANG library, a server implement MUST NOT claim it > > > implements iana-crypt-hash. Instead the server must say "I import > > > this module, but implement the features". How can one implement > > > something that is supposedly only imported? Very confusing. > > > > ietf-yang-library and 6020bis(*) uses the phrase "supported > > features". So, a server can advertise a module as imported, and list > > the supported features. > > > > (*) 6020bis actually uses the phrase "implement a feature" in one > > sentence (last sentence in 7.20.1). This should probably be changed > > to "support a feature" in order to avoid confusion. > > > > > > > How does one support a feature without implementing it? > This terminology is inconsistent and confusing.
The feature itself isn't very interesting. If a server supports feature A, it implements nodes that have if-feature "A" statements. /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
