>>>> 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
