Ladislav Lhotka <lho...@nic.cz> 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.
The reason that the text about MAY ignore is there was to allow a tool
like pyang to function even if it finds an extension like yuma:root in
a model. pyang doesn't "understand" this extension, yet it can
process the module.
I like Juergens analogy with text in the description statement - you
can write any rules in the description statement, or you can choose to
formalize it in an extension. Sometimes such rules are directed to a
client, sometimes to a server, sometimes to the YANG compiler
(e.g., code generation directives), and sometimes to humans reading
the module.
/martin
> 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.
>
> >
> >>> 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.
>
> Lada
>
> >
> > /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/>
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
