Andy Bierman <[email protected]> writes:
> On Fri, Oct 23, 2015 at 1:36 PM, Juergen Schoenwaelder <
> [email protected]> wrote:
>
>> On Fri, Oct 23, 2015 at 10:35:48AM +0200, Ladislav Lhotka wrote:
>> > Martin Bjorklund <[email protected]> writes:
>> >
>> > > auto-deletion in choice/when should be described as a property of the
>> > > data model for the datastore. Parts of the text from Section 8.2.2
>> > > should be made more generic and moved, probably to a new section
>> > > 8.1.1. I will have a look at this.
>>
>> [...]
>>
>> > IMO YANG spec should tell what's valid and what isn't, and stop there.
>>
>> As technical contributor, I tend to agree. The purpose of validation
>> should be to return a boolean - datastore is valid or invalid. I find
>> the idea scary that validation causes changes of a datastore in an
>> attempt to make an invalid the datastore valid. And it is even more
>> scary if the attempt to make the datastore valid requires to remember
>> what the last edit was that triggered the validation procedure in
>> order to decide how to try to make the datastore valid (if we consider
>> different protocols with different primitives to trigger edits on a
>> datastore).
>>
>>
>
> There is a very strong use-case in "augment when" and also
> just "when <correct-subclass>".
Essentially, these are cases that can be expressed with a regular
grammar like this:
X -> a A | b B
where terminals "a" and "b" are the types of two classes and
nonterminals "A" and "B" represent their contents.
Incidentally, this is also a type of choice that can be easily expressed
in RELAX NG:
(element type { "a" } & A) | (element type { "b" } & B)
Unfortunately, YANG's choice cannot be used in this fashion because the
same node (here it is "type") cannot be used in multiple cases.
>
> Does that mean that implementing "when" statement should not
> be 10X harder than anything else in YANG? Who knows.
>
> I suspect there does not exist anything close to a perfect
> implemention of YANG when evaluation. If customers really wanted
One (rather restrictive) way would be to allow when expressions only
with functions derived-from() and derived-from-or-self(). So classes and
sublasses would be modelled exclusively via identities.
> to use the corner-case examples you guys come up with, then
> there would be a problem. So far it is mostly the 2 use cases I
> described.
Yes, but then it would be much better to have corresponding syntactic
restrictions. The fact that any XPath expression is allowed is not only
scary, it could be exploited as a security hole.
>
> The current auto-deletion is actually consistent behavior
> because it applies to nodes in the PDU and nodes already
> in the datastore. Auto-deletion avoids forcing the client to
> make multiple edits, possibly leaving the datastore in
> a vulnerable state in between edits.
>
Auto-deletion just makes the problems of "when" more serious because it
can have catastrophic consequences.
Lada
>
>
>
>
>> /js
>>
>
> Andy
>
>
>>
>> --
>> 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/>
>>
>> _______________________________________________
>> netmod mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/netmod
>>
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
