Subject: Re: [Netconf] [netmod] LC of NDMA NETCONF/RESTCONF drafts

From: Martin Bjorklund <[email-masked]>
Date: Thu, 01 Mar 2018 09:48:01 +0100 (CET)

Hi,

Mahesh Jethanandani <[email-masked]> wrote:
> Authors,
> 
> Please post updated drafts of NMDA NETCONF and NMDA RESTCONF that
> address the comments from Andy.

Done, draft-ietf-netconf-nmda-netconf-04 and
draft-ietf-netconf-nmda-restconf-03.

The with-defaults handling has been updated.

The capability :with-origin has been removed (already covered by the
feature "origin").

Examples have been added.

/martin

> 
> Thanks.
> 
> > On Feb 21, 2018, at 3:35 AM, Robert Wilton <[email-masked]> wrote:
> > 
> > My presumption is that we will put directly equivalent text into the NMDA RESTCONF draft as well.
> > 
> > Thanks,
> > Rob
> > 
> > 
> > On 20/02/2018 20:04, Mahesh Jethanandani wrote:
> >> What portion of this text, if not all, applies to NMDA RESTCONF draft?
> >> 
> >>> On Feb 20, 2018, at 11:25 AM, Andy Bierman <[email-masked] <mailto:[email-masked]>> wrote:
> >>> 
> >>> 
> >>> 
> >>> On Tue, Feb 20, 2018 at 6:59 AM, Robert Wilton <[email-masked] <mailto:[email-masked]>> wrote:
> >>> Here, is some proposed text to refine "with-defaults" handling in the NETCONF NMDA draft.
> >>> 
> >>> The text below has been discussed by some of the authors, but we didn't reach agreement on whether the "with-operational-defaults" capability is required.  I've included it in the text below, but further text to specify it would be required.
> >>> 
> >>> 
> >>> This text is a significant improvement over previous proposals.
> >>> OK with me to make these changes.
> >>> 
> >>> Andy
> >>> 
> >>>  
> >>> 
> >>> OLD, end of section 3.1.1
> >>> 
> >>>    The "with-defaults" parameter does not apply when interacting with an
> >>>    operational datastore.  This means that all "in use" values, as
> >>>    defined in [I-D.ietf-netmod-revised-datastores] section 5.3, are
> >>>    returned from the operational state datastore, even if a node happens
> >>>    to have a default statement in the YANG module, and this default
> >>>    value is being used by the server.  If the "with-defaults" parameter
> >>>    is present in a request to such a datastore, then the server MUST
> >>>    return an error, as specified in "ietf-netconf-nmda" (see Section 4).
> >>> 
> >>> REPLACED WITH:
> >>> 
> >>> 3.1.1.1.  With-defaults interactions
> >>> 
> >>>    If the "with-defaults" capability is supported by the server, then
> >>>    the "with-defaults" parameter, defined in [RFC6243], is supported for
> >>>    <get-data> operations that target conventional configuration
> >>>    datastores.
> >>> 
> >>>    If the "with-operational-defaults" capability is supported by the
> >>>    server, then the "with-defaults" parameter is supported for
> >>>    <get-data> operations that target <operational>.  The behavior of the
> >>>    "with-defaults" parameter for <operational> is defined as below:
> >>> 
> >>>    - If no "with-defaults" parameter is specifed, or if it is set to
> >>>      "explicit", "report-all", or "report-all-tagged", then the "in use"
> >>>      values, as defined in [I-D.ietf-netmod-revised-datastores] section
> >>>      5.3, are returned from the operational state datastore, even if a
> >>>      node happens to have a default statement in the YANG module, and
> >>>      this default value is being used by the server.  If the
> >>>      "with-defaults" parameter is set to "report-all-tagged", any values
> >>>      that match the schema default are tagged with additional metadata,
> >>>      as described in [RFC6243] section 3.4.
> >>> 
> >>>    - If the "with-defaults" parameter is set to "trim", all "in use"
> >>>      values are returned, except that the output is filtered to exclude
> >>>      any values that match the default defined in the YANG schema.
> >>> 
> >>>    Support for "with-defaults" in <get-data> operations on any datastore
> >>>    not defined in [I-D.ietf-netmod-revised-datastores] SHOULD be defined
> >>>    by the specification for the datastore.
> >>> 
> >>> ADDITIONAL text added to the end of section 3.1.2 on <edit-data>:
> >>> 
> >>>    If the "with-defaults" capability is supported by the server, the
> >>>    semantics of editing modes is the same as for <edit-config>, as
> >>>    described in section 4.5.2 of [RFC6243].
> >>> 
> >>>    Semantics for "with-defaults" in <edit-data> operations on any non
> >>>    conventional configuration datastores SHOULD be defined by the
> >>>    specification for the datastore.
> >>> 
> >>> 
> >>> Thanks,
> >>> Rob
> >>> 
> >>> 
> >>> On 16/02/2018 16:38, Andy Bierman wrote:
> >>>> 
> >>>> 
> >>>> On Fri, Feb 16, 2018 at 8:05 AM, Robert Wilton <[email-masked] <mailto:[email-masked]>> wrote:
> >>>> I think that NETCONF/RESTCONF draft should specify how it interacts with the "with-defaults" feature.
> >>>> 
> >>>> 
> >>>> It already has that text.
> >>>> 
> >>>> Since NMDA is a fork-lift upgrade, the fact that all the defaults handling
> >>>> code has to be done over is line noise in the overall effort.
> >>>>  
> >>>> I'll send some proposed text, probably early next week for the NETCONF draft.  If we can agree that then we can apply the same semantics to the RESTCONF draft as well.
> >>>> Thanks,
> >>>> Rob
> >>>> 
> >>>> 
> >>>> 
> >>>> Andy
> >>>>  
> >>>> 
> >>>> On 16/02/2018 15:45, Andy Bierman wrote:
> >>>>> 
> >>>>> 
> >>>>> On Fri, Feb 16, 2018 at 7:26 AM, Kent Watsen <[email-masked] <mailto:[email-masked]>> wrote:
> >>>>> Right, it wouldn't be good to leave how to implement with-defaults unspecified for long.  If we go with option-2, we might as well do it now.  Would the RFC 6243 authors (Andy/Balazs) be willing to quickly submit an I-D for rfc6243bis?
> >>>>> 
> >>>>>  
> >>>>> 
> >>>>> 
> >>>>> No -- No such thing as quick I-D in the IETF.
> >>>>> Also I am not clear at all how with-defaults changes for  <operational>.
> >>>>> Clearly it applied to config=false nodes, yet NMDA seems to forget these config=false
> >>>>> nodes exist in YANG.
> >>>>> 
> >>>>> I suggest just leaving it out.
> >>>>> People will continue to use <get> for config=false nodes and not implement NMDA just for that.
> >>>>> So with-defaults is not needed for config=false nodes and it is not wanted for config=true nodes.
> >>>>> So leave it out. Option 1.
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> Kent  // co-chair
> >>>>> 
> >>>>>  
> >>>>> 
> >>>>> Andy
> >>>>>  
> >>>>> 
> >>>>>  
> >>>>> On 2/16/18, 12:11 AM, "Mahesh Jethanandani" <[email-masked] <mailto:[email-masked]>> wrote:
> >>>>> 
> >>>>>  
> >>>>> With this thread having gone silent for the last few days, my read is that we have two options in front of us.
> >>>>> 
> >>>>>  
> >>>>> Option 1 suggested by Juergen to not discuss with-defaults in the NMDA draft, remove any text in the draft that states the behavior of with-defaults for <operational> datastore, and punt the work to a rfc6243bis document.
> >>>>> 
> >>>>>  
> >>>>> Option 2 suggested by Andy is to apply Section 2 of RFC 6243 on <operational> datastore to support <get-data> much the same way as it done with <get> today for the conventional datastores, somewhere.
> >>>>> 
> >>>>>  
> >>>>> Going with option 1 leaves the implementation of with-defaults in a limbo state, where it is not clear to an implementation what to do. In that sense, I agree with Andy that we need to articulate a clear position for Section 2 of RFC 6243 in the NMDA context. My suggestion would be that we go with option 1, but pick up work on rfc6243bis now, update it for NMDA, and include it as part of NMDA updates.
> >>>>> 
> >>>>>  
> >>>>> Thoughts?
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> On Feb 9, 2018, at 9:30 AM, Andy Bierman <[email-masked] <mailto:[email-masked]>> wrote:
> >>>>> 
> >>>>>  
> >>>>>  
> >>>>> On Fri, Feb 9, 2018 at 6:05 AM, Juergen Schoenwaelder <[email-masked] <mailto:[email-masked]>> wrote:
> >>>>> 
> >>>>> On Fri, Feb 09, 2018 at 10:38:07AM +0000, Robert Wilton wrote:
> >>>>> >
> >>>>> >
> >>>>> > On 08/02/2018 18:44, Juergen Schoenwaelder wrote:
> >>>>> > > On Thu, Feb 08, 2018 at 09:11:58AM -0800, Andy Bierman wrote:
> >>>>> > > > Then remove the text that says an error is sent if with-defaults attempted
> >>>>> > > > on <operational>.
> >>>>> > > > None of this new text needs to go into NMDA. It can be a vendor-specific
> >>>>> > > > mystery what gets set as origin=default.  Implementors can read RFC 6243
> >>>>> > > > and figure it out on their own.
> >>>>> > > As I said, I am absolutely fine with the option of being silent about
> >>>>> > > with-defaults and if needed someone can spin an update of RFC 6243.
> >>>>> > I'm not quite happy with being entirely silent on this, because being silent
> >>>>> > causes three ambiguities:
> >>>>> > (1) Clients do not know what with-defaults "basic-mode" operational
> >>>>> > datastores support.
> >>>>> > (2) Clients do not know what "with-default" operations a server supports on
> >>>>> > operational datastores without trying them.
> >>>>> > (3) The actual behavior of the "with-defaults" operations on operational
> >>>>> > datastores also seems to be somewhat ambiguous.
> >>>>> 
> >>>>> Robert,
> >>>>> 
> >>>>> being silent means that there is no with-defaults for get-data defined
> >>>>> as part of the NETCONF NMDA work and an update of RFC 6243 is required
> >>>>> to augment with-defaults in, like it does for the basic NETCONF
> >>>>> operations defined in RFC 6241 today. In other words, we defer the
> >>>>> problem to an update of RFC 6243 and we keep with-defaults as a purely
> >>>>> optional extension instead of making it a first class citizen. (I
> >>>>> think someone also raised the issue that the NETCONF NMDA document
> >>>>> makes with-default mandatory).
> >>>>> 
> >>>>> Yes, this does not settle the debate - it just moves the debate to a
> >>>>> new work item. Given that views about default handling still seem
> >>>>> controversial, localizing the issue to an update of RFC 6243 is
> >>>>> perhaps not as bad as it may sound at first sight.
> >>>>> 
> >>>>> /js
> >>>>> 
> >>>>> PS: I have no overview about what current server implementations
> >>>>>     actually support. How many servers announce "also-supported" with
> >>>>>     enumerations that do not match the basic mode? Or is RFC 6243
> >>>>>     mostly used to just announce the basic mode and leaving the client
> >>>>>     no choice than to adopt to the server's basic mode? And how many
> >>>>>     server implementations do not even do that, i.e., leaving the
> >>>>>     client clueless about the server's basic mode? And if clients do
> >>>>>     actually have a choice, which mode do they prefer to use? I assume
> >>>>>     there is no way to answer these questions but a reality check
> >>>>>     about what is actually out there might help to understand whether
> >>>>>     it is possible to reduce the complexity here in the future.
> >>>>> 
> >>>>>  
> >>>>>  
> >>>>> Our server implements all modes and advertised also-supported.
> >>>>> 
> >>>>> The code is trivial, maybe 50 lines at most.
> >>>>> 
> >>>>>  
> >>>>> We will continue to use <get> for non-configuration nodes.
> >>>>> 
> >>>>> The <get-data> operation removes functionality for these nodes
> >>>>> 
> >>>>> and provides no value, since we have supported the <depth> parameter
> >>>>> 
> >>>>> for <get> for a few years already.
> >>>>> 
> >>>>>  
> >>>>> Using <get> with subtree filters is widely deployed -- the 2nd most
> >>>>> 
> >>>>> used operation besides <edit-config>.
> >>>>> 
> >>>>>  
> >>>>>  
> >>>>>  
> >>>>> Andy
> >>>>> 
> >>>>>  
> >>>>>  
> >>>>>  
> >>>>> --
> >>>>> 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/ <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=9eQvo1PEOL-lRGER7u6akciGF7xxQnoOpVaM6-dJFdY&s=49P5HU4PqmpQCiiDKRIceuVg7Vh3IXkY3oH1-bDsoKE&e=>>
> >>>>> 
> >>>>>  
> >>>>> _______________________________________________
> >>>>> Netconf mailing list
> >>>>> [email-masked] <mailto:[email-masked]>
> >>>>> https://www.ietf.org/mailman/listinfo/netconf <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=9eQvo1PEOL-lRGER7u6akciGF7xxQnoOpVaM6-dJFdY&s=7MXUCoM_G8S2L-uj5AfBlcTfUcDHUrpCSPNLisJLmgg&e=>
> >>>>>  
> >>>>> Mahesh Jethanandani
> >>>>> 
> >>>>> [email-masked] <mailto:[email-masked]>
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> _______________________________________________
> >>>>> Netconf mailing list
> >>>>> [email-masked] <mailto:[email-masked]>
> >>>>> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> _______________________________________________
> >>>>> Netconf mailing list
> >>>>> [email-masked] <mailto:[email-masked]>
> >>>>> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
> >>>> 
> >>>> 
> >>> 
> >>> 
> >>> _______________________________________________
> >>> Netconf mailing list
> >>> [email-masked] <mailto:[email-masked]>
> >>> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
> >> 
> >> Mahesh Jethanandani
> >> [email-masked] <mailto:[email-masked]>
> > 
> 
> Mahesh Jethanandani
> [email-masked]
>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 2 Mar 2018 09:57:04 -0800

WG, YANG-doctors,

Those who provided comments during LC or as part of YANG-doctors review, please verify that your comments/concerns have been addressed. And please do so by Wed. of next week, so we can proceed towards publication.

Thanks.

> On Mar 1, 2018, at 12:48 AM, Martin Bjorklund <[email-masked]> wrote:
> 
> Hi,
> 

Mahesh Jethanandani
[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Fri, 2 Mar 2018 19:27:16 -0800

On Fri, Mar 2, 2018 at 9:57 AM, Mahesh Jethanandani <[email-masked]
> wrote:

> WG, YANG-doctors,
>
> Those who provided comments during LC or as part of YANG-doctors review,
> please verify that your comments/concerns have been addressed. And please
> do so by Wed. of next week, so we can proceed towards publication.
>
>

I reviewed nmda-netconf-03 and nmda-restconf-02.
The changes look good

Andy

> >>>>> The text below has been discussed by some of the authors, but we
> didn't reach agreement on whether the "with-operational-defaults"
> capability is required.  I've included it in the text below, but further
> text to specify it would be required.
> >>>>>
> >>>>>
> >>>>>> I'll send some proposed text, probably early next week for the
> NETCONF draft.  If we can agree that then we can apply the same semantics
> to the RESTCONF draft as well.
> >>>>>> Thanks,
> >>>>>> Rob
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Andy
> >>>>>>
> >>>>>>
> >>>>>>> Right, it wouldn't be good to leave how to implement with-defaults
> unspecified for long.  If we go with option-2, we might as well do it now.
> Would the RFC 6243 authors (Andy/Balazs) be willing to quickly submit an
> I-D for rfc6243bis?
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On 2/16/18, 12:11 AM, "Mahesh Jethanandani" <
> [email-masked] <mailto:[email-masked]>> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> With this thread having gone silent for the last few days, my read
> is that we have two options in front of us.
> >>>>>>>
> >>>>>>>
> >>>>>>> Option 1 suggested by Juergen to not discuss with-defaults in the
> NMDA draft, remove any text in the draft that states the behavior of
> with-defaults for <operational> datastore, and punt the work to a
> rfc6243bis document.
> >>>>>>>
> >>>>>>>
> >>>>>>> Option 2 suggested by Andy is to apply Section 2 of RFC 6243 on
> <operational> datastore to support <get-data> much the same way as it done
> with <get> today for the conventional datastores, somewhere.
> >>>>>>>
> >>>>>>>
> >>>>>>> Going with option 1 leaves the implementation of with-defaults in
> a limbo state, where it is not clear to an implementation what to do. In
> that sense, I agree with Andy that we need to articulate a clear position
> for Section 2 of RFC 6243 in the NMDA context. My suggestion would be that
> we go with option 1, but pick up work on rfc6243bis now, update it for
> NMDA, and include it as part of NMDA updates.
> >>>>>>>
> >>>>>>>
> >>>>>>> Thoughts?
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Fri, Feb 9, 2018 at 6:05 AM, Juergen Schoenwaelder <
> [email-masked] <mailto:j.schoenwaelder@
> jacobs-university.de>> wrote:
> >>>>>>>
> >>>>>>> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/
> <https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.jacobs-2Duniversity.de_&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYa
> GTvjISlaJdcZo&m=9eQvo1PEOL-lRGER7u6akciGF7xxQnoOpVaM6-dJFdY&s=
> 49P5HU4PqmpQCiiDKRIceuVg7Vh3IXkY3oH1-bDsoKE&e=>>
> >>>>>>>
> >>>>>>>
> >>>>>>> https://www.ietf.org/mailman/listinfo/netconf <https://urldefense.
> proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_
> listinfo_netconf&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=
> 9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=9eQvo1PEOL-
> lRGER7u6akciGF7xxQnoOpVaM6-dJFdY&s=7MXUCoM_G8S2L-
> uj5AfBlcTfUcDHUrpCSPNLisJLmgg&e=>
> >>>>>>>
> >>>>>>> Mahesh Jethanandani
> >>>>>>>
> >>>>>>> https://www.ietf.org/mailman/listinfo/netconf <
> https://www.ietf.org/mailman/listinfo/netconf>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> https://www.ietf.org/mailman/listinfo/netconf <
> https://www.ietf.org/mailman/listinfo/netconf>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> https://www.ietf.org/mailman/listinfo/netconf <
> https://www.ietf.org/mailman/listinfo/netconf>
> >>>>
> >>>> Mahesh Jethanandani
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Ebben Aries <[email-masked]>
Date: Wed, 7 Mar 2018 23:16:02 -0700

> Those who provided comments during LC or as part of YANG-doctors review, please verify that your comments/concerns have been addressed. And please do so by Wed. of next week, so we can proceed towa…

Changes look good - few quick comments

- L221: L181 was modified but not this instance
  derived-from-or-self(../datastore, "ds:operational")

- 'negated-origin-filter': An inverse match condition should be common
  in quite a few modules however it's likely the nomenclature differs
  across this use (e.g. "except").  Should we try to use some common
  nomenclature for these uses?

> >>>>>>> Fax:   +49 421 200 3103         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=Z6iPQrS8a9qKeAbdVhbuuW6aL_eoCb21vD5OIIZIark&s=diA081Otv7om7p6q1cfG5JqRs7OPx6RaC-X0H94S2eA&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=9eQvo1PEOL-lRGER7u6akciGF7xxQnoOpVaM6-dJFdY&s=49P5HU4PqmpQCiiDKRIceuVg7Vh3IXkY3oH1-bDsoKE&e=>>
> >>>>>>> 
> >>>>>>> 
> >>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=Z6iPQrS8a9qKeAbdVhbuuW6aL_eoCb21vD5OIIZIark&s=QoH5ZG6EtOEakBwXrW-7AY1f6J95B-yWxNgr3EQ9-7M&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=9eQvo1PEOL-lRGER7u6akciGF7xxQnoOpVaM6-dJFdY&s=7MXUCoM_G8S2L-uj5AfBlcTfUcDHUrpCSPNLisJLmgg&e=>
> >>>>>>> 
> >>>>>>> Mahesh Jethanandani
> >>>>>>> 
> >>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=Z6iPQrS8a9qKeAbdVhbuuW6aL_eoCb21vD5OIIZIark&s=QoH5ZG6EtOEakBwXrW-7AY1f6J95B-yWxNgr3EQ9-7M&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=Z6iPQrS8a9qKeAbdVhbuuW6aL_eoCb21vD5OIIZIark&s=QoH5ZG6EtOEakBwXrW-7AY1f6J95B-yWxNgr3EQ9-7M&e=>
> >>>>>>> 
> >>>>>>> 
> >>>>>>> 
> >>>>>>> 
> >>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=Z6iPQrS8a9qKeAbdVhbuuW6aL_eoCb21vD5OIIZIark&s=QoH5ZG6EtOEakBwXrW-7AY1f6J95B-yWxNgr3EQ9-7M&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=Z6iPQrS8a9qKeAbdVhbuuW6aL_eoCb21vD5OIIZIark&s=QoH5ZG6EtOEakBwXrW-7AY1f6J95B-yWxNgr3EQ9-7M&e=>
> >>>>>> 
> >>>>>> 
> >>>>> 
> >>>>> 
> >>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=Z6iPQrS8a9qKeAbdVhbuuW6aL_eoCb21vD5OIIZIark&s=QoH5ZG6EtOEakBwXrW-7AY1f6J95B-yWxNgr3EQ9-7M&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=Z6iPQrS8a9qKeAbdVhbuuW6aL_eoCb21vD5OIIZIark&s=QoH5ZG6EtOEakBwXrW-7AY1f6J95B-yWxNgr3EQ9-7M&e=>
> >>>> 
> >>>> Mahesh Jethanandani

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 08 Mar 2018 08:48:24 +0100 (CET)

Hi,

>   derived-from-or-self(../datastore, "ds:operational")

I am sorry, but I don't understand the issue.  The statement looks
correct to me.

>   nomenclature for these uses?

Sure.  Do we have a precedent?  Any other suggestions?

  negated-origin-filter
  excluded-origin-filter
  except-origin-filter

more?

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 8 Mar 2018 08:57:40 +0100

> Sure.  Do we have a precedent?  Any other suggestions?

If we have to change this (not sure we have to), then I prefer
excluded-origin-filter out of the three options you have listed.

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

---

From: Kent Watsen <[email-masked]>
Date: Thu, 8 Mar 2018 17:39:29 +0000

The correct solution here is to define a generic filtering syntax that
includes metadata, which would then enable the use of an operator like
"not" or '!'.   

Defining such a syntax now would delay these drafts for an unreasonably
long amount of time.  But I think doing so should be a near term goal
for the NETMOD WG.  

<netmod-chair>there is lots of spare time on the agenda, in case anyone
wants to lead a discussion on this, send me a PM.</netmod-chair>

Back on topic, I don't think there is precedent, so we can pick whatever
we want for this.  I might have a slight preference for "negated".

Kent // contributor

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=aees5La1tgvlK47wIqkZWc5lrF-4Ui2Wm5j-bLkfECU&s=pJXuNA-l6Uw0-eAK8ngTUvAE_hmQrv9cQS2dt9u0drs&e=>

_______________________________________________
Netconf mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=aees5La1tgvlK47wIqkZWc5lrF-4Ui2Wm5j-bLkfECU&s=rVJdH7Zo44vOKZrC85bJZOlBUkDPX3VCx7mFDQ3nDVc&e=

---

From: Ebben Aries <[email-masked]>
Date: Thu, 8 Mar 2018 23:55:21 -0700

> I am sorry, but I don't understand the issue.  The statement looks

Maybe I'm missing the reason but looking at this specific diff between
draft-03 and draft-04 - I see the following

@@ -150,16 +177,26 @@
           "Filter for nodes with the given value for their
            'config' property.";
       }
-      leaf-list origin-filter {
-        when 'derived-from-or-self(../datastore, "ds:operational")';
+      choice origin-filters {
+        when 'derived-from-or-self(datastore, "ds:operational")';

But noticed the following node-set was not updated as you did above

220       leaf with-origin {
221         when 'derived-from-or-self(../datastore, "ds:operational")';
222         if-feature origin;
223         type empty;

Should this not be updated as well?

> Sure.  Do we have a precedent?  Any other suggestions?

I have no real preference - merely a suggestion for consistency.
Looking at other published or draft modules implementing a similar
condition, there isn't much if any consistency today.

If we can't find a good common name that can be used and suggested to
other model authors now, then we should probably just keep it as-is
until addressing this later possibly by other means per Kent's
suggestion.

> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=f7qrvLecCyV7e7_M9PHoW-QjMP5UTM095DBbCLKiS8k&s=DgkJs9DGZcSWhNEQMJkomi0RmvG2yZiNis-Btforwug&e=
> >

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 09 Mar 2018 10:03:22 +0100 (CET)

> draft-03 and draft-04 - I see the following

No.  The first one was adjusted b/c the leaf-list was changed to a
choice.  The choice isn't present in the datastore, so the expression
is evaluated relative to the parent node.

> until addressing this later possibly by other means per Kent's

Ok.

/martin