On Sun, Oct 25, 2015 at 8:55 AM, Martin Bjorklund <[email protected]> wrote:
> Andy Bierman <[email protected]> wrote: > > On Sun, Oct 25, 2015 at 6:58 AM, Martin Bjorklund <[email protected]> > wrote: > > > > > Andy Bierman <[email protected]> wrote: > > > > On Sat, Oct 24, 2015 at 6:07 AM, Martin Bjorklund <[email protected]> > > > 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 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. > > > > > > > > > > > > > > > > > > The one special case that has been identified is data provided > > > > as part of an edit that is silently deleted and <ok/> returned. > > > > This could be considered different than providing an edit that > > > > deletes existing data nodes. > > > > > > Right. I think an error should be returned to the client in this > > > case. This is nicer to the client. Otherwise, the client might set > > > something, get <ok/> back and the might be surprised when the changes > > > did not actually happen. > > > > > > (FWIW, this is how we interpreted the spec and thus have implemented) > > > > > > > > > > What text says return an error here? > > I think we already had this discussion. I thought that 8.3.1 was > supposed to cover this, but I can see how it doesn't. So I agree > there is no such clear text in 6020, even though that was the > intention. I am open to an discussion about the best behavior in this > case. It is trivial to change the code to not return the error. > > > I don't have enough data to know if this is more of a bug than a feature. I agree that it is a slippery slope to say the hidden when-stmts behind the <config> anyxml node are covered by 8.3.1. The text for if-feature looks similar to when-stmt, but they are not treated the same. If an edit contains a node where the if-feature is false, an 'unknown-element' error is always returned. But YANG features are stable, and for "when", the results are possibly changing because of the edit in progress. We have 'delete' to be fussy and 'remove' to delete if it exists, and the client can decide which one to use. I would prefer a protocol solution that let the client decide if payload auto-delete is OK or not. > /martin > Andy
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
