There are at least two dimensions to your comment.
One aspect is that I2RS should not, and has tried not to, prescribe the
implementation mechanism to meet the requirements. The requirement is
ephemeral config, with a descriptive definition and identity and
priority aspects. The mechanism to meet that is up to whatever protocol
is to be used.
The other aspect that strikes me is that the NetConf WG is perfectly
free to conclude that they think that what is needed is a mechanism that
does not fully meet the I2RS requirements. If so, the I2RS group will
have to decide between changing its requirements and picking another
protocol.
As long as those points are understood by each side, we are fine.
Yours,
Joel
On 6/16/15 7:31 PM, Andy Bierman wrote:
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]
<mailto:[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]
<mailto:[email protected]>]
Sent: Wednesday, June 10, 2015 8:45 AM
To: Jeffrey Haas
Cc: Susan Hares; [email protected] <mailto:[email protected]>; 'Joel M.
Halpern'; [email protected] <mailto:[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] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
