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. > 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. /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
