Hi, I buy Martin's argument that "when" stmt is like "choice". The draft says exactly what will happen if the constraint is not satisfied. Why don't we require the client to delete the old case and create the new case all at once?
The "when" auto-deletion is no less scary then "case" auto-deletion. It has the exact same ripple effects. For that matter, if a client incorrectly deletes a trunk interface, scary things will happen as well. So why don't we take out the "delete" command? A buggy client may get *any* of the commands wrong, so better take out all editing commands to protect everyone.. Andy On Fri, Oct 23, 2015 at 3:09 PM, Juergen Schoenwaelder < [email protected]> wrote: > On Fri, Oct 23, 2015 at 02:42:26PM -0700, Andy Bierman wrote: > > > Auto-deletion avoids forcing the client to make multiple edits, > > possibly leaving the datastore in a vulnerable state in between > > edits. > > A single edit can say 'delete this, add that' and then you validate > the result. This is simple to understand and matches the behaviour of > other systems people are familiar with. I do not buy your 'vulnerable > state in between argument'. If the client prefers to send multiple > edits, it better uses locks anyway. > > Right now, we seem to accept 'add that' and when validation of the > result fails, the server is expected to try 'delete that' in an > attempt to restore happiness. And this try 'delete that' can have > ripple effects. A validate operation that changes was is being > validated is scary. Its like pyang modifying foo.yang while parsing it > in an attempt to finish without parsing errors... > > /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
