Ladislav Lhotka <lho...@nic.cz> wrote:
> On Wed, 2018-05-02 at 09:16 +0200, Martin Bjorklund wrote:
> > Ladislav Lhotka <lho...@nic.cz> wrote:
> > > On Fri, 2018-04-27 at 12:19 +0100, Robert Wilton wrote:
> > > >
> > > > On 27/04/2018 12:03, Ladislav Lhotka wrote:
> > > > > On Fri, 2018-04-27 at 11:23 +0100, Robert Wilton wrote:
> > > > > > On 27/04/2018 11:03, Martin Bjorklund wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > Ladislav Lhotka <lho...@nic.cz> wrote:
> > > > > > > > On Thu, 2018-04-26 at 17:52 -0700, Andy Bierman wrote:
> > > > > > > > > On Wed, Apr 25, 2018 at 10:53 PM, Ladislav Lhotka
> > > > > > > > > <lho...@nic.cz
> > >
> > > > > > > > > wrote:
> > > > > > > > > > Ladislav Lhotka <lho...@nic.cz> writes:
> > > > > > > > > >
> > > > > > > > > > > On Wed, 2018-04-25 at 08:04 -0700, Andy Bierman wrote:
> > > > > > > > > > > > On Wed, Apr 25, 2018 at 7:05 AM, Ladislav Lhotka
> > > > > > > > > > > > <lhotka@n
> > ic.c
> > > > > > > > > > > > z>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > On Wed, 2018-04-25 at 15:55 +0200, Juergen
> > > > > > > > > > > > > Schoenwaelder
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > On Tue, Apr 24, 2018 at 04:36:01PM +0200, Martin
> > Bjorklund
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > Ladislav Lhotka <lho...@nic.cz> wrote:
> > > > > > > > > > > > > > > > Martin Bjorklund <m...@tail-f.com> writes:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I am not sure what this statement tells us re.
> > the
> > > > > > > > > > > > > > > > > issue
> > > > > > > > > > > > > > > > > in
> > > > > > > > > >
> > > > > > > > > > this
> > > > > > > > > > > > > email
> > > > > > > > > > > > > > > > > thread.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > It tells us that, in my view, the approach taken
> > in
> > > > > > > > > > > > > > > > this
> > > > > > > > > > > > > > > > document
> > > > > > > > > >
> > > > > > > > > > is a
> > > > > > > > > > > > > > > > bad idea.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Do you mean that the WG shoud drop this document?
> > And
> > > > > > > > > > > > > > > people that
> > > > > > > > > > > > > > > need yang-data should continue to use the version
> > > > > > > > > > > > > > > in
> > > > > > > > > > > > > > > 8040? Or that
> > > > > > > > > > > > > > > people that need yang-data do not have a valid use
> > case
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > they
> > > > > > > > > > > > > > > should do something else?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > One option is that people use yang-data as defined
> > > > > > > > > > > > > > in
> > RFC
> > > > > > > > > > > > > > 8040
> > > > > > > > > > > > > > until
> > > > > > > > > > > > >
> > > > > > > > > > > > > IMO, people should use plain YANG. With the new YANG
> > library
> > > > > > > > > > > > > it
> > > > > > > > > > > > > will be
> > > > > > > > > > > > > possible
> > > > > > > > > > > > > to confine such non-NM schemas in a special datastore
> > > > > > > > > > > > > so
> > > > > > > > > > > > > that
> > > > > > > > > > > > > the
> > > > > > > > > >
> > > > > > > > > > intention
> > > > > > > > > > > > > should be clear and multi-module schemas with all the
> > > > > > > > > > > > > additional
> > > > > > > > > > > > > data
> > > > > > > > > > > > > (versions,
> > > > > > > > > > > > > features, deviations) can be used.
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > I don't see how yang-data interferes with "plain YANG"
> > > > > > > > > > > > at
> > all.
> > > > > > > > > > > > It is for data that is not in scope for plain YANG.
> > > > > > > > > > >
> > > > > > > > > > > My question is why this extension is needed in the first
> > place.
> > > > > > > > > >
> > > > > > > > > > For example, RFC 8040 could have used two modules instead of
> > > > > > > > > > "ietf-restconf", one with the contents of grouping "errors"
> > and
> > > > > > > > > > the
> > > > > > > > > > other with the contents of grouping "restconf". No
> > > > > > > > > > extension.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > This is true. We used to do this before yang-data was
> > > > > > > > > available.
> > > > > > > >
> > > > > > > > If I remember correctly, the stuff was inside groupings that
> > > > > > > > were
> > not
> > > > > > > > used
> > > > > > > > anywhere.
> > > > > > >
> > > > > > > Which doesn't quite work, since no namespace is attached to the
> > nodes.
> > > > >
> > > > > Note that this is not what I was proposing. For RESTCONF errors, the
> > module
> > > > > I
> > > > > had in mind could be like this:
> > > > >
> > > > > module ietf-restconf-errors {
> > > > >
> > > > > container errors { // same content as in RFC 8040
> > > > > ...
> > > > > }
> > > > >
> > > > > ...
> > > > >
> > > > > }
> > > > >
> > > > > Please explain why this cannot serve the given purpose, apart from the
> > fact
> > > > > that
> > > > > it looks like configuration which it isn't - but this can be explained
> > in
> > > > > the
> > > > > module description.
> > > >
> > > > It is the "because it looks like configuration" that I don't like.
> > >
> > > IMO this won't change even if the same data is inside the "yang-data"
> > extension
> > > because RFC 7950 says in sec. 7.21.1:
> > >
> > > If the top node does not specify a "config" statement, the default is
> > "true".
> > >
> > > So even though the description of "yang-data" says that the "config"
> > statement
> > > is ignored if present, it doesn't mean that schema nodes lose the config
> > > property.
> >
> > No, this is not correct. 7.21.1 says:
> >
> > If "config" is not specified, the default is the same as the parent
> > schema node's "config" value.
>
> And also:
>
> If the top node does not specify a "config" statement, the default is
> "true".
>
> >
> > Note how it says *schema node*. Nodes in a grouping that don't have a
> > config statement don't have a config property. Also, the same text
> > about ignoring config is present for input/output/notfication.
> >
> > Nodes in a yang-data extension statement thus also do not have a
> > config value, since yang-data is not a data definition statement.
>
> Are you saying that a container inside yang-data doesn't define a schema node?
I mean that just like in groupings, nodes in yang-data don't have a
config property.
> > This is an argument *for* an extension statement. If you just define
> > special nodes as normal nodes with a special description statement,
> > you really break the rules for YANG.
>
> I wouldn't *define* the schema nodes as special, just the resulting schema may
> be used differently. This shouldn't matter as long as this data has nothing to
> do with NETCONF or RESTCONF.
>
> My main objections against yang-data are:
>
> - additional complexity
>
> - bad example (Need - or don't like - something in YANG? Just introduce an
> extension.)
extensions are *much* better than the alternative you propose (Need -
or don't like - something in YANG? Just document how you break the
rules in the description statement).
extensions have turned out to be really useful. I agree that you
need to be careful with what you do though.
/martin
>
> Lada
>
> >
> >
> > /martin
> >
> >
> >
> > > This may look like nitpicking but it illustrates the general problem: YANG
> > was
> > > designed for a very specific context and using it elsewhere requires
> > creative
> > > interpretation of its spec, with "yang-data" extension or without.
> > >
> > > >
> > > > If the server supports and advertises this module then it is reasonable
> > > > to expect that a client should be able to configure the errors
> > > > container, since it is configuration ...
> > >
> > > There is no point for the server to advertise it as a part of the standard
> > > datastores such as "intended". And in order to advertise it as a schema
> > > for
> > > error messages, it is IMO possible to use the trick that I suggested:
> > > define
> > a
> > > special datastore for it, such as "error-messages". So it will be the
> > datastore
> > > that enforces the desired semantics, and clients that support it can use
> > > it
> > in
> > > the intended way.
> > >
> > > >
> > > > At least marking it as config false would be slightly better.
> > > >
> > > > >
> > > > > With this module, one could validate error messages using generic YANG
> > tools
> > > > > etc.
> > > > >
> > > > > (I am not proposing to update RFC 8040, just using it as an example.)
> > > > >
> > > > > > OK. So, using plain groupings doesn't work.
> > > > > >
> > > > > > In cases where groupings are being used within a YANG defined RPC,
> > then
> > > > > > presumably they do work OK?
> > > > > >
> > > > > > Is the specific problem scenario where the data is external to YANG
> > > > > > defined RPCs, but yet it is still desirable to use a YANG schema and
> > one
> > > > > > of the associated YANG encodings to describe/encode the data?
> > > > > >
> > > > > >
> > > > > > > > > > What would be wrong with this solution? Instead, the reader
> > > > > > > > > > is
> > > > > > > > > > overwhelmed with the complexity of the "yang-data"
> > > > > > > > > > definition,
> > and
> > > > > > > > > > most
> > > > > > > > > > tools cannot process the module.
> > > > > > > > >
> > > > > > > > > There are tools that can use yang-data.
> > > > > > > > > Not all use-cases involve a server to query for a
> > > > > > > > > yang-library.
> > > > > > > >
> > > > > > > > Sure, but it is not necessary, I meant it just as an option.
> > > > > > > > Such
> > YANG
> > > > > > > > modules
> > > > > > > > can be passed straight to tools.
> > > > > > > >
> > > > > > > > > Offline tools need to know about the special data somehow.
> > > > > > > >
> > > > > > > > Why? Let's say I want the ascii tree, and pyang will be able to
> > > > > > > > generate
> > > > > > > > it. All
> > > > > > > > right, there will be "rw" labels that don't apply but it is not
> > > > > > > > a
> > big
> > > > > > > > deal.
> > > > > > > >
> > > > > > > > > The yang-data extension prevents data-def-stmts from being
> > treated
> > > > > > > > > as if they were configuration or operational data.
> > > > > > > >
> > > > > > > > This would be a problem if this yang-data is mixed with standard
> > data
> > > > > > > > in
> > > > > > > > the
> > > > > > > > same module. IMO this can be avoided, and then for it is
> > essentially
> > > > > > > > irrelevant
> > > > > > > > for tools whether it is normal data or not.
> > > > > > > >
> > > > > > > > > I agree with you that unconstrained use of yang-data is
> > questionable
> > > > > > > > > for a standard extension. The bar should be that all tools
> > > > > > > > > which
> > > > > > > > > choose
> > > > > > > > > to implement the extension should provide the user with the
> > > > > > > > > same
> > > > > > > > > behavior.
> > > > > > > > > Declaring that behavior out-of-scope does not help
> > interoperability
> > > > > > > > > at
> > > > > > > > > all.
> > > > > > > >
> > > > > > > > Yes, and so my proposal here is to silently misuse YANG somewhat
> > where
> > > > > > > > necessary
> > > > > > > > rather than spend cycles on a Standard Track document that
> > > > > > > > gives a
> > > > > > > > false
> > > > > > > > impression of a general solution.
> > > > > > >
> > > > > > > I am strongly opposed to this. IMO it is much better to put such
> > > > > > > structures in an extension, which tools that don't understand it
> > will
> > > > > > > ignore, than relying on description statements in normal data
> > > > > > > nodes,
> > > > > > > which no tool can understand without hard coding special cases.
> > > > > >
> > > > > > I'm also opposed to this.
> > > > > >
> > > > > > Stuff that looks like configuration should be configuration, and
> > > > > > stuff
> > > > > > that looks like state should be state. If this data is going to be
> > > > > > described in YANG then I think that there must be a programmatic way
> > to
> > > > > > indicate that the resultant schema is not configuration or
> > > > > > operational
> > > > > > state, but something else instead. An extension seems to achieve
> > this.
> > > > >
> > > > > YANG spec deals exclusively with configuration and state data, and
> > > > > using
> > its
> > > > > statements inside an extension doesn't make this basic fact go away.
> > > > > Specifying
> > > > > all necessary changes properly inside a description of an extension is
> > > > > simply
> > > > > impossible.
> > > >
> > > > If an implementation needs to support generating the error messages
> > > > then
> > > > they can support the yang-data extension if they want (or just hard
> > > > code
> > > > what they expect to receive).
> > >
> > > Or support the "error-messages" datastore, see above.
> > >
> > > Lada
> > >
> > > >
> > > > Otherwise, devices can also ignore the yang-data extension and it
> > > > doesn't seem to do any harm since its doesn't change the behaviour in
> > > > any way.
> > > >
> > > > Thanks,
> > > > Rob
> > > >
> > > >
> > > > >
> > > > > Lada
> > > > >
> > > > > > Thanks,
> > > > > > Rob
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > > It would be great to remove NETCONF specifics from YANG and I'd
> > > > > > > > be
> > > > > > > > willing
> > > > > > > > to
> > > > > > > > contribute to this work.
> > > > > > >
> > > > > > > This is a different topic though.
> > > > > > >
> > > > > > >
> > > > > > > /martin
> > > > > > >
> > > > > > >
> > > > > > > > Lada
> > > > > > > >
> > > > > > > > > > Lada
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Andy
> > > > > > > > >
> > > > > > > > > > > > A plain client can ignore yang-data and not affect and
> > RPC,
> > > > > > > > > > > > notification,
> > > > > > > > > >
> > > > > > > > > > or
> > > > > > > > > > > > data
> > > > > > > > > > > > definitions in plain YANG.
> > > > > > > > > > >
> > > > > > > > > > > A plain (NC/RC) client should never see such data even if
> > > > > > > > > > > it
> > is
> > > > > > > > > > > not
> > > > > > > > > >
> > > > > > > > > > protected by
> > > > > > > > > > > yang-data in YANG. On the other hand, tools will be able
> > > > > > > > > > > to
> > > > > > > > > > > process
> > > > > > > > > > > such
> > > > > > > > > >
> > > > > > > > > > schemas
> > > > > > > > > > > (generate the ascii tree, convert it to something else,
> > generate
> > > > > > > > > > > sample
> > > > > > > > > > > instances etc.) without explicitly supporting yang-data.
> > > > > > > > > > >
> > > > > > > > > > > Lada
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > > Lada
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Andy
> > > > > > > > > > > >
> > > > > > > > > > > > > > there is a version of YANG that has a proper and
> > complete
> > > > > > > > > > > > > > integrated
> > > > > > > > > > > > > > solution. (If for example yang-data is used to
> > > > > > > > > > > > > > declare
> > > > > > > > > > > > > > error
> > > > > > > > > > > > > > content
> > > > > > > > > > > > > > for RPCs, then more extensions are needed or a
> > > > > > > > > > > > > > proper
> > > > > > > > > > > > > > integration
> > > > > > > > > >
> > > > > > > > > > into
> > > > > > > > > > > > > > YANG. Is it really good to introduce
> > > > > > > > > > > > > > augment-yang-data
> > > > > > > > > > > > > > (instead of
> > > > > > > > > > > > > > making augment work with say 'data' in YANG 1.2)?
> > > > > > > > > > > > > > And
> > then
> > > > > > > > > > > > > > we
> > > > > > > > > > > > > > do
> > > > > > > > > > > > > > uses-yang-data etc.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > /js
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > --
> > > > > > > > > > > > > Ladislav Lhotka
> > > > > > > > > > > > > Head, CZ.NIC Labs
> > > > > > > > > > > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > > > > > > > > > >
> > > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > > netmod mailing list
> > > > > > > > > > > > > netmod@ietf.org
> > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Ladislav Lhotka
> > > > > > > > > > > Head, CZ.NIC Labs
> > > > > > > > > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > > > > > > > >
> > > > > > > > > > > _______________________________________________
> > > > > > > > > > > netmod mailing list
> > > > > > > > > > > netmod@ietf.org
> > > > > > > > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > > > > > > >
> > > > > > > > > > _______________________________________________
> > > > > > > > > > netmod mailing list
> > > > > > > > > > netmod@ietf.org
> > > > > > > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > > > > >
> > > > > > > > --
> > > > > > > > Ladislav Lhotka
> > > > > > > > Head, CZ.NIC Labs
> > > > > > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > netmod mailing list
> > > > > > > > netmod@ietf.org
> > > > > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > netmod mailing list
> > > > > > > netmod@ietf.org
> > > > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > > > > .
> > > > > > >
> > > >
> > > >
> > > --
> > > Ladislav Lhotka
> > > Head, CZ.NIC Labs
> > > PGP Key ID: 0xB8F92B08A9F76C67
> > >
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
