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
