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

[Andy Bierman <[e-mail]>]

On Wed, Feb 7, 2018 at 11:36 PM, Juergen Schoenwaelder <
[e-mail]> wrote:

> On Wed, Feb 07, 2018 at 03:03:49PM -0800, Andy Bierman wrote:
> > >
> > > > 2) The <get-data> operation returns all values in use.
> > > >     The only way to suppress defaults is to use <origin-filter>
> > > >     (e.g., request all origins except 'default')
> > >
> > > Or use with-defaults = trim.
> >
> > Yes -- because the definition in RFC 6243 is worded to exclude nodes.
> >
> > It should be clear in some draft how basic-mode applies to origin=default
> > within <operational>.
>
> Frankly, carrying the different basic modes over to <operational>
> sounds like a mistake. Complexity for no real value.
>
>

API consistency is never a mistake.
Special case treatment of 1 datastore sounds like a mistake.


> > Applying sec 2 of 6243...
> >
> > config=true:
> >
> > If basic-mode=report-all then origin=default will never be present
> >
> > If basic-mode=trim then origin=default is only possible if the
> value-in-use
> > is the YANG default
> >
> > If basic-mode=explicit then origin=default is only possible if the
> > configured value was not
> > explicitly set by a client.  Sec 2.3.1 is not clear if the YANG default
> > value is relevant or not.
> > It could be that if the configured value not explicitly set, then any
> > value-in-use (not just the
> > YANG default) could be tagged origin=default.
> >
> >
> > config=false:
> >
> > report-all: default ignored, no nodes treated as default
> > trim: node removed if value=YANG default
> > explicit: all config=false nodes are set by the server, so no nodes
> treated
> > as default
>
> Who needs all this to manage a network?



>
>
> This draft makes with-defaults mandatory-to-implement.
> > It is a SHOULD implement now.  (I approve!).
> >
> > The with-defaults capability MUST be advertised by the NMDA server,
> > including
> > the basic-mode parameter. The also-supported parameter MAY be included.
> >
> > Is it possible for report-all-tagged to apply to nodes that are learned
> > (i.e., not origin=default)?
>
> So here is an alternate proposal: The NMDA documents are silent about
> with-defaults and if someone wants to use with-defaults with
> datastores then an update of RFC 6243 needs to be written. This way,
> implementations can choose to not do any of the with-defaults magic.
>
> What we may consider, though, is to have a way to negate origin-filter
> so that we can exclude specific origins - right now to emulate this
> one has to (a) know all possible origins and then (b) list all origins
> except the one not wanted.
>
>
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.

Sometimes default leafs might take up 50% or more of the retrieval response.
Insisting that all clients always want this extra data seems overly
simplistic.
Assuming all networks are fast enough to ignore a 2X increase in data size
for no benefit
is not a good idea either.





> /js
>


Andy


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