On Tue, Jun 16, 2015 at 5:03 PM, Joel M. Halpern <[email protected]> wrote:
> 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 impact on the existing documents needs to be examined by the WG. This is where datastore vs. tag details could be quite different. 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. > I don't know what the WG consensus will be, but IMO I2RS needs to distinguish the parts that need signalling events from the parts that need access to the YANG notifications. These are not the same. I know the implementation requirements for RFC 5277 fairly well and I am recommending against its use for signalling events. Other than that I see no issues supporting I2RS requirements. > Yours, > Joel > > Andy > 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
