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