On Sep 24, 2014:3:00 AM, at 3:00 AM, Juergen Schoenwaelder <[email protected]> wrote:
> 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.
Yes I agree. They are configuration objects. There might be two copies
of the same object across data stores not an inheritance relationship: say one
in the run-time/ephemeral, one in the persistent.
> 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.
They should use precisely the same data models with perhaps a sub-set
being actually implemented at any given time in the ephemeral one given that
some objects might not make sense in that context. In the diagram you drew in
the previous email I responded to, you showed this analogy very well I think.
--Tom
> 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/>
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
>
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
