Martin Bjorklund <m...@tail-f.com> writes:
> 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:*).
>
What about the problem with "old clients"? Let's say a new version of a
device advertises a module that contains an extension (such as
"annotation") that changes server behaviour, datastore semantics, things
like that. So far the theory has been that a client may ignore such a
module, which however means ignoring the changes in semantics that may
be crucial for interoperability and/or security.
I think a robust and safe old client support is in fact very difficult
to achieve and may be a security hole. This is my favorite example:
augment "/if:interfaces" {
leaf launch-missiles {
type boolean;
default true;
}
}
IMO old clients may try to perform the same operations they used to do
with an old version without knowing the current datastore schema and
semantics, but no guarantees can be given - it may work or fail
miserably.
Lada
> 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.
>
>
>> IMO ephemeral data support needs to be a real statement
>> that can be used with refine-stmt and deviate-stmt.
>> It is a real property of a data node.
>
> Note: it is still not clear that such a statement (base or extension)
> is needed at all.
>
>
> /martin
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
