> On Aug 20, 2015:9:26 AM, at 9:26 AM, Martin Bjorklund <[email protected]> wrote:
>
> Ladislav Lhotka <[email protected]> wrote:
>> Martin Bjorklund <[email protected]> writes:
>>
>>> Ladislav Lhotka <[email protected]> wrote:
>>>>
>>>>> On 20 Aug 2015, at 13:12, Martin Bjorklund <[email protected]> wrote:
>>>>>
>>>>> Ladislav Lhotka <[email protected]> wrote:
>>>>>>
>>>>>>> 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.
>>>>>
>>>>> Right, this idea assumes that ephemeral data *is* returned by <get>.
>>>>>
>>>>>> 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.
>>>>>
>>>>> I agree that it is important to think about protocol negotiation
>>>>> mechanisms, client backwards compatibility etc. when defining
>>>>> extensions.
>>>>
>>>> But even then it might be difficult to handle situations where one
>>>> client supports an extension while another doesn’t - the server
>>>> simply may not be able to behave simultaneously in two different
>>>> ways.
>>>
>>> But just b/c there are *some* potential extension that would have
>>> problems, does not mean that *all* extensions should be banned.
>>
>> My concern is that vendors might misuse extensions for creating silos -
>> we all remember browser wars, right?
>>
>> And in the particular case of "annotation", I am not sure whether it is
>> really OK for a server to advertise an annotation in a module and then
>> start using it without client's consent.
>>
>>>
>>>> That’s why I think the only option that’s really safe for now
>>>> is
>>>>
>>>> ** 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.
>>>
>>> I think we need explicit text in order to be able to agree on a
>>> solution.
>>
>> Section 6.3.1:
>>
>> OLD
>>
>> 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.
>>
>> NEW
>>
>> Extensions MUST NOT affect the following aspects:
>>
>> o syntax and semantics of YANG language,
>
> I don't know what this means, but it sounds ok…
I think what you mean is “MUST NOT contradict the syntax or semantics
specified in The Yang Language [RFC Reference]”
>
>> o management protocols such as NETCONF or RESTCONF,
This is trickier. We are now in agreement that Yang as a language, is
not bound to NETCONF and also RestConf, but it seems the statement above
doesn’t buy into that because its coupling the three things together.
—Tom
>>
>> o validity of datastores and protocol messages with respect to the
>> data model.
>
> I am not sure I understand these two either. I don't think this is
> needed. It's like if we wrote that the text in description statements
> MUST NOT "affect management protocols like NETCONF", etc. If someone
> tries to get such an extension standardized, hopefully reviewers will
> catch this.
>
>> A server advertising modules that define and use an extension MUST
>> adhere to the extension's semantics as specified in its definition.
>
> Ok.
>
>> However, clients MAY ignore any or all extensions appearing in
>> modules advertised by the server.
>
> Hmm, I agree with Andy's idea that the definition of an extension
> defines the conformance for the extension.
>
>
>> By the way, due to the adopted solution Y49-04, the second paragraph in
>> sec. 6.3.1 should also be removed.
>
> I assume you mean the second paragraph of 6.3.1 in RFC 6020? That
> paragraph is already removed in draft-ietf-netmod-rfc6020bis-06.
>
>
> /martin
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
