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

Andy Bierman <andy@yumaworks.com> Wed, 07 February 2018 23:03 UTC

Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF65F127522 for <netmod@ietfa.amsl.com>; Wed, 7 Feb 2018 15:03:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUligSr7jORO for <netmod@ietfa.amsl.com>; Wed, 7 Feb 2018 15:03:53 -0800 (PST)
Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6623F126DED for <netmod@ietf.org>; Wed, 7 Feb 2018 15:03:52 -0800 (PST)
Received: by mail-lf0-x22c.google.com with SMTP id u20so1533718lff.11 for <netmod@ietf.org>; Wed, 07 Feb 2018 15:03:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6HzpFj3e8UGnLMuC6acxwDENhH6z+Ua38ZX2ldsC7jo=; b=PlGLGAXhEia6UkCZF1ZnzARJomai/+c/TXNstANJyZjlhFtqnS8Vkvp5VOwSKG9qp7 yYMS/kL1IxNp76dz2oEe4GvT28tw8Lse4UCjWghFWaySEBpwn9vdne7HLABWw3owriJA f6A4LF1RtS7YtSm0M13ka518FL52rpkOTqL5aHzPIiDv2sm/IgEv8vuXkXGdunrkTZfQ Vlvy9BbaDrgXfg0hpChlb7vpYVV2zknVYwZ1rDicnqMyO0HBDl3AiNB1oxYXEjjOJpGq v4v04zsYABsl2RIrkT7qcmMzcJTqNMlurg2I172HkNYzeWzKLm57eDEWjg0apj62lY3C xGWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6HzpFj3e8UGnLMuC6acxwDENhH6z+Ua38ZX2ldsC7jo=; b=C9xag2XsPyx1f7EL9Sem3L/HUdYl6RH1d8qlEpS2ajREfiiFj8SJEQJDiMetH+LFIn kOIhUDXYn1rFBykgd5kevobycO8hWCFX/hh1P7iDvt1sntTjCQ+jpPSuOAVqEEOIwSUh E0ma2/TkS2Oq37ItLPnKQ7FInGcZSMCWAtKomxDwVPqTfJ9R8eWfHRCFzx6bUu0q+2b4 sCcWQSRFFsB8HGWRKQZTSJdogsf9MfbPD15fWeqX79yJijnFoM+4EL5pDRyHTO7cGxAn Fs6atIQLgr1v4DWPllq3qssb6OI5dHQhCXJ+JXhe+rm0M6e8yP0z1IB8SuFS3UuVhAhM AA2w==
X-Gm-Message-State: APf1xPAZV+/GDYCWLO8RUUhVcPaGoRiSZDaayuLdrHPPartJvyAYHS9q bJt+uTbXM24Y9g+pRvlXRhXdM+a2FfmZoC5MfhcDmg==
X-Google-Smtp-Source: AH8x225Z2jexPPOFcYli4DN89lmacIFtj97LSPhnuPXSVt/Df/eNBfcs6hcFIlyb9eBLwb809Lc4JY8OvowrnQUwz8w=
X-Received: by 10.46.47.13 with SMTP id v13mr5057943ljv.15.1518044630480; Wed, 07 Feb 2018 15:03:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.143.6 with HTTP; Wed, 7 Feb 2018 15:03:49 -0800 (PST)
In-Reply-To: <20180207.192803.834988416883038576.mbj@tail-f.com>
References: <CABCOCHSUWGKOH2JJA3TrRRJrvgwmmFRPs8cmOtPg0YKcY9=tsg@mail.gmail.com> <a0b9c4ba-a54d-f26e-3c09-1c2a92df58dd@cisco.com> <CABCOCHR34ovCHumyTKXOYzJcU3WM1kt-EnpxxtGLS2kLUPtECA@mail.gmail.com> <20180207.192803.834988416883038576.mbj@tail-f.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Wed, 7 Feb 2018 15:03:49 -0800
Message-ID: <CABCOCHR95zL=AZ-LLq_1FsCff9dgUKP5_33uY7W7OMd8tdfb3w@mail.gmail.com>
To: Martin Bjorklund <mbj@tail-f.com>
Cc: Robert Wilton <rwilton@cisco.com>, Netconf <netconf@ietf.org>, NetMod WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="089e082f330cf417c00564a74e56"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/oDTazUocwkloYX4khSM09xlhqoY>
Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Feb 2018 23:03:57 -0000

On Wed, Feb 7, 2018 at 10:28 AM, Martin Bjorklund <mbj@tail-f.com> wrote:

> Andy Bierman <andy@yumaworks.com> wrote:
> > On Wed, Feb 7, 2018 at 8:11 AM, Robert Wilton <rwilton@cisco.com> wrote:
> >
> > >
> > >
> > > On 07/02/2018 14:23, Andy Bierman wrote:
> > >
> > >
> > >
> > > On Wed, Feb 7, 2018 at 3:14 AM, Robert Wilton <rwilton@cisco.com>
> wrote:
> > >
> > >> Hi Andy,
> > >>
> > >> On 07/02/2018 02:33, Andy Bierman wrote:
> > >>
> > >>
> > >>
> > >> On Mon, Feb 5, 2018 at 1:33 PM, Mahesh Jethanandani <
> > >> mjethanandani@gmail.com> wrote:
> > >>
> > >>> For folks that provided comments as part of LC, please verify that
> your
> > >>> comments have been adequately addressed by -03 version of the draft.
> > >>>
> > >>>
> > >>
> > >> Most comments have been addressed.
> > >>
> > >>
> > >>     The "with-defaults" parameter does not apply when interacting
> with an
> > >>
> > >>         operational datastore.
> > >>
> > >>
> > >> There is no explanation of why the with-defaults parameter does not
> apply
> > >> to <operational>.
> > >> This is confusing. The solution that has been a standard for years
> still
> > >> applies to
> > >> all datastores, except a completely different mechanism
> (origin-filter)
> > >> is used instead
> > >> for 1 datastore.
> > >>
> > >> If the server code can identify a default so it can be tagged
> > >> origin=or:default, then it can
> > >> also support with-defaults.
> > >>
> > >> I prefer the sentence above be changed, so that a server MAY implement
> > >> with-defaults
> > >> for <operational>.  If the client sends <with-defaults> it should be
> OK
> > >> to honor it instead
> > >> of returning an error.
> > >>
> > >> I have two concerns with changing this to a MAY:
> > >>
> > >> (1) The most useful "with-defaults" behavior differs for
> <operational> vs
> > >> the configuration datastores, but with-defaults only allows a single
> > >> standard behavior to be specified.
> > >>
> > >> E.g. for configuration datastores the most appropriate semantics (if
> the
> > >> client doesn't explicitly ask for something else) is "explicit". i.e.
> you
> > >> give back exactly what was put in.
> > >>
> > >> But, for operational, the most appropriate semantics (if the client
> > >> doesn't explicitly ask for something else) is something like
> "report-all",
> > >> i.e. the device reports the precise current state including any
> defaults.
> > >> However, we felt that this would return too much unnecessary data,
> hence
> > >> why the datastore architecture defines "in-use" data, allowing the
> server
> > >> to prune out any data that is clearly irrelevant.
> > >>
> > >> (2) <operational> is a new datastore.  I personally don't want each
> > >> server choosing how the data is returned, which requires that clients
> must
> > >> handle all variants.  It would be better for the draft to specify the
> > >> standard semantics to use unless a client has explicitly requested
> > >> something else.
> > >>
> > >> I'm not opposed to a "with-defaults-bis", or a new draft covering
> > >> "with-defaults" for <operational>", but I think that:
> > >> (i) We shouldn't delay the NMDA protocol drafts for this, this can be
> > >> done as separate draft adding extra optional functionality.
> > >> (ii) The semantics for retrieving data from operational (or
> > >> notifications) should be as defined by "in-use" in the NMDA
> architecture,
> > >> unless a client has explicitly specified, or configured, a different
> > >> behavior.
> > >> (iii) Probably the only existing option defined in "with-defaults"
> that
> > >> makes sense for <operational> is a variant of "trim" that is
> specified to
> > >> return what is defined as returning the "in-use" values, but also
> excluding
> > >> any values that match a default value specified in the schema.
> > >>
> > >>
> > >
> > > I think your approach violates the Postel Principle.
> > > "Be liberal in what you accept" is about robustness.
> > > Rejecting parameters for no good reason is about fragility.
> > >
> > > I never said change the behavior for <operational> if no
> <with-defaults>
> > > is present.
> > > If the parameter is provided it is trivial for the server to honor it.
> > > The most useful value (report-all) is the default, not leave out all
> > > defaults, like <get-config>.
> > >
> > > OK, so one option is to allow the "with-defaults" parameter for the
> > > <operational> datastore, but specify in both the NETCONF NMDA and
> RESTCONF
> > > NMDA drafts how "with-defaults" semantics apply to any operational
> > > datastore:
> > >
> > > 1) Regardless of what is reported in the "basic-mode" capability
> > > parameter, the default behavior for <operational> is "report-all", with
> > > semantics as described below:
> > > 2) "report-all" for operational datastores is defined as returning all
> "in
> > > use" values (i.e. as specified in section 5.3 of the NMDA
> architecture, so
> > > default values that are not "in use" are not returned).
> > > 3) "trim" for operational datastores is defined as returning all
> "in-use"
> > > values (... as 5.3) except that values that match the value specified
> in
> > > the schema "default" statement are omitted.  Note, clients cannot
> > > distinguish between a value that is omitted because it is not in use,
> vs a
> > > value that is omitted because it matches the schema default.
> > > 4) "explicit" for operational datastores is defined as returning the
> same
> > > as "report-all", defined above.
> > > 5) "report-all-tagged" for operational datastores is defined as
> returning
> > > the same as "report-all", except that all values that match the values
> > > specified in the schema "default" statement are tagged, as described in
> > > with-defaults (RFC 5243).
> > >
> > > Also note - there is no change in semantics or behavior to how
> > > "with-defaults" works for conventional datastores.
> > >
> > > Thoughts?
> > >
> > >
> > This looks good.
> >
> > Showing the work...
> >
> > 1) there is no YANG default for <with-defaults> parameter.
> >     The behavior if this parameter is missing is determined by the
> operation
>
> Right.  So in this case (get-data of operational), it would return all
> default values in use.
>


OK



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

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


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



> > 3) The <with-defaults> parameter for <operational> is mostly a NO-OP.
> >     It does not add or remove any nodes that would be returned.
> >     The "report-all-tagged" value does add the "default> attribute, which
> > is useful
> >     for clients that process these attributes already
> >
> > 4) The values that are tagged default are the same ones that the server
> tags
> >      as origin=default.
> >
> > 5) It still seems to up to the server "basic-mode" as to what is
> considered
> >      "set by default". This messy aspect of NETCONF is minimized in
> > <get-data> because
> >      the server usually returns all values in use.
>
>
>
> /martin
>
>
>

Andy



>
> >
> >
> > Thanks,
> > > Rob
> > >
> > >
> >
> > Andy
> >
> >
> > >
> > >
> > >
> > >
> > >> Thanks,
> > >> Rob
> > >>
> > >>
> > >>
> > > Andy
> > >
> > >
> > >>
> > >>
> > >> Andy
> > >>
> > >>
> > >>
> > >>
> > >>> Thanks
> > >>>
> > >>> Mahesh Jethanandani
> > >>> mjethanandani@gmail.com
> > >>>
> > >>> > On Feb 5, 2018, at 9:43 AM, Martin Bjorklund <mbj@tail-f.com>
> wrote:
> > >>> >
> > >>> > Hi,
> > >>> >
> > >>> > Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
> > >>> >> This closes the LC for the two NDMA drafts for NETCONF and
> RESTCONF.
> > >>> >>
> > >>> >> As part of the LC, there were a couple of comments/questions
> > >>> >> raised. In particular
> > >>> >>
> > >>> >> - Vladmir reported an error, which Martin said is fixed in his
> local
> > >>> copy.
> > >>> >
> > >>> > Fixed.
> > >>> >
> > >>> >> - Robert suggested that “/yang-library/checksum” should be a
> > >>> >>  reference. Juergen supported that comment, so I am assuming that
> > >>> >>  that will be incorporated into the draft.
> > >>> >
> > >>> > Yes, fixed.
> > >>> >
> > >>> >> - Andy had questions around datastore set to “conventional”
> > >>> >
> > >>> > Fixed.
> > >>> >
> > >>> >>  , about origin filter limited to 1 source
> > >>> >
> > >>> > Fixed.
> > >>> >
> > >>> >>  and the behavior of with-defaults.
> > >>> >
> > >>> > There were no additional changes to the document from the
> discussion
> > >>> > about this.
> > >>> >
> > >>> >>  I see some discussion around it with the authors
> > >>> >>  agreeing that some of them need some text clarifying the
> > >>> >>  position. Can the authors please post the suggested
> text/additions
> > >>> >>  for the WG to review.
> > >>> >> - Anything else??
> > >>> >>
> > >>> >> Once an updated draft has been posted, I will do a writeup on the
> > >>> >> drafts and send it to IESG.
> > >>> >
> > >>> > The issues above are now addressed, in
> > >>> > draft-ietf-netconf-nmda-netconf-03.
> > >>> >
> > >>> > There were no additional comments on
> > >>> > draft-ietf-netconf-nmda-restconf-02, so I believe this version is
> > >>> > ready.
> > >>> >
> > >>> >
> > >>> > /martin
> > >>> >
> > >>> >
> > >>> >>
> > >>> >> Thanks.
> > >>> >>
> > >>> >>> On Jan 31, 2018, at 10:16 AM, Juergen Schoenwaelder <
> > >>> j.schoenwaelder@jacobs-university.de> wrote:
> > >>> >>>
> > >>> >>> On Wed, Jan 31, 2018 at 04:53:48PM +0000, Eric Voit (evoit)
> wrote:
> > >>> >>>>
> > >>> >>>> I do have one additional thought below on
> > >>> draft-ietf-netmod-revised-datastores section 5.3 default handling
> > >>> process.  See in-line...
> > >>> >>>>
> > >>> >>>
> > >>> >>> Well, this document is with the RFC editor now. I do not think it
> > >>> needs
> > >>> >>> clarification. It already has text in 5.3 such as:
> > >>> >>>
> > >>> >>>  Requests to retrieve nodes from <operational> always return the
> > >>> value
> > >>> >>>  in use if the node exists, regardless of any default value
> specified
> > >>> >>>  in the YANG module.  If no value is returned for a given node,
> then
> > >>> >>>  this implies that the node is not used by the device.
> > >>> >>>
> > >>> >>> /js
> > >>> >>>
> > >>> >>>> From: Robert Wilton -X, January 31, 2018 6:31 AM
> > >>> >>>>
> > >>> >>>>
> > >>> >>>> Hi Andy,
> > >>> >>>>
> > >>> >>>> On 31/01/2018 09:22, Andy Bierman wrote:
> > >>> >>>>
> > >>> >>>>
> > >>> >>>> On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder <
> > >>> j.schoenwaelder@jacobs-university.de <mailto:j.schoenwaelder@jacobs
> > >>> -university.de><mailto:j.schoenwaelder@jacobs-university.de <mailto:
> > >>> j.schoenwaelder@jacobs-university.de>>> wrote:
> > >>> >>>>> On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman wrote:
> > >>> >>>>> Hi,
> > >>> >>>>>
> > >>> >>>>> I have some questions about these drafts.
> > >>> >>>>>
> > >>> >>>>> 1) what if datastore set to "conventional"?
> > >>> >>>>>   There are many places where a datastore-ref type is used.
> > >>> >>>>>   However, "conventional" is valid for base "datastore", even
> > >>> though
> > >>> >>>>>   it is ambiguous as a datastore selector.
> > >>> >>>>
> > >>> >>>> We can add explicit text that an identity that does not resolve
> to a
> > >>> >>>> datastore implemented by the server results in an invalid value
> > >>> error.
> > >>> >>>>
> > >>> >>>>
> > >>> >>>> OK
> > >>> >>>>
> > >>> >>>>
> > >>> >>>>> 2) origin filter is limited to 1 source
> > >>> >>>>>  This filtering seems rather limited.  A client must retrieve
> > >>> >>>>> <with-origin> and check
> > >>> >>>>>   all the values in use, then make repeated requests for each
> > >>> source as a
> > >>> >>>>> different
> > >>> >>>>>   <origin-filter> leaf
> > >>> >>>>
> > >>> >>>> If the client does <with-origin>, then it has all origin
> information
> > >>> >>>> and it can filter locally. That said, we could make
> origin-filter a
> > >>> >>>> leaf-list which is logically ORed so that one can retrieve
> > >>> >>>> origin-filter=or:system or origin-filter=or:learned in one
> request.
> > >>> >>>>
> > >>> >>>>
> > >>> >>>> OK
> > >>> >>>>
> > >>> >>>>> 3) with-defaults broken
> > >>> >>>>>   The operational datastore does not support with-defaults.
> > >>> >>>>>    Instead, the client must use origin-filter=or:default or
> > >>> with-origin
> > >>> >>>>>    and check all the origin attributes.  Since a client needs
> to
> > >>> use
> > >>> >>>>>    with-defaults for other datastores, this special handling of
> > >>> >>>>> <operational>
> > >>> >>>>>    seems unhelpful.
> > >>> >>>>
> > >>> >>>> I think the with-defaults semantics for conventional
> configuration
> > >>> >>>> datastores are much more complicated than necessary for the
> > >>> >>>> operational state datastore. Note that that the operational
> state
> > >>> >>>> datastore reports in-use values not really defaults:
> > >>> >>>>
> > >>> >>>> <leaf or:origin='default'>foo</leaf>
> > >>> >>>>
> > >>> >>>> This reports that the value 'foo' is in use and that it
> originates
> > >>> >>>> from a default value. Note that this could also be
> > >>> >>>>
> > >>> >>>> <leaf or:origin='intended'>foo</leaf>
> > >>> >>>>
> > >>> >>>> in case the intended configuration datastore configured the
> value
> > >>> >>>> 'foo' (despite this value matching the default). The
> with-defaults
> > >>> >>>> solution is pretty complex because it tries to handle how
> different
> > >>> >>>> systems deal with configuration defaults. The idea is to not
> carry
> > >>> >>>> this complexity over to in-use values in the operational state
> > >>> >>>> datastore.
> > >>> >>>>
> > >>> >>>>
> > >>> >>>> Before NMDA, the client could decide if it wanted to retrieve
> > >>> default nodes or not.
> > >>> >>>> This client-choice has been removed from NMDA, which is a
> problem.
> > >>> >>>> We tried to reach a sensible compromise on the data returned
> from
> > >>> operational (defined in section 5.3 of the NMDA architecture):
> > >>> >>>> - it should return explicit values for everything that is
> affecting
> > >>> the actual running state of the device (regardless of whether the
> > >>> operational value matches a schema default value).
> > >>> >>>> - it does not need to, and should not, return operational values
> > >>> for stuff that isn't actually in use, i.e. don't return needless and
> > >>> unwanted data.
> > >>> >>>>
> > >>> >>>> In particular, if no value is returned from a particular data
> node
> > >>> in <operational> then, barring mgmt protocol errors, a client can
> assume
> > >>> that any functionality associated with that data node is off (i.e.
> not in
> > >>> use).
> > >>> >>>>
> > >>> >>>> Some examples to illustrate the behavior:
> > >>> >>>>
> > >>> >>>> (i) If a protocol, e.g. OSPF,  is not enabled/running then
> > >>> <operational> does not need to return any data for it.  It would be
> > >>> reasonable to return a flag to indicate that OSPF is not
> enabled/running.
> > >>> >>>>
> > >>> >>>> (ii) If you have some funky widget on an interface that
> defaults to
> > >>> being off and isn't being used then <operational> don't need to
> return any
> > >>> data for it.
> > >>> >>>>
> > >>> >>>> (iii) But, if you have some funky widget on an interface that
> > >>> defaults to being on, then the server should return data for it. If
> it is
> > >>> actually enabled, then it would indicate that it is on and return any
> > >>> associated values with its operational state, or if it is disabled
> then it
> > >>> should explicitly report that it is off.
> > >>> >>>>
> > >>> >>>> (iv) I would regard that all applied configuration is "in use"
> by
> > >>> the system, even if it matches the default value, and hence it
> should be
> > >>> reported.
> > >>> >>>>
> > >>> >>>>
> > >>> >>>> This behavior for <operational> is obviously slightly different
> > >>> from the existing with-default handling that is supported for
> configuration
> > >>> datastores.  As I recall, there were a couple of reasons that we
> decided to
> > >>> have a different behavior for <operational>:
> > >>> >>>> (a) to have consistent semantics for all servers, rather than
> > >>> different servers supporting different with-defaults behaviors
> (which makes
> > >>> life harder for clients because they must cope with all variants).
> > >>> >>>> (b) to remove any potential ambiguity if data isn't returned.
> I.e.
> > >>> with the existing with-defaults semantics it is not clear to me that
> > >>> servers will always return an explicit value to indicate that a
> particular
> > >>> widget is off if the schema defines that the default it that is
> enabled.
> > >>> If the server doesn't support a given widget at all, it is quite
> plausible
> > >>> that it will just return no data for it.  In theory
> features/deviations
> > >>> should handle this, but those don't work so well if different
> linecards
> > >>> have different capabilities.  Hence being explicit about stuff that
> is in
> > >>> use seems more robust.
> > >>> >>>>
> > >>> >>>> <eric> These are good examples.  It would be great if section
> 5.3
> > >>> could be tweaked to make clearer the relationship between running
> datastore
> > >>> defaults and other operational datastore defaults for the same tree.
> > >>> >>>>
> > >>> >>>> For example, let’s say I create a configured subscription, and
> the
> > >>> default transport protocol is NETCONF.  NETCONF will be used for that
> > >>> subscription even though the node might not be populated.  In this
> case,
> > >>> the object would not appear in the running datastore, but MUST*
> appear in
> > >>> the operational datastore with the default origin (as it is in-use).
> > >>> >>>>
> > >>> >>>> This to me is the desired behavior as it doesn’t incorrectly add
> > >>> information to the running datastore, but shows what is in-use within
> > >>> operational.   I suspect other such relationships for other
> operational
> > >>> tree defaults could be asserted, perhaps based on the origin.
> > >>> >>>>
> > >>> >>>> (* Maybe ‘MUST eventually’, as obviously there is a temporal
> > >>> relationship between the two datastores.)
> > >>> >>>>
> > >>> >>>> Eric
> > >>> >>>>
> > >>> >>>> Thanks,
> > >>> >>>> Rob
> > >>> >>>>
> > >>> >>>>
> > >>> >>>>
> > >>> >>>>
> > >>> >>>>
> > >>> >>>>
> > >>> >>>> /js
> > >>> >>>>
> > >>> >>>> Andy
> > >>> >>>>
> > >>> >>>> --
> > >>> >>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > >>> >>>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen |
> > >>> Germany
> > >>> <https://maps.google.com/?q=Campus+Ring+1+%7C+28759+
> Bremen+%7C+Germany&entry=gmail&source=g>
> > >>> >>>> Fax:   +49 421 200 3103         <https://www.jacobs-
> university.de/>
> > >>> >>>>
> > >>> >>>>
> > >>> >>>>
> > >>> >>>>
> > >>> >>>>
> > >>> >>>> _______________________________________________
> > >>> >>>>
> > >>> >>>> netmod mailing list
> > >>> >>>>
> > >>> >>>> netmod@ietf.org <mailto:netmod@ietf.org><mailto:netmod@ietf.org
> > >>> <mailto:netmod@ietf.org>>
> > >>> >>>>
> > >>> >>>> https://www.ietf.org/mailman/listinfo/netmod <
> > >>> https://www.ietf.org/mailman/listinfo/netmod>
> > >>> >>>>
> > >>> >>>
> > >>> >>>> _______________________________________________
> > >>> >>>> netmod mailing list
> > >>> >>>> netmod@ietf.org <mailto:netmod@ietf.org>
> > >>> >>>> https://www.ietf.org/mailman/listinfo/netmod <
> > >>> https://www.ietf.org/mailman/listinfo/netmod>
> > >>> >>>
> > >>> >>>
> > >>> >>> --
> > >>> >>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > >>> >>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen |
> > >>> Germany
> > >>> <https://maps.google.com/?q=Campus+Ring+1+%7C+28759+
> Bremen+%7C+Germany&entry=gmail&source=g>
> > >>> >>> Fax:   +49 421 200 3103         <https://www.jacobs-
> university.de/ <
> > >>> https://www.jacobs-university.de/>>
> > >>> >>>
> > >>> >>> _______________________________________________
> > >>> >>> netmod mailing list
> > >>> >>> netmod@ietf.org <mailto:netmod@ietf.org>
> > >>> >>> https://www.ietf.org/mailman/listinfo/netmod <
> > >>> https://www.ietf.org/mailman/listinfo/netmod>
> > >>> >> Mahesh Jethanandani
> > >>> >> mjethanandani@gmail.com
> > >>> >>
> > >>>
> > >>> _______________________________________________
> > >>> Netconf mailing list
> > >>> Netconf@ietf.org
> > >>> https://www.ietf.org/mailman/listinfo/netconf
> > >>>
> > >>
> > >>
> > >>
> > >> _______________________________________________
> > >> Netconf mailing listNetconf@ietf.orghttps://ww
> w.ietf.org/mailman/listinfo/netconf
> > >>
> > >>
> > >>
> > >
> > >
>