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

[Martin Bjorklund <[e-mail]>]

Hi,

Ebben Aries <[e-mail]> wrote:
> On Mar 02 09:57 AM, Mahesh Jethanandani 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.
> > 
> 
> Changes look good - few quick comments
> 
> - L221: L181 was modified but not this instance
>   derived-from-or-self(../datastore, "ds:operational")

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

> - '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?

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

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

more?


/martin



> 
> > 
> > > On Mar 1, 2018, at 12:48 AM, Martin Bjorklund <[e-mail]> wrote:
> > > 
> > > Hi,
> > > 
> > > Mahesh Jethanandani <[e-mail]> 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 <[e-mail]> 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 <[e-mail] <mailto:[e-mail]>> wrote:
> > >>>>> 
> > >>>>> 
> > >>>>> 
> > >>>>> On Tue, Feb 20, 2018 at 6:59 AM, Robert Wilton <[e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>> 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" <[e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>> wrote:
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> On Fri, Feb 9, 2018 at 6:05 AM, Juergen Schoenwaelder <[e-mail] <mailto:[e-mail]>> 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > >>>>>>> Fax:   [phone]         <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=>>
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> _______________________________________________
> > >>>>>>> Netconf mailing list
> > >>>>>>> [e-mail] <mailto:[e-mail]>
> > >>>>>>> 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
> > >>>>>>> 
> > >>>>>>> [e-mail] <mailto:[e-mail]>
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> _______________________________________________
> > >>>>>>> Netconf mailing list
> > >>>>>>> [e-mail] <mailto:[e-mail]>
> > >>>>>>> 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=>
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> _______________________________________________
> > >>>>>>> Netconf mailing list
> > >>>>>>> [e-mail] <mailto:[e-mail]>
> > >>>>>>> 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=>
> > >>>>>> 
> > >>>>>> 
> > >>>>> 
> > >>>>> 
> > >>>>> _______________________________________________
> > >>>>> Netconf mailing list
> > >>>>> [e-mail] <mailto:[e-mail]>
> > >>>>> 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
> > >>>> [e-mail] <mailto:[e-mail]>
> > >>> 
> > >> 
> > >> Mahesh Jethanandani
> > >> [e-mail]
> > >> 
> > 
> > Mahesh Jethanandani
> > [e-mail]
> > 
> 
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>