On Wed, Jun 1, 2016 at 1:32 PM, Susan Hares <[email protected]> wrote: > > Ah.. Interesting viewpoint on the word "overwrite". And I find nothing > wrong with your viewpoint. > > If i2rs only config does not resolve to installable state, how would you > handle it. Is this a case where i2rs config value does not exist so local > config is used? I am showing partial installation of i2rs rib model. > > If I can see how this works, maybe I can find a way to understand > juergen's model. > > Why would this work? You mean the I2RS agent incorrectly accepts an edit that cannot be installed because it is invalid, or there are insufficient resources?
This is the same as the "no-validate" case for I2RS. If there is a "when IPv4" clause that is ignored by the agent, such that the agent appears to accept "IPv4" fields in an "IPv6" entry, what happens? (IMO this is 1 reason the no-validate mode is so broken). Does the hopelessly invalid data stay in the ephemeral datastore? Does the agent attempt to (incorrectly) apply the IPv4 parameters to an IPv6 entry or does the agent ignore the data (i.e., must be validating the data somehow if it knows to ignore it) Sue > Andy > > Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone > -------- Original message -------- > From: Andy Bierman <[email protected]> > Date: 6/1/2016 3:11 PM (GMT-05:00) > To: Susan Hares <[email protected]> > Cc: Linda Dunbar <[email protected]>, [email protected], Juergen > Schoenwaelder <[email protected]>, Alia Atlas < > [email protected]>, Benoit Claise <[email protected]>, Jeffrey Haas < > [email protected]> > Subject: Re: [i2rs] Can I2RS focus on the "Over the Wire" data structure , > not on how end point handle the "DataStore"? > > > > On Wed, Jun 1, 2016 at 12:04 PM, Susan Hares <[email protected]> wrote: > >> Andy >> >> We currently are specifying i2rs rib model which can overwrite the local >> config. Implementations experience will provide us with input on the >> protocols. >> >> > I don't view it that way. > The local config remains untouched throughout. > The higher priority ephemeral config value is used instead of the local > config value. > The operational state should reflect that ephemeral config is overriding > the local config. > The data model for the I2RS version does not have to be the local config > model. > > > >> Sue >> >> >> > Andy > > >> >> Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone >> -------- Original message -------- >> From: Linda Dunbar <[email protected]> >> Date: 6/1/2016 12:34 PM (GMT-05:00) >> To: Andy Bierman <[email protected]> >> Cc: [email protected], Juergen Schoenwaelder < >> [email protected]>, Alia Atlas <[email protected]>, >> Benoit Claise <[email protected]>, Jeffrey Haas <[email protected]>, Susan >> Hares <[email protected]> >> Subject: Re: [i2rs] Can I2RS focus on the "Over the Wire" data structure >> , not on how end point handle the "DataStore"? >> >> Andy, >> >> >> >> Agree with your suggested approach. >> >> >> >> Linda >> >> >> >> *From:* Andy Bierman [mailto:[email protected]] >> *Sent:* Tuesday, May 31, 2016 9:05 PM >> *To:* Linda Dunbar >> *Cc:* Jeffrey Haas; Benoit Claise; [email protected]; Juergen Schoenwaelder; >> Susan Hares; Alia Atlas >> *Subject:* Re: Can I2RS focus on the "Over the Wire" data structure , >> not on how end point handle the "DataStore"? >> >> >> >> Hi, >> >> >> >> If your graphic advice means "the requirements are good enough, move on" >> >> then I agree. >> >> >> >> The datastore framework would be nice to have, but it is very close >> >> to the implementation details. It is also attempting to be a superset of >> all >> >> "accepted" implementation choices. >> >> >> >> By "on the wire" we usually mean a protocol specification. >> >> IMO, all that is needed (for editing) is a set of RESTCONF extensions. >> >> Some people want to describe the I2RS desired behavior wrt/ how it >> >> interacts with the local config. (and many more features...) >> >> >> >> Perhaps a good first step would be ephemeral data models that do not >> >> interact with the local config at all. I2RS is the only protocol of >> concern and the >> >> highest priority client. I2RS just needs to support read/write/notify of >> ephemeral data. >> >> If this is not acceptable then be prepared to wait until all the >> framework stuff is settled >> >> and standardized. >> >> >> >> >> >> Andy >> >> >> >> >> >> >> >> >> >> On Tue, May 31, 2016 at 4:09 PM, Linda Dunbar <[email protected]> >> wrote: >> >> IETF has been successful for past 20 years in focusing on “Over the >> Wire” data structure. It would be so much cleaner and straight forward if >> the YANG modules developed by I2RS focusing on the “Over the Wire” data >> structure (and with NETMOD to focus on other aspects). >> >> The “I2RS ephemeral State” has the needed description for the desired >> behavior of the data received over I2RS interface. If we follow the IETF >> practice, it is good enough. >> >> Internal implementation framework is always controversial, hard to >> converge, usually ending up with a document (if completed) that is too big >> and difficult to read. >> >> >> >> Providing some source code to show the internal implementation would be >> much more useful as a reference implementation. >> >> >> >> The draft-schoenw-netmod-revised-datastores-00 is on the architectural >> framework for datastores as they are used by network management protocols. >> IMHO, how data stores are used are internal to the end points. >> >> >> >> [image: >> http://www.urbanblisslife.com/wp-content/uploads/2012/10/Done-is-Better-Than-Perfect.jpg] >> <http://www.google.com/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&uact=8&ved=0ahUKEwj50KWat4XNAhULxGMKHRhqDPQQjRwIBw&url=http%3A%2F%2Fwww.urbanblissmedia.com%2Fentrepreneur-rules-done-is-better-than-perfect%2F&psig=AFQjCNGKEiPB2iHSqyBiF5609pd72H0L7w&ust=1464822503865777> >> >> >> >> Linda Dunbar >> >> >> >> *From:* i2rs [mailto:[email protected]] *On Behalf Of *Andy Bierman >> *Sent:* Tuesday, May 31, 2016 4:09 PM >> *To:* Jeffrey Haas >> *Cc:* Benoit Claise; [email protected]; Juergen Schoenwaelder; Susan Hares; >> Alia Atlas >> *Subject:* Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - >> 11:00am - Topic: Ephemeral State Requirements >> >> >> >> Hi, >> >> >> >> I am not convinced the IETF can be forced to function as if it were >> >> a dev-group in some corporation. This is a volunteer organization so >> >> usually solution proposals come from people who have created a solution >> >> and they want the WG to standardize it. >> >> >> >> >> >> Andy >> >> >> >> >> >> On Tue, May 31, 2016 at 12:51 PM, Jeffrey Haas <[email protected]> wrote: >> >> Andy, >> >> On Tue, May 31, 2016 at 11:41:59AM -0700, Andy Bierman wrote: >> > At some point the WG needs to agree on normative text instead of >> iterating >> > on requirements forever. >> >> IMO, it would be in I2RS's best interests if netconf/netmod provided >> drafts >> in appropriately normative language covering I2RS requirements. However, >> we've been in a pathological cycle of: >> "We don't understand, please give us requirements" >> "We don't understand your requirements" >> "You provided examples with your requirements that appear to be attempts >> to >> change our protocol - don't do that." >> >> The most recent revised-datastore draft would be a good place to document >> where netmod(/netconf) believes ephemeral datastores (if that's the >> instantiation) could live, and also how ephemeral configuration state >> could >> interact with candidate, startup and running configuration. >> >> yang-push covers much of our desired pub-sub behavior. (Yay!) >> >> Discussion is required for how to tag security considerations impacting >> transport into the yang model, in particular for notification. >> >> Proposals for secondary identity and priority are also needed. >> >> -- Jeff >> >> >> >> >> > > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs > >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
