> On 20 Aug 2015, at 12:37, Martin Bjorklund <[email protected]> wrote:
>
> Ladislav Lhotka <[email protected]> wrote:
>> Martin Bjorklund <[email protected]> writes:
>>
>>> Andy Bierman <[email protected]> wrote:
>>>> On Wed, Aug 19, 2015 at 5:49 AM, Martin Bjorklund <[email protected]> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> [joining this discussion a bit late]
>>>>>
>>>>> Ladislav Lhotka <[email protected]> wrote:
>>>>>>
>>>>>>> On 10 Aug 2015, at 18:46, Andy Bierman <[email protected]> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Aug 10, 2015 at 9:37 AM, Ladislav Lhotka <[email protected]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On 10 Aug 2015, at 17:32, Andy Bierman <[email protected]> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Aug 10, 2015 at 4:24 AM, Ladislav Lhotka <[email protected]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On 10 Aug 2015, at 12:17, Andy Bierman <[email protected]> wrote:
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I am strongly against changing the contract on extensions.
>>>>>>>>> They MAY be ignored by any YANG tool. Period.
>>>>>>>>> That means they are far from mandatory.
>>>>>>>>> They are little more than a keyword and a description clause.
>>>>>>>>
>>>>>>>> So do you prefer my proposed solution -02 or -03?
>>>>>>>>
>>>>>>>> ** Solution Yxx-03
>>>>>>>>
>>>>>>>> Make extensions optional. This means that extensions won't be
>>>>>>>> allowed to change YANG language, NETCONF protocol, and validity of
>>>>>>>> datastores and protocol messages.
>>>>>>>>
>>>>>>>>
>>>>>>>> This is how we use extensions to tag YANG data models
>>>>>>>> to drive automation tools.
>>>>>>>
>>>>>>> But that means, for example, that annotations cannot be defined via an
>>>>>>> extension statement as in draft-ietf-netmod-yang-metadata.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Which means these statements should be real instead of extensions.
>>>>>>> If the statements are defining data that is exchanged between
>>>>>>> peers in a standard protocol, then YANG extensions are not
>>>>>>> appropriate.
>>>>>>
>>>>>> I agree, and -03 is my preferred solution, too.
>>>>>
>>>>> I strongly disagree. IMO the IETF usage of extensions so far (NACM,
>>>>> annotations) works well (in the case of NACM proven by multiple
>>>>> independent implementations), and follows how extensions were intended
>>>>> to be used, and obviously, how the WG has understood them up until
>>>>> now.
>>>>>
>>>>> If the sentence:
>>>>>
>>>>> If a YANG compiler does not support a particular extension, which
>>>>> appears in a YANG module as an unknown-statement (see Section 12),
>>>>> the entire unknown-statement MAY be ignored by the compiler.
>>>>>
>>>>> in 6020 can be interpreted to mean that an occurance of an extension
>>>>> is non-normative, we should fix it so that it matches what was
>>>>> intended and how it is used.
>>>>>
>>>>> Juergen suggested this replacement text, which I support. Maybe it
>>>>> can be improved even more.
>>>>>
>>>>> 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).
>>>>>
>>>>>
>>>>
>>>> I strongly disagree with this change.
>>>> This would mean that every tool is required to support the
>>>> semantics of every extension ever defined.
>>>
>>> No. It means that if a server advertises module that uses some
>>> extension to define some behaviour, the server supports that
>>> behavior. Just as we expect a server to support the text in
>>> description statements.
>>
>> This is unclear both from the current text and from Juergen's
>> proposal. Maybe I am a nitpicker but assume that either (i) server
>> implementation is completely generated from the data model, or (ii) the
>> parser in question is simply in the implementor's head. Then I don't
>> know how the server can implement the semantics of an extension if the
>> extension is removed while YANG modules containing it are being parsed.
>>
>> A text like "a client MAY ignore an extension that it doesn't
>> understand" would be clearer but I don't think it is acceptable if the
>> extension changes
>>
>> - semantics of YANG,
>
> Agreed.
>
>> - semantics of the protocol,
>
> Maybe...
>
>> - schema of the data model (as annotations do).
>
> I think it is ok to define an annotation with an extension (as the
> draft does). When designing a feature that is going to use an
> annotation it is important to keep in mind that not all clients will
> understand the annotation. So e.g. if the new feature is a "comment",
> the server might just blindly return them to all clients, but in the
For a client that doesn’t understand the annotation (or annotations in general)
it is just extra junk that’s not in the data model. This is no different from a
new data node type defined through an extension - in fact, in JSON encoding
annotations are just special object members. A prudent client may consider such
data invalid.
> case of "inactive", the server must not send these attributes to a
> client that doesn't ask for them. (You may argue that even for
> comments the client should ask for them, but that is besides the
> point).
IMO “inactive” data change the NETCONF/RESTCONF protocol. If a client doesn’t
see inactive data, it may think it is OK to write its own content to that
place, which probably shouldn’t be allowed.
>
> The bottom line is that you have to be careful when you define a new
> extension statement.
>
>>> For example, the nacm: extensions do not apply unless ietf-netconf-acm
>>> is advertised (and nacm is enabled). I expect most extensions to work
>>> this way. Another example is if we actually defined i2rs:ephemeral;
>>> this would have no effect unless the "i2rs" capability (whatever that
>>> is) is also advertised.
>>
>> The nacm: extensions are probably OK because they only give some
>> additional info about the server behaviour that is independent of
>> client's support. If the client ignores them, then it may be just
>> wondering why it cannot read or write some data.
>
> Right.
>
>>> The text also means that it is perfectly ok for a client to ignore the
>>> extension if it doesn't understand it. For example, if the client has
>>> no idea what the ephemeral datastore it, it doesn't matter that a node
>>> is marked with i2rs:ephemeral true.
>>
>> I am not convinced at all about this one. If the server advertises the
>> "i2rs" capability and modules that use "i2rs:ephemeral" extension, then
>> a normal NETCONF/RESTCONF client can ignore both (RFC 6241: "Each peer
>> [...] MUST ignore any capability received from the other peer that it
>> does not require or does not understand."). Buth what then: can the
>> client treat nodes tagged with "i2rs:ephemeral" just as standard nodes?
>
> My idea has been that it would be used as:
>
> leaf my-ephemeral-leaf {
> config false;
> i2rs:ephemeral true;
> ...
> }
>
> which means that if the client doesn't know what to do with
> "i2rs:ephemeral", it will ignore it, as just see this as a normal
> config false node that can be read with <get>.
It of course depends on the particular usage rules - I assumed ephemeral data
would be config=true. But even in your example, if ephemeral data are in a
special datastore, they may not be returned with <get>, which can again violate
the schema.
I think arbitrary extensions are OK if they are used in a controlled
environment, e.g. in single vendor’s server and client software, but in general
they can break interoperability unless they are accompanied with a
bidirectional client-server negotiation mechanism.
Lada
>
>
> /martin
>
>
>
>>
>> Lada
>>
>>>
>>>> For example,
>>>> we have our own extensions that cause the server to
>>>> perform internal tasks certain ways (like ywx:sil-delete-children-first).
>>>>
>>>> According to the text you propose, all servers would have to
>>>> provide the behavior embodied in the syntax of this extension
>>>> statement?
>>>
>>> Yes, all servers that advertise such a module. B/c as you note below
>>> it is "well-behaved". So the defintion probably says something like
>>> "if the server implements SIL, then it will delete the children before
>>> it deletes the node itself".
>>>
>>>> This extension does not alter any protocol behavior
>>>> at all, so it is "well-behaved".
>>>>
>>>> A server MAY skip over the entire extension and completely ignore it.
>>>> Other servers are not required to provide the behavior described
>>>> in the extension semantics.
>>>
>>> Yes. Aren't we in agreement here?
>>>
>>>
>>> /martin
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>>> However, I do agree that an extension cannot "undo" semantics defined
>>>>> by other YANG statements, just as you cannot do that in a description
>>>>> statement. For example, this would be illegal:
>>>>>
>>>>> leaf foo {
>>>>> type int32;
>>>>> description "The type is really a string.";
>>>>> }
>>>>>
>>>>> leaf bar {
>>>>> type int32;
>>>>> xx:real-type string;
>>>>> }
>>>>>
>>>>> It is also a Very Bad Idea (speaking from experience...) to define an
>>>>> extension that introduces new data nodes.
>>>>>
>>>>> The text about "MAY ignore" was meant to capture this. It's supposed
>>>>> to be like for a client that doesn't understand an augemntation; it
>>>>> can skip it. A client that doesn't understand nacm:default-deny-all
>>>>> works just fine and can safely ignore it.
>>>>>
>>>>>
>>>>> /martin
>>>>>
>>>>
>>>>
>>>> Andy
>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
