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
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs
