Hi, I think I understand Juergen's concerns about I2RS requirements. Some of them are not specified as functionality, but rather as solutions.
Most notably, the NETCONF WG needs to decide the best way to integrate ephemeral configuration into the existing framework. That may end up being a query-tag or a datastore or something new, but that is a standards implementation detail, not a requirement. Andy On Wed, Jun 10, 2015 at 7:52 AM, Susan Hares <[email protected]> wrote: > Juergen: > > <chair hat on> > The I2RS WG still needs a written draft proposing how this would work to > have an effective discussion. > <chair hat off> > > If it has these benefits you mention, it would be good to write itup. > > Best wishes, > > Sue > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:[email protected]] > Sent: Wednesday, June 10, 2015 8:45 AM > To: Jeffrey Haas > Cc: Susan Hares; [email protected]; 'Joel M. Halpern'; [email protected]; > 'Alia Atlas' > Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015) > > On Tue, Jun 09, 2015 at 08:34:44PM -0400, Jeffrey Haas wrote: > > Juergen, > > > > On Fri, Jun 05, 2015 at 02:35:33PM +0200, Juergen Schoenwaelder wrote: > > > Frankly, there is no full alternate proposal either. The overlay > > > model has been discussed at quite some detail at a NETMOD interim. I > > > am happy to point at the meeting minutes. The question perhaps > > > really is whether (a) I2RS has requirements to be addresses and > > > NETMOD/NETCONF looks at solutions or whether (b) I2RS casts a > > > solution into stone to be run through the NETCONF working group or > > > whether (c) creates a solution on its own independently of any other > > > NETMOD/NETCONF requirements. > > > > During that interim, we did discuss a number of details regarding > overlays. > > We also discussed a number of issues that overlays have when ephemeral > > state was not disjoint from static configuration state. > > > > As a result of that discussion and further presentation at a later > > I2RS meeting regarding the Venn diagram interactions of static and > > ephemeral configuration state, my latest draft attempts to codify > > behaviors that shouldn't be problematic in either proposed form or in > overlay. > > > > The point of frustration for all parties seems to be that while the > > paragraph from you above seems to indicate that there is some > > understanding of the requirements, I am unable to provide text that > > illustrates either requirement or potential solution to the matter. > > All parties are spending their resources saying "I think I understand > this > point, but this is wrong." > > If the points are understood well enough to disagree with potential > > solutions, I would suggest that they may be clear enough for both > > protocol and data modeling experts to contribute text that either > > clarifies the requirements to the collective experts' needs or > > similarly a proposal documenting a solution. > > > > These fundamental failures suggest a few possibilities: > > 1. There is a complete failure to properly communicate. If so, we should > > find replacement parties to carry on the work. We had some declared > > interest in a design team. Sue has, I believe, contacted people about > it. > > Those individuals should take over the work. > > 2. Netconf/restconf/yang are inappropriate tools and we have wasted the > > Working Group's time. I don't believe this as my employer has > > ephemeral datastores in an upcoming release. It does not, however, > have > > full I2RS properties such as priority or secondary-id. > > 3. The relevant experts are trying to get I2RS ephemeral state work to > die. > > If so, let's have the relevant discussion either publicly or privately > so > > we can stop wasting people's IETF cycles. > > I can assure you that, at least from my side, 3. is not the case. > > My perspective is likely slightly different from yours since I (not > surprisingly) care more about NETCONF/RESTCONF and YANG than I2RS > itself: If we add writable ephemeral state to NETCONF/RESTCONF (and perhaps > YANG), I believe we will have to envision more usages of that feature than > just I2RS. Looking at things from a wider and longer term perspective, I am > concerned about (i) duplicated data modeling work and I am concerned about > (ii) use-case specific merge logic that needs to be supported. From this > perspective, the overlay model has been prety attractive because it comes > with a single merge logic and it minimizes (or even eliminates) duplicated > data modeling work. > > /js > > PS: Out of curiosity: Can you disclose what your employer's ephemeral > datastore solution coming out as a product soon looks like? Is it > closer to an overlay approach or is it closer to what you > described in your I-D? > > -- > 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/> > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
