Robert Wilton <rwil...@cisco.com> wrote: > Hi Kent, > > I've a few comments on draft-kwatsen-netmod-opstate-00: > > 1) Having a related-state statement seems to be a good solution for > binding oper nodes to config nodes that are not directly related in > the data tree. > > But I note that the binding is attached to the config node. I had > incorrectly read/assumed that the binding would be attached to the > operational node referring back to the config node.
We discussed this as well. We interpreted the requirement from openconfig to be from config to state though. Maybe it would be useful to have both 'related-state' and 'related-config'. > A couple of potential advantages of attaching the binding on the > oper node instead of the config node may be: > > - There may be cases where many oper nodes depend on a few config > nodes (e.g. lots of oper nodes could choose to depend on the IP > address configured on an interface), so spreading out the > related-state statements may be beneficial. > > - I think that it is more likely that oper nodes will be in other > modules that depend on, or augment, a module with the dependent > config node. Obviously the related-state binding can't be written > directly inline on the config node because the module dependency > would be the wrong way round. This could be achieved by augmenting > the config node with a related-state statement, but this would seem > to be less clear and more verbose than putting the related-state > statement on the oper node itself. > > > 2) <get-state> Operation. > Yes, I agree that this is a good addition to NETCONF. > > > 3) The Applied Configuration Capability: > Using a separate datastore to differentiate between intended and > applied cfg seems like an OK solution to me. > > But for a separate datastore solution, it would feel more natural > (at least to me) to put the intended-cfg in a separate datastore, > and having the applied-cfg and derived-state in the default running > datastore. But running is (sometimes) writable, whereas applied config is always read-only. I rather map intended to running, and then define new protocol operations so that the client can retrieve the necessary data properly (essentially making current <get> less useful). /martin > My reasoning for this is that logically the flow of config information > through the system is: > [ (A) candidate cfg ] -> (B) intended cfg -> (C) applied cfg -> (D) > derived state. > > Hence, it seems strange to me that (A - candidate) and (C - applied) > would each be in separate datastores but (B - intended) and (D - > derived) are together in the running datastore. > > I can appreciate that there may be some issues with making (B - > intended) a separate datastore (i.e. what does an edit-config > request mean on the running datastore?), but I think that it has the > advantage that a <get> request on the running datastore would return > the contents of (C - applied) and (D - derived) which is arguably > more generally useful to an NMS dealing with an async system that > presumably already knows the contents of (B - intended). > > Cheers, > Rob > > > On 03/09/2015 01:23, Kent Watsen wrote: > > For next week's interim meeting, but feel free to post comments before > > then ;) > > > > Cheers, > > Kent > > > > > > On 9/2/15, 7:55 PM, "internet-dra...@ietf.org" <internet-dra...@ietf.org> > > wrote: > > > >> A new version of I-D, draft-kwatsen-netmod-opstate-00.txt > >> has been successfully submitted by Kent Watsen and posted to the > >> IETF repository. > >> > >> Name: draft-kwatsen-netmod-opstate > >> Revision: 00 > >> Title: Operational State Enhancements for YANG, NETCONF, and > >> RESTCONF > >> Document date: 2015-09-02 > >> Group: Individual Submission > >> Pages: 12 > >> URL: > >> https://www.ietf.org/internet-drafts/draft-kwatsen-netmod-opstate-00.txt > >> Status: > >> https://datatracker.ietf.org/doc/draft-kwatsen-netmod-opstate/ > >> Htmlized: > >> https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-00 > >> > >> > >> Abstract: > >> This document presents enhancements to YANG, NETCONF, and RESTCONF to > >> better support the definition of and access to operational state > >> data. > >> > >> Please note that it may take a couple of minutes > >> from the time of > >> submission > >> until the htmlized version and diff are available at tools.ietf.org. > >> > >> The IETF Secretariat > >> > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
