> On 03 Aug 2015, at 10:18, Juergen Schoenwaelder
> <j.schoenwael...@jacobs-university.de> wrote:
>
> On Mon, Aug 03, 2015 at 09:22:48AM +0200, Ladislav Lhotka wrote:
>> Andy Bierman <a...@yumaworks.com> writes:
>>
>>> On Fri, Jul 31, 2015 at 8:37 AM, Ladislav Lhotka <lho...@nic.cz> wrote:
>>>
>>>>
>>>>> On 31 Jul 2015, at 16:54, Andy Bierman <a...@yumaworks.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Jul 31, 2015 at 5:45 AM, Ladislav Lhotka <lho...@nic.cz> wrote:
>>>>>
>>>>>> On 31 Jul 2015, at 14:40, Andy Bierman <a...@yumaworks.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Jul 31, 2015 at 1:12 AM, Ladislav Lhotka <lho...@nic.cz>
>>>> wrote:
>>>>>> Martin Bjorklund <m...@tail-f.com> writes:
>>>>>>
>>>>>>> Andy Bierman <a...@yumaworks.com> wrote:
>>>>>>>> On Thu, Jul 30, 2015 at 10:41 AM, Martin Bjorklund <m...@tail-f.com>
>>>> wrote:
>>>>>>>>
>>>>>>>>> Andy Bierman <a...@yumaworks.com> wrote:
>>>>>>>>>> On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund <
>>>> m...@tail-f.com>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Andy Bierman <a...@yumaworks.com> wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I understand the intent is that an implementation of NACM
>>>>>>>>>>>> has to understand these NACM extensions. I agree with Lada
>>>>>>>>>>>> that the YANG text about MAY ignore extensions casts doubt
>>>> whether
>>>>>>>>>>>> this sort of NACM rule is enforceable or specified
>>>> correctly.
>>>>>>>>>>>
>>>>>>>>>>> So do you agree that it would be a good idea to clarify this
>>>>>>>>>>> according to Juergen's suggestion?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> Not really.
>>>>>>>>>> Pretending the extension is just another description-stmt
>>>>>>>>>> does not really fix anything.
>>>>>>>>>>
>>>>>>>>>> A real YANG statement like config-stmt or a new statement
>>>>>>>>>> called ephemeral-stmt can be modified with refine-stmt
>>>>>>>>>> or deviate-stmt. This can never happen for
>>>>>>>>>> an external statement.
>>>>>>>>>
>>>>>>>>> There are two separate issues here:
>>>>>>>>>
>>>>>>>>> 1) It seems we are in agreement that if a model uses an extension
>>>>>>>>> statement, it is normative (like ietf-system's usage of
>>>> nacm:*).
>>>>>>>>>
>>>>>>>>> Should we somehow clarify this in 6020bis?
>>>>>>>>>
>>>>>>>>> 2) Extensions cannot be refined or deviated.
>>>>>>>>>
>>>>>>>>> Actually, the *syntax* rules allows things like:
>>>>>>>>>
>>>>>>>>> deviation /x:foo {
>>>>>>>>> deviate replace {
>>>>>>>>> i2rs:ephemeral true;
>>>>>>>>> }
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> I agree that it not clear what this means, but we could also
>>>>>>>>> clarify this in 6020bis.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> But this will take even longer than just defining the statements
>>>> that
>>>>>>>> are needed for ephemeral state, so no point in doing that.
>>>>>>>>
>>>>>>>> The text in 7.18.3.2 clearly does not support the example above at
>>>> all.
>>>>>>>
>>>>>>> The grammar allows extensions everywhere, so the example is (as I
>>>>>>> wrote) syntactically valid.
>>>>>>>
>>>>>>>> Only one of the keywords listed in the table are supported.
>>>>>>>
>>>>>>> The text doesn't say so, and anyway my point was that - regardless of
>>>>>>> the outcome of the ephemeral dicussion - it might be a good a idea to
>>>>>>> clarify that extensions can be deviated as well.
>>>>>>
>>>>>> +1
>>>>>>
>>>>>>
>>>>>> So you are saying that a tool MAY ignore any extension, except
>>>>>> inside a deviation-stmt? Then it becomes mandatory to support?
>>>>>>
>>>>>> Or do you mean:
>>>>>>
>>>>>> Yes you can put extension-stmts anywhere, but also, yes the tool
>>>>>> MAY ignore every single extension (everywhere, including inside a
>>>>>> deviation-stmt)
>>>>>
>>>>> I understood Martin’s proposal so that a device that doesn’t support an
>>>> extension used in modules it advertises will have to put it in a
>>>> “not-supported” deviation.
>>>>>
>>>>>
>>>>> So features are all "not-supported" by default. but extensions,
>>>>> which a tool MAY ignore, are all supported by default?
>>>>
>>>> I proposed to remove this “MAY ignore” text.
>>>>
>>>
>>>
>>> I do not support this change
>>>
>>
>> The current "MAY ignore" formulation is unclear, and it doesn't matter
>> whether it talks about compilers, parsers or tools.
>>
>> The problem with extensions is that they can mean virtually anything –
>> in particular, they can change semantics of YANG or the management
>> protocol.
>
> Any description statement in principle can do this. We trust that sane
6020(bis) is silent about the effects a description or extension can have - I
think there should be relatively strict limits. I agree with Jernej that
descriptions or extensions should not be allowed to change YANG semantics.
We had a discussion before about defining new XPath functions via extensions.
Doing it via descriptions is equally inacceptable for me.
Lada
> data model writers won't do bad things. And if they do, we hope that
> people will not implement and deploy bad things.
>
>> I think there are two possible approaches:
>>
>> 1. Treat all extensions appearing in the server's data model as
>> mandatory parts of data model or protocol semantics.
>>
>> 2. Make extensions truly optional and irrelevant from the point of view
>> of YANG language.
>>
>> With #1, a client that doesn't understand all extensions the server uses
>> SHOULD terminate the session, because there are no means for negotiating
>> support for extensions one by one.
>>
>> I am afraid this could have disastrous consequences for
>> interoperability: we would have silos where servers only work with
>> clients of the same provenience.
>>
>> #2 is what RELAX NG does: elements and attributes from foreign
>> namespaces are allowed in a schema but they cannot affect the notion of
>> RELAX NG validity because the specification of the validation procedure
>> says: "Foreign attributes and elements are removed."
>>
>> With #2, protocols such as I2RS can still define their extensions
>> provided that
>>
>> - there is some way for making sure that both the server and client
>> understands it,
>>
>> - it doesn't affect servers and clients of other protocols, so they may
>> safely ignore it.
>>
>> I would personally vote for #2, but then the NACM stuff or the
>> "annotation" statement really cannot be extensions.
>
> I continue to see extension statements as reusable and (in principle)
> machine readable fragments of description statements. From this
> perspective, it seems odd to make a difference between extensions and
> description statements. I think the NACM extensions are just fine as
> they are. I do not see anything broken about them.
>
> /js
>
> --
> Juergen Schoenwaelder Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
