Subject: Re: [netconf] AUTH48 changes to RFC 8526 <draft-ietf-netconf-nmda-netconf-08>

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 6 Feb 2019 22:49:47 +0100

Mahesh,

can we assume that this edit is accepted and we can resume the AUTH48
process?

/js

On Tue, Jan 29, 2019 at 10:54:54AM -0800, Mahesh Jethanandani wrote:
> NETCONF WG,
> 
> During the AUTH48 review of draft-ietf-netconf-nmda-netconf-08, the authors found a couple of things that needed further clarification. The edits are reflected in this e-mail using OLD: and NEW:. Since the changes are technical changes, we needed to make sure that the WG was ok with the changes. This starts a one week review period terminating next Tuesday, February 5 to provide any comments you might have. If providing comments, please be specific in the changes you would like to see, preferably using your own OLD: and NEW:. If no comments are received, it will be deemed that the changes are fine with the WG. The two set of changes are in the YANG model itself, and in Section 3.1.1.4.
> 
> In the YANG model:
> 
> OLD:
> 
>         choice origin-filters {
>           when 'derived-from-or-self(datastore, "ds:operational")';
>           if-feature "origin";
>           description
>             "Filters based on the 'origin' annotation.";
>           leaf-list origin-filter {
>             type or:origin-ref;
>             description
>               "Filter based on the 'origin' annotation.  A node matches
>                the filter if its 'origin' annotation is derived from or
>                equal to any of the given filter values.";
>           }
>           leaf-list negated-origin-filter {
>             type or:origin-ref;
>             description
>               "Filter based on the 'origin' annotation.  A node matches
>                the filter if its 'origin' annotation is not derived
>                from and not equal to any of the given filter values.";
>           }
>         }
> 
> NEW:
> 
>         choice origin-filters {
>           when 'derived-from-or-self(datastore, "ds:operational")';
>           if-feature origin;
>           description
>             "Filters configuration nodes based on the 'origin'
>              annotation.  Configuration nodes that do not have an
>              'origin' annotation are treated as if they have the
>              'origin' annotation 'or:unknown'.
> 
>              System state nodes are not affected by origin-filters and
>              thus not filtered.  Note that system state nodes can be
>              filtered with the 'config-filter' leaf.";
> 
>           leaf-list origin-filter {
>             type or:origin-ref;
>             description
>               "Filter based on the 'origin' annotation.  A
>                configuration node matches the filter if its 'origin'
>                annotation is derived from or equal to any of the given
>                filter values.";
>           }
>           leaf-list negated-origin-filter {
>             type or:origin-ref;
>             description
>               "Filter based on the 'origin' annotation.  A
>                configuration node matches the filter if its 'origin'
>                annotation is not derived from and not equal to any of
>                the given filter values.";
>           }
>         }
> 
> OLD:
> 
>         leaf config-filter {
>           type boolean;
>           description
>             "Filter for nodes with the given value for their
>              'config' property.  If this leaf is not present, all
>              nodes are selected.
> 
>              For example, when this leaf is set to 'true', only 'config
>              true' nodes are selected.";
>         }
> 
> NEW:
> 
>         leaf config-filter {
>           type boolean;
>           description
>             "Filter for nodes with the given value for their 'config'
>              property.  When this leaf is set to 'true', only 'config
>              true' nodes are selected and, when set to ‘false’, only
>              ‘config false’ nodes are selected.  If this leaf is not
>              present, no nodes are filtered.";
>         }
> 
> Add the following example to 3.1.1.4:
> 
>     In order to not retrieve any system state nodes, the
>     "config-filter" can be used:
> 
>     <rpc message-id="103"
>          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>       <get-data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"
>                 xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores"
>                 xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
>         <datastore>ds:operational</datastore>
>         <subtree-filter>
>           <bgp xmlns="http://example.com/ns/bgp <http://example.com/ns/bgp>"/>
>         </subtree-filter>
>         <config-filter>true</config-filter>
>         <origin-filter>or:intended</origin-filter>
>         <origin-filter>or:system</origin-filter>
>         <with-origin/>
>       </get-data>
>     </rpc>
> 
>     <rpc-reply message-id="103"
>                xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>       <data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda">
>         <bgp xmlns="http://example.com/ns/bgp <http://example.com/ns/bgp>"
>              xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
>              or:origin="or:intended">
>           <peer>
>             <name>2001:db8::2:3</name>
>             <local-port or:origin="or:system">60794</local-port>
>           </peer>
>         </bgp>
>       </data>
>     </rpc-reply>
> 
> Thanks.
> 
> Mahesh Jethanandani // as shepherd
> [email-masked]
> 
> 
> 

> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

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

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 6 Feb 2019 14:16:20 -0800

> On Feb 6, 2019, at 1:49 PM, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> Mahesh,
> 

Yes. 

This closes the one week review period. No comments were received on the further clarifications proposed by the authors. As such, we will now let the RFC Editor know to proceed with making the proposed changes.

Thanks.

>>          <bgp xmlns="http://example.com/ns/bgp <http://example.com/ns/bgp> <http://example.com/ns/bgp <http://example.com/ns/bgp>>"/>
>>        </subtree-filter>
>>        <bgp xmlns="http://example.com/ns/bgp <http://example.com/ns/bgp> <http://example.com/ns/bgp <http://example.com/ns/bgp>>"
>> [email-masked] <mailto:[email-masked]>
>> 
>> 
>> 
> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
> 
> 
> -- 
> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/ <https://www.jacobs-university.de/>>

Mahesh Jethanandani
[email-masked]

---

From: Rohit R Ranade <[email-masked]>
Date: Thu, 7 Feb 2019 02:06:35 +0000

Sorry for the late comment.  I think this should be “neither derived-from nor equal to any of the given filter values”

I think if it is derived-from but not matching the filter value, this filter should apply.

With Regards,

Rohit

From: netconf [mailto:[email-masked]] On Behalf Of Mahesh Jethanandani
Sent: 07 February 2019 03:46
To: Juergen Schoenwaelder <[email-masked]>
Cc: Netconf <[email-masked]>
Subject: Re: [netconf] AUTH48 changes to RFC 8526 <draft-ietf-netconf-nmda-netconf-08>

On Feb 6, 2019, at 1:49 PM, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:

Mahesh,

Yes.

Thanks.

/js

NETCONF WG,

In the YANG model:

OLD:

       choice origin-filters {

NEW:

       choice origin-filters {

OLD:

       leaf config-filter {
         type boolean;
         description

NEW:

       leaf config-filter {
         type boolean;
         description

   <rpc message-id="103"

Thanks.

Mahesh Jethanandani // as shepherd
[email-masked]<mailto:[email-masked]>

_______________________________________________
netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 7 Feb 2019 16:29:13 -0800

Authors of the draft,

Do we want to accept or reject this late comment?

> On Feb 6, 2019, at 6:06 PM, Rohit R Ranade <[email-masked]> wrote:
> 
> On Feb 6, 2019, at 1:49 PM, Juergen Schoenwaelder <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Mahesh,
> 
Mahesh Jethanandani
[email-masked]

---

From: Kent Watsen <[email-masked]>
Date: Fri, 8 Feb 2019 01:47:56 +0000

These are semantically identical statements.  
Let’s ask the RFC Editor for their opinion.  
FWIW, I prefer Rohit’s suggested replacement.

Kent // as co-author

> On Feb 7, 2019, at 7:29 PM, Mahesh Jethanandani <[email-masked]> wrote:
> 
> Authors of the draft,
> 
>> On Feb 6, 2019, at 6:06 PM, Rohit R Ranade <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> From: netconf [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Mahesh Jethanandani
>> To: Juergen Schoenwaelder <[email-masked] <mailto:[email-masked]>>
>> Cc: Netconf <[email-masked] <mailto:[email-masked]>>

---

From: tom petch <[email-masked]>
Date: Fri, 8 Feb 2019 16:40:55 +0000

----- Original Message -----
From: "Kent Watsen" <[email-masked]>
Sent: Friday, February 08, 2019 1:47 AM

<tp>

I find the original formulation much clearer. I can rewrite it as

match if
origin NOT derived from filter
AND
origin NOT equal to filter

so if cable is derived from ADSL, then I can slot in the values and get

filter cable
origin ADSL
ADSL NOT derived from cable true
AND
ADSL NOT equal to cable true
i.e. true

filter ADSL
origin cable
cable NOT derived from ADSL false
AND
cable NOT equal to ADSL true
i.e. false

which I find clear ( and I assume is what you intend).

With neither ..  nor, I cannot do that, or not as straightforwardly, and
so find unclear.

Tom Petch

Kent // as co-author

>> Sorry for the late comment.  I think this should be “neither
derived-from nor equal to any of the given filter values”
>> From: netconf [mailto:[email-masked]
<mailto:[email-masked]>] On Behalf Of Mahesh Jethanandani
>> To: Juergen Schoenwaelder <[email-masked]
<mailto:[email-masked]>>
>> On Feb 6, 2019, at 1:49 PM, Juergen Schoenwaelder
<[email-masked]
<mailto:[email-masked]>> wrote:
>> This closes the one week review period. No comments were received on
the further clarifications proposed by the authors. As such, we will now
let the RFC Editor know to proceed with making the proposed changes.
>> During the AUTH48 review of draft-ietf-netconf-nmda-netconf-08, the
authors found a couple of things that needed further clarification. The
edits are reflected in this e-mail using OLD: and NEW:. Since the
changes are technical changes, we needed to make sure that the WG was ok
with the changes. This starts a one week review period terminating next
Tuesday, February 5 to provide any comments you might have. If providing
comments, please be specific in the changes you would like to see,
preferably using your own OLD: and NEW:. If no comments are received, it
will be deemed that the changes are fine with the WG. The two set of
changes are in the YANG model itself, and in Section 3.1.1.4.
>>          <bgp xmlns="http://example.com/ns/bgp
<http://example.com/ns/bgp> <http://example.com/ns/bgp
<http://example.com/ns/bgp>>"/>
>>        <bgp xmlns="http://example.com/ns/bgp
<http://example.com/ns/bgp> <http://example.com/ns/bgp
<http://example.com/ns/bgp>>"
>> [email-masked] <mailto:[email-masked]>
<https://www.ietf.org/mailman/listinfo/netconf>
> [email-masked] <mailto:[email-masked]>
<https://www.ietf.org/mailman/listinfo/netconf>

------------------------------------------------------------------------
--------

---

From: Kent Watsen <[email-masked]>
Date: Sat, 9 Feb 2019 00:27:47 +0000

Hi Tom,

Ack.   Actually, I wrote a similar thing to Mahesh last night after sending my message to the list.   The English may be more correct with Rohit suggestion but, as you say, it is a little less mechanical and may confuse some.   That said, while “nor” is somewhat uncommon, “neither” is widely used and (I think) hard to misinterpret.   I’m still of the opinion that we should leave it to the RFC Editor at this point.

Kent

> On Feb 8, 2019, at 11:40 AM, tom petch <[email-masked]> wrote:
>