Hi,
So why don't we make all the new YANG 1.1 statements like "action"
into extensions? This is just as good, right? It seems like real keywords
are for feature you like, and extensions are for features you don't like.
IMO ephemeral state is much more fundamental than the action-stmt.
Every YANG tool MUST understand any statements added for this purpose.
Andy
On Wed, Jul 29, 2015 at 7:14 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:
> On Wed, Jul 29, 2015 at 02:24:03PM +0200, Ladislav Lhotka wrote:
> >
> > > On 29 Jul 2015, at 13:47, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> > >
> > > On Wed, Jul 29, 2015 at 12:57:09PM +0200, Ladislav Lhotka wrote:
> > >>
> > >>> On 29 Jul 2015, at 12:25, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> > >>>
> > >>> On Wed, Jul 29, 2015 at 09:34:17AM +0200, Martin Bjorklund wrote:
> > >>>> Hi,
> > >>>>
> > >>>> Andy Bierman <a...@yumaworks.com> wrote:
> > >>>>
> > >>>>> I do not agree that YANG extensions should be used for IETF
> standards track
> > >>>>> modules.
> > >>>>
> > >>>> I strongly disagree. This was one of the two original ideas behind
> > >>>> extension statements (the other was that vendors could add their own
> > >>>> stuff).
> > >>>
> > >>> An extension defines certain semantics. For example:
> > >>>
> > >>> extension default-deny-write {
> > >>> description
> > >>> "Used to indicate that the data model node
> > >>> represents a sensitive security system parameter.
> > >>>
> > >>> If present, and the NACM module is enabled (i.e.,
> > >>> /nacm/enable-nacm object equals 'true'), the NETCONF server
> > >>> will only allow the designated 'recovery session' to have
> > >>> write access to the node. An explicit access control rule
> is
> > >>> required for all other users.
> > >>>
> > >>> The 'default-deny-write' extension MAY appear within a data
> > >>> definition statement. It is ignored otherwise.";
> > >>> }
> > >>>
> > >>> If a data model writer uses an extension, then the semantics
> > >>> associated with the extension are embedded in the data model. The
> > >>> extension can be seen as a shorthand for copying the semantics
> > >>> directly into the description clause. In other words, an
> > >>
> > >> The difference is that YANG spec doesn’t say descriptions may be
> ignored.
> > >
> > > I do not get it, please help me.
> >
> > A client that ignores constraints expressed in a description statement
> should be considered broken. I am not sure it is also the case for a client
> that ignores an extension and the implied semantics, because sec. 6.3.1
> seems to allow it.
> >
> > In fact, I think it can be applied to the server, too: An implementor
> may take a module, remove extensions he doesn’t want to implement (or let a
> “compiler” remove them) and implement the modified form of the module.
> >
>
> As I tried to explain, I believe there is confusion between a tool
> skipping over an extension statement and the semantics that are
> applied to the data model. The text in 6.3.1 talks about the tool
> (the 'compiler').
>
> > >>> implementation has to implement the semantics no matter which
> > >>> tool is used.
> > >>
> > >> I agree, but then I think the text you have in PS should be removed
> entirely. There is again the issue of old client support that IMO doesn’t
> hold water anyway: a client that doesn’t fully understand the semantics of
> the data model cannot be guaranteed to work, and is in fact dangerous.
> > >>
> > >
> > > Again, I do not get it. There are non-machine readable semantics
> > > anyway. A decent client better understands the semantics - otherwise
> > > it is just a clueless yang browser. So why is there a problem with
> > > extension statements (which are just a shorthand for semantics that
> > > happen to be machine readable for those tools that are programmed to
> > > read and understand them).
> >
> > As I said, it is unclear (to me at least) from the text in 6.3.1 whether
> extensions are an integral part of the contract expressed by the module. If
> I had a contract with an insurance company saying “Anybody who cannot read
> fine print may ignore it”, I would get quite nervous.
>
> I believe this is a mis-interpretation of the text in 6.3.1. and I
> tried to propose new text that hopefully clarifies this. You agree
> with the proposed text?
>
> /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
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
