Andy:
We will look for concrete proposal in the NETCONF/NETMOD group. 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. Sue 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
