Hi Martin,
Speaking with the authors offline late last week, this discussion
regarding OPTION-2 came up, and I mentioned again my concerns for
CON 'c':
c) unable to return the opstate value for any configured node
...to which the Xufeng suggested we take your idea to heart.
Specifically, rather than augment <get-config>, let's look-ahead and
use the opstate <get-data> RPC (including the 'origin' attribute)
now. This way, <get-config> would return the configured value, while
<get-data> could return the applied value, as well as the system
generated/learned topology. So, as in previous fashion, I formally
submit OPTION 3:
OPTION 3: use new RPC <get-topo-data>, which is just like <get-data>
--------------------------------------------------------------------
This option defines a new RPC called <get-topo-data> that is fashioned
directly after the <get-data> RPC from the revised-datastores draft.
The RPC is renamed for fear of conflicting with any possible future
changes that may occur to the planned <get-data> RPC. The <get-topo-data> RPC
would take an optional 'with-origin-data' selector to return the
'origin' attribute.
PROS:
a) does NOT break legacy clients (how we got here).
b) ability to return the opstate value for any configured node.
c) minimal rewrite of the module for revised-datastores solution.
CONS:
a) seems like a shady thing for an IETF module to do.
b) would need to resolve other issues (e.g., how to support with
RESTCONF), which makes the draft quite a bit more than just
a module draft.
c) requires server to support metadata, which is a relatively
new concept and maybe not well supported by servers.
Thanks,
Kent
-------ORIGINAL MESSAGE-------
>>>> 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
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
