Andy Bierman <[email protected]> writes:

> On Thu, Nov 5, 2015 at 1:20 AM, Martin Bjorklund <[email protected]> wrote:
>
>> Juergen Schoenwaelder <[email protected]> wrote:
>>

...

>> > - Old function: make auto-delete for choice and when non-NETCONF specific
>> >
>> >   Revision -08 of YANG 1.1 defines auto-deletion as a property of the
>> >   NETCONF edit-config operation and the issue is whether this
>> >   auto-deletion behaviour is a NETCONF specific edit-config property
>> >   or a general YANG datastore validation property that equally applies
>> >   to RESTCONF, COMI, ...
>> >
>> >   It is unclear where we are with this. More input would be welcome.
>>
>> I think it would be very confusing if e.g. RESTCONF behaved
>> differently than NETCONF.  However, I can see how it might make sense
>> for a server on a constrained device to not do auto-delete - but OTOH
>> such a server probably don't do "must" and "when" checking at all.
>> And it might have specialized data models that don't use such
>> constructs.
>>
>>
>>
> I don't like any of the NETCONF-specific text in YANG 1.1.
> YANG datastore constraints refer to a conceptual "valid datastore".
> There is no reason to talk about specific protocol behavior,
> except that we are too lazy to put protocol text where it belongs.

Agreed.

>
> It should at least be clear that datastore validation does not at all depend
> on how the datastore contents were changed.  The current text does
> not even fully support <copy-config>, so it does not even support NETCONF,
> let alone RESTCONF.
>
> IMO auto-deletion should not be changed.
> It works fine and the only issue that has ever come up is
> auto-deleting data from an edit-config payload.

IMO a scarier prospect is the ripple effect where an edit-config causes
some remote part(s) of the data tree to disappear.

I looked into the existing uses of "when" and none of them seems to be
really designed for the auto-deletion option. That is, auto-deletion is
either impossible (e.g. if "when" involves just a list key) or otherwise
it would clearly be an operator error (e.g. if interface type is changed
by mistake).

Lada


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

Reply via email to