> 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. 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. Lada > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
