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? > > /martin > Andy > > > > > This said, I am all for guidelines and that we check for bad uses of > > > "when" when we do reviews of data models. > > > > > > > > We will do that, but it does not address the runtime error (or not) > > of auto-deletion of data provided in the edit. Should this be > > an error, a warning, or return OK? > > > > Auto-deletion of existing data nodes is fine. > > The client needs to be aware of the YANG module > > or watch netconf-config-change notifications. Setting /X=3 or /X=5 > > requires understanding of the semantics for object X. The when-stmt is > just > > part of that requirement. > > > > > > > > > > > > > > /martin > > > > > > > > > > Andy > > > > > > > > > > > > > > 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). > > > > > > > > /js > > > > > > > > -- > > > > 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 > > > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
