Hi Kent, and other authors,
I've taken a quick look through this draft, and hence have a few
comments/questions below. Some of these comments are the same that I
made in reference to the previous version of this draft.
1. Minor nit: I think that the key point of this solution is that it is
introducing a new applied configuration datastore, but this draft
doesn't seem to state that anywhere in the introduction or abstract.
E.g. the first reference to the applied configuration datastore is in
section 5.1.
2. Personally, for a datastore solution, I would prefer if the new
datastore was for the intended configuration, and that the applied
configuration was stored in the same datastore (running?) as all the
rest of the operational state.
If the logical flows of system information is as follows:
[candidate] -> intended cfg -> applied cfg -> derived state
Then it seems strange to bundle intended cfg & derived state together in
one datastore, and to have applied-cfg separate (a bit like an unwanted
step child).
3. For the related-state statement, I think that this statement would be
better as related-config and expressed in the reverse direction.
To give a contrived example of problems with related-state based on the
example in 4.1.1:
Say I defined a new module that augments the ex-interfaces module that
provides some further operational state for an interface. In my
specific example it wants to report the actual L2 MTU/MRU values
programmed in the hardware. (This could differ from a configured MTU to
take into vary 802.1Q VLAN tag overheads or perhaps other slop).
module ex-controller {
namespace "http://example.com/controller";;
prefix ctrlr;
import ex-interface {
prefix ex-if;
}
import ietf-yang-related-state {
prefix yrs;
}
// Standard module definition.
augment "/ex-if:interfaces/ex-if:interface-state" {
when "if:type = 'ianaift:ethernetCsmacd'";
leaf hardware-mru {
type { uint16; }
description "Actual MRU programmed in hardware";
}
leaf hardware-mtu {
type { uint16; }
description "Actual MTU programmed in hardware";
}
}
// Separate augmentation required for each related-state
// statement.
augment "/ex-if:interfaces/ex-if:interface/ex-if:mtu" {
when "if:type = 'ianaift:ethernetCsmacd'";
yrs:related-state
"/interfaces-state/interface/name=current()/name/hardware-mtu";
}
// Separate augmentation required for each related-state
// statement.
augment "/ex-if:interfaces/ex-if:interface/ex-if:mtu" {
when "if:type = 'ianaift:ethernetCsmacd'";
yrs:related-state
"/interfaces-state/interface/name=current()/name/hardware-mru";
}
}
Here you will see that I would need a separate augmentation statement to
set up every related-state binding. Further, YANG would need to be
modified to even allow such an augmentation of a leaf.
If you reverse the sense of the binding to "related-config" then I think
that these problems disappear.
4. For section 5.4, get-state operation, it might be useful to clarify
that if neither of the applied/derived options are specified then the
data that is returned covers both the applied configuration and derived
state (i.e. the data that is returned spans two datastores).
5. Am I correct to presume that this draft doesn't provide any support
to return intended config, applied config & derived state all in a
single request? I appreciate that this isn't included as a formal
requirement - but part of me wonders whether this might have been an
oversight in the requirements.
6. I can understand the decision of get-diff to reuse edit-config or
YANG patch, but I'm not sure that this makes it particularly easy for
clients to then process that data. I might be wrong, but I suspect that
a solution that returns the values of the intended and applied config
nodes in an easier to relate way may be preferable (perhaps something
along the lines of the encoding proposed in
draft-wilton-netmod-opstate-yang).
Thanks,
Rob
On 02/02/2016 17:54, Kent Watsen wrote:
Hi All,
I didn’t receive the usual announcement CC-ed to the netmod list, so I’m
replying to this one sent to the id-announce list instead.
Anyway, this morning I posted -01 of this draft and then shortly after -02 to
fix some cleanup items I only noticed after -01 was posted :ooops:
Either way, this update is an overhaul to the original draft posted last
September.
Kent
On 2/2/16, 10:30 AM, "[email protected]" <[email protected]>
wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
Title : Operational State Enhancements for YANG, NETCONF, and
RESTCONF
Authors : Kent Watsen
Andy Bierman
Martin Bjorklund
Juergen Schoenwaelder
Filename : draft-kwatsen-netmod-opstate-02.txt
Pages : 27
Date : 2016-02-02
Abstract:
This document presents enhancements to YANG, NETCONF, and RESTCONF
satisfying the requirements set forth in Terminology and Requirements
for Enhanced Handling of Operational State.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-kwatsen-netmod-opstate/
There's also a htmlized version available at:
https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-kwatsen-netmod-opstate-02
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.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
I-D-Announce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
