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