On Thu, Apr 7, 2016 at 7:21 AM, Martin Bjorklund <m...@tail-f.com> wrote:
> Andy Bierman <a...@yumaworks.com> wrote:
> > On Thu, Apr 7, 2016 at 5:55 AM, Martin Bjorklund <m...@tail-f.com> wrote:
> >
> > > Andy Bierman <a...@yumaworks.com> wrote:
> > > > On Thu, Apr 7, 2016 at 5:33 AM, Martin Bjorklund <m...@tail-f.com>
> wrote:
> > > >
> > > > > Andy Bierman <a...@yumaworks.com> wrote:
> > > > > > On Thu, Apr 7, 2016 at 3:45 AM, Juergen Schoenwaelder <
> > > > > > j.schoenwael...@jacobs-university.de> 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.
>
> Sure. But the confusion comes from the term "implement" which in
> ietf-yang-library means "implement data nodes". When someone also say
> "implement a feature", it might be confusing. So I simply propose
> that we stick to the phrase "support a feature", to avoid the
> confusion. Do you have some other idea?
>
>
not really. We already spent a lot of time on the 'conformance-type' leaf
and could not come up with consensus on something else.
Supported feature will have to be good enough. It also applies to
if-feature
on an identity-stmt, which is only indirectly implemented.
>
> /martin
>
Andy
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
