On Tue, Jun 23, 2015 at 1:29 PM, Susan Hares <[email protected]> wrote:
> Andy: > > > > We will look for concrete proposal in the NETCONF/NETMOD group. > I doubt this will work without direct involvement from an I2RS proponent who really plans to implement the protocol in their products. I think about 5 or 6 of us have 7 or 8 different solutions in mind ;-) Otherwise you would have probably already seen a draft posted. > > The proposal for “config = ephemeral” came out of discussion with the > netconf group. Again, I hope there will be a concrete proposal from that > group. > > > OK, then I will assume the text that looks like specific YANG or XML is really just a shorthand for the concept. The YANG syntax is the easiest part. The text related to YANG validation, error handling, XPath evaluation, etc. is the hard part. Without a clear consensus on the properties, the YANG text will be difficult to write. I am hopeful that the protocol details will be more clear once persistent data vs. ephemeral data vs. operational data is sorted out. > Sue > > > Andy > *From:* i2rs [mailto:[email protected]] *On Behalf Of *Andy Bierman > *Sent:* Tuesday, June 23, 2015 3:05 PM > *To:* Susan Hares > *Cc:* [email protected]; Alia Atlas > *Subject:* Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt > > > > Hi, > > > > I am still fairly confused how the running configuration interacts > > with ephemeral data, but I will wait to see some concrete solution > > proposals. > > > > [sue]: Hopefully this will come out of netconf. > > > > The proposal does not mention what changes would be required to > > YANG to add "config=ephermal". There are 1000s of lines > > of text that would be impacted by this change. This change > > might break a YANG 1.0 tool, which would violate the NETMOD charter > > for YANG 1.1. > > > > [Sue]: Do you have an alternate proposal. > > > > This solution does seem to suggest that I2RS can never alter any > > value that is config=true. These nodes can only be changed by NETCONF. > > This of course means that no client priority or secondary identity > > could be supported for config=true nodes. Ephemeral data cannot > > really rely on any local config, since any client can alter it at any time. > > This might be fine, but I2RS clients need to be careful not to > > assume any particular running configuration in order to work. > > You cannot safely add an ephemeral leaf to a configuration container > > or list. > > [Sue]: You understand the meaning of ephemeral. The I2RS client will > > Have to set the configuration via a normal netconf configuration. > > > > > > It also means that I2RS can never be used to override a config=true > > value (since the data models do not overlap). A special add-on I2RS > > module would be needed to define the specific I2RS override knobs. > > > > [yes – this is correct]. > > > > sec 6.2 adds client priority to the NACM group list. > > Users can be in multiple groups, so you need to specify how > > the client priority is determined as the group membership > > configuration is changed. > > > > +--rw groups > > | +--rw group [name] > > | +--rw name group-name-type > > | +--rw user-name* user-name-type > > | +--rw i2rs:i2rs-priority i2rs-priority-type > > > > [Sue: Could you provide more details on this fact. I was concerned > because Martin indicated the group membership could be changed to the > highest group. Would it be better on the client? > > > Sec 6.3. shows the client setting its own priority. > This does not seem correct if the administrator is supposed to > set the client priorities. > > > > <foo xmlns:i2rs="https://ietf.example.com/i2rs"; > > i2rs:i2rs-secondary-identity="user1" i2rs:i2rs-priority="47"> > > ... > > </foo> > > > > [Sue: It is the assumed the client is resetting its priority because the > administrator changed something.] > > > > Great questions – keep asking more! > > > > Andy > > > > > > > > > > On Tue, Jun 23, 2015 at 11:37 AM, Susan Hares <[email protected]> wrote: > > Andy: > > > > Thank you for the feedback on draft-ietf-i2rs-pehemeral-state-00.txt. > This document is now a WG document – so suggestions on changing the text > are welcome. It is a work-in-progress so I appreciate your help in > refining this draft. Please suggest alternate text for the draft. My > comments on individual points are below. > > > > At the front of this document are the top 10 requirements for the I2RS > protocol. All other details within this draft are to provide more detail > to these requirements, and do not dictate a solution to the NETCONF/NETMOD > working group. I hope my message to netconf/netmod/I2rs further clarifies > this point. > > > > The I2RS 6/24/2015 interim will continue to discuss the I2RS requirement > on web-ex. Please join us at the interim and continue to discuss the > requirements on this mail list. > > > > Sue Hares > > > > *From:* i2rs [mailto:[email protected]] *On Behalf Of *Andy Bierman > *Sent:* Tuesday, June 23, 2015 2:09 PM > *To:* [email protected] > *Cc:* [email protected]; [email protected] > *Subject:* Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt > > > > Hi, > > > > This draft seems to propose very specific solutions, not requirements. > > > > > > This text is in the section explaining why an ephemeral datastore won't > work: > > > > The most obvious disadvantage of such a fully separate datastore is > > that interaction with the network element's operational or > > configuration state becomes significantly more difficult. > > > > I don't see any evidence or examples in the draft to support this claim. > > > > > > [Sue: This is correct. The authors recorded what they heard at the I2RS > interims. If you would like to clarify this – please do. I have heard > this is implementation dependent. Is this true? > > > > The requirements do not make it clear how a YANG module is implemented > > by I2RS vs. implemented by NETCONF or RESTCONF. It is not clear at all > > how YANG data-def-stmts are handled correctly by each protocol. > > Perhaps you can provide some data model examples. > > > > [Sue: I have given the I2RS yang module list in the netconf announcement > for the I2RS RIB, I2RS Topology drafts, and I2RS FB RIB. These data > modules provide you with some examples, and I welcome a specific discussion > of these modules on the list or at the I2RS interim. > > > > Andy > > > > > > > > On Tue, Jun 23, 2015 at 9:52 AM, <[email protected]> wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Interface to the Routing System Working > Group of the IETF. > > Title : I2RS Ephemeral State Requirements > Authors : Jeff Haas > Susan Hares > Filename : draft-ietf-i2rs-ephemeral-state-00.txt > Pages : 13 > Date : 2015-06-23 > > Abstract: > This document covers requests to the netmod and netconf Working > Groups for functionality to support the ephemeral state requirements > to implement the I2RS architecture. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-00 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs > > > > >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
