Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt

[Robert Wilton <[e-mail]>]

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, "[e-mail]" <[e-mail]> 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
>> [e-mail]
>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod