> On Aug 20, 2015:10:30 AM, at 10:30 AM, Ladislav Lhotka <[email protected]> wrote:
>
>
>> On 20 Aug 2015, at 16:00, Nadeau Thomas <[email protected]> wrote:
>>
>>>
>>> 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]”
>
> Yes.
>
>>
>>>
>>>> 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.
>
> Well, there is still quite a lot of text in 6020bis that has to do with
> NETCONF, and some of the existing or proposed extensions clearly affect the
> protocol(s).
>
> Lada
Yes, I know. We should think seriously about re-aligning that.
—Tom
>
>>
>> —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
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
