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

Mahesh Jethanandani <mjethanandani@gmail.com> Wed, 07 February 2018 21:58 UTC

Return-Path: <mjethanandani@gmail.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 A26D31270AB; Wed, 7 Feb 2018 13:58:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 scCcDuLD-Y5q; Wed, 7 Feb 2018 13:58:26 -0800 (PST)
Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (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 1619B127873; Wed, 7 Feb 2018 13:58:25 -0800 (PST)
Received: by mail-io0-x241.google.com with SMTP id l17so3657102ioc.3; Wed, 07 Feb 2018 13:58:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=q0IpYigziU2jlHGR7IAz1stl6pXgJxS58RJrn9B+gdc=; b=PHGN8KmGrjpYJEo0asZBZ0aKGmpbJ+WLKto9U+oOic02rQtFZaQFti/Wuqc168tGw/ rNYS73spJynGsQQ/dXN40fainB7p4OOzb/F/7JldNy347PlffARsVOoiocmaYTS3Ssat c0yMeOEirrjN8b57hSuS7TJHLjjv5FsQCwX8Gvf0Jut63wiSKSdXuQkvN9gD9MZo7j9m RSNSbFgSma9tOCtWbDsqQ537l/Sy+BEs1XMgWibfJnwbQjJKOKwouEp3JVGGSxPeeVZV VjQsZ/t9SZhQi204BvIoeX9yieCjtRcEkBh48IV7kzVNPWVBqANQJlzJ9WVyJ4LJnbUJ Rvfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=q0IpYigziU2jlHGR7IAz1stl6pXgJxS58RJrn9B+gdc=; b=VYzO/jfcRyzuctzH0vnCqkWykAqjzarFYWEyd7grAD9u/epOnVzXh0jG9MhXxzrQVL Vnwi75clyFeigNAiZ96EeoKDrXTP3m9ARl1RbXQaTHYluiO232QAONf2uN5Lh2n9py8v TPlCRJ0NcmBZrGQFRC9C6E8GPOfnNp2m2HuIkVPQGNEuMaexN7X1V6e1MjerzjfUU1j3 LYxK79TTqEmrlSO/pc6BAcEgbu2fduUZTAz15aRYDt7QsCi64mySYrIzMnULXKqZeqVB QOvHst5INZ13DJCRPH+bmDyFVQEbcs5LsBVvftsCqD5CA4e1rxmxdAw9tR01qSSSVYd8 qSHg==
X-Gm-Message-State: APf1xPB4HOspiOagD63lEQlQiSqB3MdPWmm1m0Z8Y2M7QMT9HU3O2jo/ 1rlDAVFqJLeE9+vfeKdB/4Y=
X-Google-Smtp-Source: AH8x2249HC48NIccT/XB8mtWBNVMlCjW5qM2hGthM05caewsxfa5bPiTGgYHqL9jDOaBH6pEJumwxg==
X-Received: by 10.107.143.14 with SMTP id r14mr9494893iod.191.1518040705223; Wed, 07 Feb 2018 13:58:25 -0800 (PST)
Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:8ff:cdce:63cb:9067]) by smtp.gmail.com with ESMTPSA id e7sm2924811ita.17.2018.02.07.13.58.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Feb 2018 13:58:24 -0800 (PST)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Message-Id: <4A22F659-0656-4382-964D-B9319AF5CE93@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4D4DCC4F-24DD-4AA1-8D66-28B33500B47E"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Wed, 07 Feb 2018 13:58:22 -0800
In-Reply-To: <20180207.192803.834988416883038576.mbj@tail-f.com>
Cc: netconf@ietf.org, netmod@ietf.org
To: Martin Bjorklund <mbj@tail-f.com>, Andy Bierman <andy@yumaworks.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>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/E_QuOfq5_eK0WykltdkocjhOqNk>
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 21:58:31 -0000

It appears that there is some consensus around the issue of “with-defaults” for operational datastore. Andy, would you agree with what has been suggested?

It also appears that text needs to be added to explain the behavior w.r.t. operational datastore. If everyone agrees, authors, can you propose the text that needs to be updated.

Thanks.

> On Feb 7, 2018, at 10:28 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
> 
> Andy Bierman <andy@yumaworks.com <mailto: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.
> 
>> 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.
> 
>> 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
> 
> 
> 
>> 
>> 
>> 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 <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 <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://www.ietf.org/mailman/listinfo/netconf
>>>> 
>>>> 
>>>> 
>>> 
>>> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org <mailto:Netconf@ietf.org>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
Mahesh Jethanandani
mjethanandani@gmail.com