So I understand the practical implication of a WG being behind schedule and by no means do i want to contribute to that. One approach that Tom Petch had suggested is to focus on use cases. The idea of what model/protocol is used can be going on in parallel. Input from the use cases is useful to help define what protocol model used.
cheers, jamal On Tue, Apr 22, 2014 at 7:43 AM, Benoit Claise <[email protected]> wrote: > Dear all, > > I've been spending the last 2 hours reading that full email thread, up to > this time. > Not sure to which email I should reply, so here am I, top posting. > > + 1 on YANG for the data model language. > What counts at the end of the day is a consistent data model language for > configuration, because implementing a proxy for different data model > languages is a pain, time consuming, and error-prone. > Ideally, we should have a consistent information model language, but the > industry/standards are not there yet. Not even sure they will even arrive > there one day. > > Looking at the life cycling of specifying a new language, implementing it, > deploying it, and developing tools around it (I have SMI and YANG in mind), > having a new data model language for I2RS only is not practical. And the > more we wait, the more obvious the solution is. > I know, it's not about a technical argument any longer (those have been > made on the lits already). > Let's look at the WG deliverables: > Jul 2013 > Request publication of an Informational document defining the problem > statement > Jul 2013 > Request publication of an Informational document defining the high-level > architecture > Aug 2013 > Request publication of Informational documents describing use cases > Sep 2013 > Request publication of an Informational document defining the protocol > requirements > Sep 2013 > Request publication of an Informational document defining encoding > language requirements > Feb 2014 > Request publication of Standards Track documents specifying information > models > Feb 2014 > Request publication of an Informational document providing an analysis of > existing IETF and other protocols and encoding languages against the > requirements > Feb 2014 > Consider re-chartering > > The least we can say is that the WG is late. > I observe that after 1 year and 3 months after the WG creation, we still > don't have the problem statement/architecture/requirements: that explains, > whether we like it or not, why the business reasons are getting more and > more important compared to the technical arguments. > Didn't we see a few comments lately about the IETF not being relevant > because we're too slow? > Maybe the IESG should be stricter: "no problem statement with a year, WG > closed", but I guess I'm diverging :-) > > Once YANG is selected, NETCONF/RESTCONF for the protocol is the next > logical step, even if I believe that in practice, we'll see different > devices speaking different languages. > > Regards, Benoit (as a contributor) > > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs > >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
