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

From: Rohit R Ranade <[email-masked]>
Date: Wed, 25 Apr 2018 04:22:24 +0000

Hi All,

I plan to implement this draft and hence had some implementation related clarifications.

1.       I feel that there should be more text added about "origin" filtering mechanism. I am not clear about some aspects of origin filtering.

RFC 8342 : NMDA RFC provides the below example

<interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
                 or:origin="or:intended">
       <interface>
         <name>lo0</name>
         <description>loopback</description>
         <ip-address or:origin="or:system">127.0.0.1</ip-address>
         <ip-address>::1</ip-address>
       </interface>
     </interfaces>
If user provides <origin-filter> as "system" ONLY, then he will NOT get this record in output. Because the keys have originated from "intended" . Right ?
So, If user wants to get the system originated data, he MUST give all the origins in the <origin-filter> where the keys of the system data have originated from. Can you please confirm whether this is OK.

Another example given in RFC 8342 is as below:
     <interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
                 or:origin="or:intended">
       <interface or:origin="or:system">
         <name>lo0</name>
         <ip-address>127.0.0.1</ip-address>
         <ip-address>::1</ip-address>
       </interface>
     </interfaces>

?  Here keys are originated from "system", but it is under container of "intended". So if user gives "system" for "origin-filter", the output will still NOT have this instance output ?

?  Also the container is not defined as "presence" in C.3.  Interface Example, but still it has origin whether that is Ok ?

With Regards,
Rohit R Ranade

From: Rohit R Ranade
Sent: 24 April 2018 18:39
To: [email-masked]' <[email-masked]>
Subject: [netmod] Comments on draft-ietf-netconf-nmda-netconf-05

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.

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

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.

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.

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.

With Regards,
Rohit R Ranade

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 25 Apr 2018 12:42:22 +0200

> So, If user wants to get the system originated data, he MUST give all the origins in the <origin-filter> where the keys of the system data have originated from. Can you please confirm whether this…

I would expect that <origin-filter>or:system</origin-filter> would
select the ip-address tagged with or:origin="or:system" and that the
system would return any necessary container or list elements and the
necessary key elements (since otherwise the value returned is just
useless). So the result would be:

> ?  Here keys are originated from "system", but it is under container of "intended". So if user gives "system" for "origin-filter", the output will still NOT have this instance output ?

We allow origin values on containers or lists in order to inherit
them, i.e., to achieve a more compact encoding. Anyway, if a leaf node
matches, then I think any encompassing containers and list should be
included in the result so that the matching leaf can be reported. So
you would return

instead of not returning anything at all.

> ?  Also the container is not defined as "presence" in C.3.  Interface Example, but still it has origin whether that is Ok ?
 
Why not?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>