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