On Wed, Feb 7, 2018 at 11:36 PM, Juergen Schoenwaelder < j.schoenwael...@jacobs-university.de> 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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <https://www.jacobs-university.de/> >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
