Re: [netmod] Comments on draft-ietf-netconf-nmda-netconf-05

[Juergen Schoenwaelder <[e-mail]>]

On Tue, Apr 24, 2018 at 01:09:07PM +0000, Rohit R Ranade wrote:
> Hi All,
> 
> Please find some comments for the draft.
> 
> 
> 1.       If "config-filter" leaf is not given for <get-data> whether we can add explicit text that both config=true and config=false nodes will be selected.

Well, if there is no filter, you do not filter. Is this not obvious?
 
> 2.       In the YANG module description for "config-filter" , also it is not clear about what happens if the leaf is not given in filter. I feel better we keep the style like RESTCONF RFC 8040 Section 4.8.1 , with "content" having  config/nonconfig/all

Why? Even in RESTCONF the content query parameter can be absent.

   If this query parameter is not present, the default value is "all".
 
> 3.       Regarding the "max-depth" parameter, I feel we should take the text about how "depth" is calculated for each node from RESTCONF RFC from Section 4.8.2 and add it to this draft. What will be depth of parent keys which are auto-selected when selecting on child nodes. Maybe some example regarding using of "max-depth" will be helpful.

I do not think the RESTCONF text talks about depths of parent keys which are
auto-selected. Here is what the I-D says:

             "For each node selected by the filter, this parameter
              selects how many conceptual sub-tree levels should be
              returned in the reply.  If the depth is 1, the reply
              includes just the selected nodes but no children.  If the
              depth is 'unbounded', all descendant nodes are included.";

What exactly is missing?
 
> 4.       For the <get-data> filter mechanism, since there are 4 filters (filter-spec and config-filter and max-depth and with-defaults), whether we can mention that all these filters are AND'ed. Also whether there is a suggested order to apply filter ? I think "max-depth" filter has to be applied last. Others maybe any order is OK.

Yes, I think the idea is that all filters apply. Do you have a
concrete proposal?

> 5.       negated-origin-filter : Regarding this I feel we can add a sentence as to when user should use "negated-origin-filter" , as "origin-filter" also can be used for this purpose.

Well, the set of origin values is not necessarily static. There are a
bunch of concrete values defined in RFC 8342 but technically origin
values are identities and thus extensible. Hence, if you want every
config true node which is not origin intended, then you better use
negated-origin-filter since trying list all origin-filter values is at
least fragile. Bottom line: if I want 'all except some', I use
"negated-origin-filter" and if I want 'all where' I use
"origin-filter".

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>