On Mon, Oct 26, 2015 at 8:57 AM, Ladislav Lhotka <[email protected]> wrote:
> > > On 26 Oct 2015, at 16:10, Andy Bierman <[email protected]> wrote: > > > > > > > > On Mon, Oct 26, 2015 at 4:55 AM, 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. > > > > > > > > Some of the new text that has been discussed in not implementable. > > For example, there are no tools that take an arbitrary set of XPath > expressions > > against the same XML instance document, and determine which order > > (if any) is the one true correct order that must be used. Requirements > > like this in YANG 1.1 are just not implementable. > > And even if it is implementable, it would be terribly expensive. > > > > > The "when" statement is the sharpest knife in the drawer. > > If it is too complicated to get right, then it will be > > used incorrectly. Same as the "pattern" statement. > > We get those wrong all the time and fix them in Errata. > > That doesn't seem to be a problem. I don't hear calls to > > remove pattern-stmt because he syntax is really hard. > > The difference is that efficient algorithms are available for regex > matching, and there are no dark corners. > So a pattern may not do exactly what it was intended for but it should > never cause the server or client software to fail or accidentally erase > some data. > > If the regex test fails then the leaf or leaf-list will be rejected with an invalid-value error. If an invalid pattern passes then it will be accepted as a valid string for that typedef. This is bad enough but it can in turn cause ripple effects (e.g. leafref) that are just as bad as deleting data that the when-stmt says is going to be deleted. > > > > We are not going to spend any time coding for > > clever corner-cases. We do spend time coding for use-cases. > > I agree the interoperability for use-cases is quite acceptable. > > All this fuss over corner-cases is not that interesting. > > I think it is only matter of time when such corner cases show up in the > wild. People like to use sharp knives. > > And we fix then one at a time when they come up. As the number of inter-connected modules grows the possibility for when-stmt race conditions in real modules will also grow. Hopefully YANG Doctors will be paying attention and identify problems in IETF modules before they are published. Lada > Andy > > > > > > > Andy > > > > > > > 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 > > > > _______________________________________________ > > 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
