A theme that appears to have been running through the discussion of languages like YANG since (at least) 2007 (see draft-schoenw-sming-lessons-01, section 3.1) is that “preference should be give to solutions that simplify the task of readers. Reduction of the efforts required by writers is of secondary importance and the reduction of the efforts required by tool developers is of least important preference.” However, it sounds as though “when” auto-deletion complicates the task for both readers (e.g. network operators) and tool developers.
Jonathan From: Ladislav Lhotka Sent: 26 October 2015 10:54 To: Andy Bierman;Juergen Schoenwaelder;Andy Bierman;Martin Bjorklund;Balazs Lengyel;[email protected] Subject: Re: [netmod] Order of evaluation for when? Andy Bierman <[email protected]> writes: > 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. Correct. > 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? In a delete command, the client has to explicitly identify the node to be deleted. With auto-deletion this is not the case. > A buggy client may get *any* of the commands wrong, so > better take out all editing commands to protect everyone.. It's vulnerable not only to bugs in client or server code but also to human errors - an operator might not fully understand the contrived logic of the data model. Lada > > > > 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/> >> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
