> 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.
> 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.
Lada
>
> Whether tools understand the semantics of an extension statement or
> not is a tool implementation issue. If a YANG tool does not support
> default-deny-write, an implementation still needs to provide the
> behaviour called out for if a data model uses this extension.
>
> Given this interpretation of extensions, I do not really understand
> the discussion here.
>
> /js
>
> PS: Perhaps we should change
>
> If a YANG compiler does not support a particular extension, which
> appears in a YANG module as an unknown-statement (see Section 13),
> the entire unknown-statement MAY be ignored by the compiler.
>
> to
>
> If a YANG parser does not support a particular extension, which
> appears in a YANG module as an unknown-statement (see Section 13),
> the entire unknown-statement MAY be ignored by the parser. Note
> that even in this case the semantics associated with the extension
> still apply (as if they were part of a description statement).
>
> and consistently use YANG parser everywhere instead of sometimes YANG
> parser and sometimes YANG compiler.
>
> --
> 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
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
