> 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.
>
>>> 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
