On Thu, Apr 7, 2016 at 5:55 AM, Martin Bjorklund <[email protected]> wrote:
> 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. > > > Except this is not at all how features are used in iana-crypt-hash.yang. The features are clearly related to implementation of any leaf or leaf-list that uses this typedef. Perhaps this is an exception and we should have never defined those features in the first place. > /martin > Andy
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
