Hi,
I am still fairly confused how the running configuration interacts
with ephemeral data, but I will wait to see some concrete solution
proposals.
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.
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.
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.
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
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>
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
