On Mon, Sep 22, 2014 at 05:05:46PM -0400, Jeffrey Haas wrote:
> - This "shadowing" behavior avoids issues in the existing yang by not
> requiring additional language semantics that would require mechanisms to
> cross-reference between datastores. (One might observe this is somewhat
> similar to Object Oriented programming where the configuration state
> serves as a "base class" with ephemeral configuration extending that
> base. A different analogy is the union filesystem semantic.)
I believe the OO analogy is largely mis-leading, I think the union
filesystem semantics are much closer.
> Possible yang 1.1 implications: If the above model works, the discussed
> configuration semantic may be the previously discussed
> "config (false|true|ephemeral);"
My understanding that both the config datastore and any ephemeral
datastores largely use the same data model (or schema). So config
true|false remains unchanged - the difference is the datastore you
write to.
> It is noted, however, that introducing something like a secondary identity
> would require changes to SSH and/or TLS and may be somewhat difficult to
> make the case to the owning working groups.
I do not follow here. The secure transport delivers what NETCONF calls
a username, the identity of the NETCONF client. If this client acts on
behalf of another application (the secondary identity), then this
identity is meta data should be attached to the information submitted
to the ephemeral datastore. I do not see why this would lead to any
changes to SSH or TLS.
> Some discussion was given to the filtering considerations. Extending the
> filtering options of the ietf-inet-types module may be appropriate.
> [Juergen, is this an action item for yang 1.1?]
The YANG 1.1 issue Y20 is about adding a set of built-in xpath
functions. I like to ask I2RS to tell us what functions they need. We
do have IP prefix-length matching on our radar. If other functions are
required, please let us know as soon as possible.
Now, this mostly is about the xpath function set that can be used in
must and when expressions. You probably want to use them also in
filtering expressions in the protocol. This is where things again
become a protocol issues. Note that RFC 6241 says on page 17:
The XPath expression is interpreted in the following context:
[...]
* The function library is the core function library.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
