On Tue, Jul 12, 2016 at 03:24:11PM +0000, Eric Voit (evoit) wrote: > Hi Robert, > Hi Juergen, > > Robert: thanks for this comparison. Certainly the Event and Datastore > Subscription drafts would be users of whatever results from your and > Juergen’s efforts. > > A question on the representation of the Ephemeral Datastore. Why not > consider Ephemeral Config as part of the running datastore? Having Ephemeral > part of running should match better to people’s mental models of what Running > actually means. Also if there is no Ephemeral Config on a device, this > shouldn’t present backwards compatibility issues. >
a) The content of the <running> _configuration_ datastore may be eventually made persistent according to how NETCONF works today. b) The <running> configuration datastore has editing primitives that trigger specific YANG validation rules that, as far as I understand, do not match I2RS requirements. c) I2RS specifically requires that I2RS data can reference state data, which is not allowed for config true data in configuration datastores. There may be more but this is likely already a good start. 'Ephemeral datastore' is a term we should get rid of as soon as possible. A datastore may be ephemeral or persistent and this is I think a _property_ of a datastore but no the main reason for the existance of a datastore. We are talking about an 'ephemeral datastore' in the context of I2RS simply since never nailed it down / found agreement on what kind of datastore this really is. I would call this thing a <control-plane> datastore or a <routing> datastore or even an <i2rs> datastore or even a <foo> 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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
