Hi, I agree it should be a WG (maybe IESG) decision whether YANG 1.1 should be published ASAP and a new version started right away to update it. The RFC publication process is not that hard to solve. The tool and user confusion caused by all these versions is another matter.
more inline... On Sun, Jul 26, 2015 at 4:47 AM, Juergen Schoenwaelder < j.schoenwael...@jacobs-university.de> wrote: > On Sun, Jul 26, 2015 at 04:17:26AM -0700, Andy Bierman wrote: > > On Sun, Jul 26, 2015 at 12:16 AM, Juergen Schoenwaelder < > > j.schoenwael...@jacobs-university.de> wrote: > > > > > On Sat, Jul 25, 2015 at 05:17:11PM -0700, Andy Bierman wrote: > > > > Hi, > > > > > > > > I would like to open another issue for YANG 1.1, > > > > because I don't want to have 1.1 and then 1.2 right away. > > > > The NETMOD WG should evaluate the different ways to > > > > support ephemeral state, based on Jeff's draft. > > > > > > > > > > The NETMOD WG did spent almost a full day face-to-face interim meeting > > > time in September 2014 on this and now we have a requirements I-D plus > > > a solution proposal that does not directly match what was discussed > > > back then. It is my understanding that the solution discussed in > > > September 2014 does not require changes to YANG 1.1. > > > > > > I2RS was aware of the YANG 1.1 timeline from the very beginning. YANG > > > 1.1 is gating other specifications and I am not interested to hold > > > everything off (including RESTCONF) because of I2RS. There are many > > > other customers of YANG 1.1 beyond I2RS. > > > > Yeah, it's too bad so many drafts are waiting on YANG. > > Support for I2RS got started but never finished. > > I care more about the costs of deploying tools and the extra complexity > > on readers, who need to know all the versions of YANG. > > The proposed solution changes one of the most important statments > > in YANG. Harding something to do as an afterthought. > > I do not think there is agreement on any solution yet. I heard also > about vendors implementing ephemeral state solutions that do not > require any changes to YANG (and that seem to be more inline with what > was discussed in September 2014). > I know there is not agreement on the solution yet. That is why it is an open issue. I2RS does not have to present NETMOD WG with a solution (even though they did present an acceptable solution). In order for I2RS to have the YANG validation rules that meet its use-cases, new text is needed. This text needs to be associated with data-nodes. I like the proposed solution of config=true,ephemeral,false because I know none of the existing text inadvertently applies to ephemeral nodes. I do not think YANG is fully specified wrt/ datastores because operational state and ephemeral nodes are not separated. An ephemeral datastore (and perhaps operational datastore) are needed to solve this problem. > > It should not take that long because the NETCONF WG (same people) > > have been spending almost all f2f and virtual interim time on I2RS. > > The YANG doctors concluded that ephemeral state > > was a general feature and not NETCONF specific. > > > > The problem with using YANG extensions for important protocol features > > is that the YANG spec says these statements MAY be completely skipped > > by a tool implementation. This is not acceptable for ephemeral state > > (or operational state either). > > I do not know what is to be addressed for operational state. > Then openconfig issues for starters. That does not have to be solved at the same time as ephemeral data. > > /js > Andy > > -- > 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
