I would phrase the marking need slightly differently.
Given that it would seem onerous to expect all I2RS-supporting devices
to support ephemeral behavior for all parts of all models, we need some
way to clearly indicate what is expected.
Trying to do it as separate models seems difficult.
Marking elements in the model as ephemeral seems the clearest and most
efficient mechanism, but I am sure there are other alternatives.
Yours,
Joel
On 10/11/15 3:58 PM, Juergen Schoenwaelder wrote:
On Sun, Oct 11, 2015 at 11:10:16AM -0700, Andy Bierman wrote:
On Sun, Oct 11, 2015 at 10:51 AM, Juergen Schoenwaelder <
[email protected]> wrote:
On Sun, Oct 11, 2015 at 09:55:31AM -0700, Andy Bierman wrote:
On Sun, Oct 11, 2015 at 9:11 AM, Juergen Schoenwaelder <
[email protected]> wrote:
On Fri, Oct 09, 2015 at 04:13:03PM -0400, Susan Hares wrote:
The 10/7/2015 interim discussed the ephemeral portion of the protocol
1) Ephemeral state is not unique to zI2RS
2) The ephemeral datastore is a datastore holds
configuration that is intended to not survive a reboot.
Configuration as YANG config true or a subset thereof?
config=true nodes only.
good
Some way is needed to specify I2RS conformance for
a given YANG module, unless every persistent config leaf
is expected to also be supported as ephemeral data.
If not, a YANG "ephemeral-stmt" is probably needed, since
config=true is insufficient to support I2RS conformance.
One question is whether this needs to be inline in the data model or
not. If conformance is the goal, then you know what having things
defined inline has limits. If we would address conformance in more
general terms, perhaps I2RS conformance falls out as a special case.
One ephemeral datastore.
No client panes. That was to support caching, but
the architecture forbids caching, so that was taken out.
One ephemeral pane that overrides the running datastore
good
Identities? I assume you mean schema nodes, do you? Adding by
defining an YANG extension such as i2rs:ephemeral true? How does such
an i2rs:ephemeral true interplay with config true/false? What about
contexts for must/when expressions? Or is the idea to settle on
RESTCONF and to work with YANG patch?
I think a real keyword is needed not an extension.
Otherwise YANG groupings cannot be utilized w/ statements
that are refined in the uses-stmt to set the ephemeral flag.
I fail to understand the groupings argument.
The refine-stmt is defined to work on YANG statements, not external
statements.
RFC 6020bis says in section 7.13.2.:
o Any node can get refined extensions, if the extension allows
refinement. See Section 7.19 for details.
A YANG extension is (by definition) something external to the YANG language.
The WG needs to decide if the ephemeral property should be specific to
an I2RS YANG module or should be basic property of the YANG data modeling
language. YANG keywords must be supported and they do not need
to be imported from a YANG module to be used.
Or it is a common extension (that is the extension is not I2RS
specific but instead for everything that wants to use ephemeral
datastores).
Anyway, if the main purpose is to define a conformance level, it may
be worth thinking about adding a conformance mechanism that decouples
conformance requirements from the data model definition.
/js
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
