Hi,
Kent Watsen <[email protected]> wrote:
> Hi All,
>
> It's been quiet on the list as a small group of us (Alex, Xufeng,
> Pavan, and myself) went offline to discuss for a bit before bringing
> back to the group, which I'm doing now.
>
> Regarding resolving the modeling the issue, we went through nearly a
> dozen ideas that we've narrowed down to two. We discussed the
> pros/cons, but since we each emphasize different values, we were
> unable to reach a consensus amongst ourselves. We're hoping that
> bringing the discussion here will bring more perspectives and resolve
> this issue.
>
>
> OPTION 1: separate /foo and /foo-state trees
> --------------------------------------------
>
> This option was/is described here:
> https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html.
>
> PROS:
> a) does NOT break legacy clients (how we got here)
> b) consistent with convention used in many IETF modules
> c) able to show if/how opstate may differ from configured values
>
> CONS:
> a) questionably valid YANG leafref usage
What does this mean?
> b) complex server implementation (to handle require-instance false)
Can you elaborate on this one?
> c) eventually the module would need to migrate to the long-term
> solution, which would result in needing to also rewrite all
> modules that have augmented it (e.g., ietf-te-topology).
> d) leafref path expressions really only work for configuration data,
> though a clever server could have a special ability to peak at
> the opstate values when doing validations. Of course, with
> require-instance is false, the value of leafref based validation
> checking is negated anyway, even for config true nodes, so this
> may not matter much.
>
>
>
> OPTION 2: explicit client-option to also return tagged opstate data
> -------------------------------------------------------------------
>
> This option takes a couple forms. The first is module-specific and
> the second is generic. In both cases, the idea is modeled after the
> with-defaults solution (RFC6243), wherein the client passes a special
> flag into <get-config> causing the server to also return opstate data,
> having a special metadata flag set, intermingled with the
> configuration
> data.
>
>
> 2A: Module-specific version
>
> module foo {
> import ietf-netconf { prefix nc; }
> import ietf-yang-metadata { prefix md; }
> md:annotation server-provided {
> type boolean;
> }
> container nodes {
> config true;
> list node {
> key "name";
> leaf name { type string; }
> leaf dependency {
> type leafref {
> path "../node/name"
> require-instance false;
> }
> }
> }
> }
> augment /nc:get-config/nc:input {
> leaf with-server-provided {
> type boolean;
> }
> }
> }
I don't think this solution is substantially different from the
solution in draft-ietf-i2rs-yang-network-topo-10. You have just moved
a config false leaf to a meta-data annotation. This solution suffers
from the same problems as the solution in
draft-ietf-i2rs-yang-network-topo-10.
/martin
>
> For instance:
>
> <get-config>
> <source>
> <running/>
> </source>
> <with-server-provided/>
> </get-config>
>
> <data>
> <nodes>
> <node>
> <name>overlay-node</name>
> <dependency>underlay-node</dependency>
> </node>
> <node foo:server-provided='true'>
> <name>underlay-node</name>
> </node>
> </nodes>
> </data>
>
> PROS:
> a) does NOT break legacy clients (how we got here)
> b) having all data in one merged tree is simpler to process
> than two separate queries.
> c) module doesn't have to be rewritten for revised-datastores;
> the 'with-server-provided' switch would just not be passed
> by new opstate-aware clients.
>
> CONS:
> a) inconsistent with convention used in many IETF modules
> b) unclear how to model 'with-server-provided' for RESTCONF
> (just use a description statement to define a query param?)
> c) unable to return the opstate value for any configured node
> (is it needed here?)
> d) requires server to support metadata, which is a relatively
> new concept and maybe not well supported by servers.
> e) only changes presentation-layer (doesn't change the fact
> that 'server-provided' data is not configuration), thus the
> leafref path expressions still don't work quite the way as
> desired, though a clever server could have a special ability
> to peak at the opstate values when doing validations. Of
> course, with require-instance is false, the value of leafref
> based validation checking is negated anyway, even for config
> true nodes, so this may not matter much.
>
>
>
>
> 2B: Generic version
>
> The generic version is much the same, but rather than letting the
> solution be limited to this one module, the idea is to generalize
> it so it could be a server-level feature. Having a generic RPC to
> return data from more than one DS at a time was something that was
> discussed ~1.5 years ago when we were kicking off the opstate effort.
>
> The PROS and CONS are similar, but there are additional CONS in the
> generic case. The main ones being 1) how to simultaneously return
> both the config and opstate values for a node (split at the leaves)
> and 2) how to handle some YANG statements such as presence containers
> and choice nodes. For this reason, (2B) is NOT considered a viable
> solution and is only here so that it's clear that it was discussed.
>
>
>
> If there are any other options people want to suggest, please do so
> now!
>
> Thanks,
> Kent
>
>
>
> _______________________________________________
> i2rs mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/i2rs
>
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
