Martin Bjorklund <m...@tail-f.com> writes:
> Andy Bierman <a...@yumaworks.com> wrote:
>> On Wed, Aug 19, 2015 at 5:49 AM, Martin Bjorklund <m...@tail-f.com> wrote:
>>
>> > Hi,
>> >
>> > [joining this discussion a bit late]
>> >
>> > Ladislav Lhotka <lho...@nic.cz> wrote:
>> > >
>> > > > On 10 Aug 2015, at 18:46, Andy Bierman <a...@yumaworks.com> wrote:
>> > > >
>> > > >
>> > > >
>> > > > On Mon, Aug 10, 2015 at 9:37 AM, Ladislav Lhotka <lho...@nic.cz>
>> > > > wrote:
>> > > >
>> > > > > On 10 Aug 2015, at 17:32, Andy Bierman <a...@yumaworks.com> wrote:
>> > > > >
>> > > > >
>> > > > >
>> > > > > On Mon, Aug 10, 2015 at 4:24 AM, Ladislav Lhotka <lho...@nic.cz>
>> > > > > wrote:
>> > > > >
>> > > > > > On 10 Aug 2015, at 12:17, Andy Bierman <a...@yumaworks.com> 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,
- semantics of the protocol,
- schema of the data model (as annotations do).
>
> 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.
>
> 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?
Lada
>
>> For example,
>> we have our own extensions that cause the server to
>> perform internal tasks certain ways (like ywx:sil-delete-children-first).
>>
>> According to the text you propose, all servers would have to
>> provide the behavior embodied in the syntax of this extension
>> statement?
>
> Yes, all servers that advertise such a module. B/c as you note below
> it is "well-behaved". So the defintion probably says something like
> "if the server implements SIL, then it will delete the children before
> it deletes the node itself".
>
>> This extension does not alter any protocol behavior
>> at all, so it is "well-behaved".
>>
>> A server MAY skip over the entire extension and completely ignore it.
>> Other servers are not required to provide the behavior described
>> in the extension semantics.
>
> Yes. Aren't we in agreement here?
>
>
> /martin
>
>
>
>>
>>
>>
>> > However, I do agree that an extension cannot "undo" semantics defined
>> > by other YANG statements, just as you cannot do that in a description
>> > statement. For example, this would be illegal:
>> >
>> > leaf foo {
>> > type int32;
>> > description "The type is really a string.";
>> > }
>> >
>> > leaf bar {
>> > type int32;
>> > xx:real-type string;
>> > }
>> >
>> > It is also a Very Bad Idea (speaking from experience...) to define an
>> > extension that introduces new data nodes.
>> >
>> > The text about "MAY ignore" was meant to capture this. It's supposed
>> > to be like for a client that doesn't understand an augemntation; it
>> > can skip it. A client that doesn't understand nacm:default-deny-all
>> > works just fine and can safely ignore it.
>> >
>> >
>> > /martin
>> >
>>
>>
>> Andy
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
