On May 1, 2014:11:02 AM, at 11:02 AM, Andy Bierman <[email protected]> wrote:
> > > > On Thu, May 1, 2014 at 7:46 AM, Jeffrey Haas <[email protected]> wrote: > Tom, > > On Thu, May 01, 2014 at 10:01:38AM +0100, t.petch wrote: > > But, Jeff, you then say, in a parallel post > > > > "The issues then comes back to the ones noted in > > draft-bjorklund-netmod-operational-00: How do we distinguish > > operational, > > config or ephemeral config states? " > > > > whereas I see operational state, config and read-only statistics, with > > state (unqualified) referring to the first and last collectively! > > 'ephemeral' does not appear in Martin's I-D, nor would I expect it to - > > I don't see it as a concept in YANG/NETCONF. > > I agree it is not currently part of Netconf/Yang. This is part of why I > raise the question. > > > There is a separate issue of persistent and ephemeral in YANG, or, > > arguably, in NETCONF, which is also not documented AFAICS. This is > > probably of less interest to I2RS at this time. > > I actually think it's one of our bigger sticking points - or at least > something we need a clear answer on if N/Y is to be considered for i2rs use. > I2RS state is intended to be ephemeral. (See architecture document.) > > > I think this has been explained several times already, > starting in the IETF 89 slides. > > I don't think anybody has said NC/RC/YANG could be used > as the I2RS protocol without a single change. People has said > it is the best starting point for I2RS. There seemed to be an overwhelming > consensus in the London meeting and on this mailing list to > use NC or RC + YANG as the I2RS starting point. > > IMO, there needs to be a new datastore in the architecture that > contains I2RS data. The I2RS protocol will define how this data is accessed. > It's really not that complicated. > > There are many implementations using NC/RC + YANG, and many of > these vendors have stated that they believe this approach can > be made to work for I2RS. I agree. I am not sure why we keep going round and round about these issues. Its been clear from the start that while yang/netconf is a modeling language and protocol that can be used as a solid basis to solve the problems here, both need some minor modifications. In the case of yang, we've gone over many of the mods needed recently. NetMod is *currently* working on yang 1.1 which are minor changes that are probably a good vehicle to catch those changes, but waiting for another 9 months while we debate using the other 9 options will miss that window. As for NetConf, we need to be able to relax the commit sequence/locking/back-out operations so we have a "cut through" mechanism for fast programming. It is that simple. This has all been discussed at length over a year ago. We cannot wait forever for this WG to debate things ad infinitum. When can we get to producing some relevant solutions? --Tom > > > If there is one running datastore, then, presumably, it is persistent > > (across reboots) - the documents appear not to say. If there is running > > and startup, presumably startup is persistent and running is not. But > > if you have running and acme-special datastores, then which is > > persistent? This is one of several issues, like operational state, that > > have surfaced from time to time and, for me, have not got nailed down as > > well as I would like, and so - surface from time to time. > > > I2RS does not have any interaction with the "local config" except maybe > to read it. The NETCONF configuration datastores (candidate, running, > startup) are > not going to be used by I2RS. Nothing I2RS does is going to even slightly > alter the definition of any NETCONF configuration procedures. > > > This covers my point. Moving this particular bit of discussion to Juergen's > response to me in another thread. > > -- Jeff > > Andy > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
