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