Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo

[Kent Watsen <[e-mail]>]

>>>> 2) It doesn't say anything about how the opstate data is stored on the
>>>>    server.  The opstate data is not modeled at all.  This approach
>>>>    only defines a presentation-layer format for how opstate data can
>>>>    be returned via an RPC.  The server is free to persist the opstate
>>>>    data anyway it wants, perhaps in an internal datastore called
>>>>    'operational-state' or in an uber-datastore with the opstate data
>>>>    flagged with a datastore='oper-state' attribute.  Regardless, it's
>>>>    an implementation detail, and the conceptual datastore model is
>>>>    preserved.
>>> 
>>> You are essentially defining a new operation, but do it by modifying the
>>> semantics of an existing one.  I don't think this is a good idea; it is
>>> better to define a new rpc.
>> 
>> [Xufeng] Is using a new rpc is acceptable? If so, this could be a viable
>> option.
>
>The draft-ietf-netmod-revised-datastores proposes a new rpc (maybe
><get-data>) to return data from the new operational-state datastore.
>This is IMO better than adding opstate nodes to the reply to a
><get-config> request.


Martin,

Going back your earlier "better to define a new rpc" comment, I fail to
see how this proposal is significantly different than RFC 6243.

If not this, then the new RPC would be something like <get-config-ex>
more than the planned <get-data>, as the goal is to return 'running'
+ "some opstate" (not just opstate).

Still, in looking the the pros/cons, Option 1 appears stronger - only
the authors don't like the idea of having to rewrite their models
later...

Kent