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... > o management protocols such as NETCONF or RESTCONF, > > 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
