> On 26 Oct 2015, at 12:55, Martin Bjorklund <[email protected]> wrote: > > Juergen Schoenwaelder <[email protected]> wrote: >> On Sat, Oct 24, 2015 at 03:07:41PM +0200, Martin Bjorklund wrote: >>> 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. >>> >>> Right. This is what "must" does. "when" is different. If a node's >>> "when" expression becomes false, that node is deleted, and its other >>> constraints are no longer used (e.g. must, mandatory etc). These are >>> two different use cases, two different tools available to the data >>> model designer. >>> >>> If we put "when" to the side for a moment, do you also think that >>> there should be no auto-deletion of cases in a choice? >> >> If I were to start from scratch, my answer would be most likely yes. >> >>> If this discussion had started from implementation/deployment >>> experience that said that "when" could not be implemented or that it >>> made it difficult to write NMS system or something else, things would >>> be different. But now we have a feature that has been in use for 5+ >>> years, and there are several implementations of it out there, and now >>> we say that it should be removed? Or worse, keep the syntax but >>> radically change the semantics. >> >> Do independent implementations really behave the same? I am not sure, >> the discussion around this makes me believe that it is somewhat likely >> that they do not all do the same. > > Apart from the error reporting issue we have discussion, I think at > least yuma and tail-f behave the same for the use cases that people > actually use. I'm sure we don't handle all these corner cases the > same way, but this should be fixed by adjusting the code to match the > new text in 6020bis. > >> Reading section 7.19.5 of RFC 6020 again, I do not find the auto-deletion >> described. > > It is described in 8.3.2. > >> I do see auto-deletion defined in section 7.9.6 for >> NETCONF's edit-config operation. (The text does not say anything about >> what happens if an attempt is made to create multiple cases, I guess >> it is implementation dependent which choice will become effective but >> one might also consider this an error - but clearly this is not >> defined). I note that RFC 6020bis has lifted this auto-deletion up >> from being a NETCONF edit-config property to a property that applies >> to all protocols. (It still does not define what happens if an edit >> creates multiple case branches.) >> >> A proposal was made to declare "when" auto-deletion to be part of the >> YANG data store validation process, that is, it applies to every >> protocol interface. This means that a datastore not only needs to >> maintain data that is being validated, it also needs to remember the >> last edit (at least) in order to _guess_ what should be deleted during >> validation. > > No guessing is involved. If a node's when expression evaluates to > false, it is deleted.
Are there any use cases where a client wants to send an edit that makes a "when" expression false, in order to remove the instance of the parent node, i.e. when it is not a mistake? In the two use cases that Andy described it is probably not the case - e.g., changing the type of an interface in ietf-interfaces is IMO always an error, and changing the type of routing protocol in ietf-routing isn't possible at all because "type" is part of the list key. Lada > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
