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).

> 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.

/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

Reply via email to