Hi Andy,
On 07/02/2018 02:33, Andy Bierman wrote:
On Mon, Feb 5, 2018 at 1:33 PM, Mahesh Jethanandani
<[email protected] <mailto:[email protected]>> 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.
Thanks,
Rob
Andy
Thanks
Mahesh Jethanandani
[email protected] <mailto:[email protected]>
> On Feb 5, 2018, at 9:43 AM, Martin Bjorklund <[email protected]
<mailto:[email protected]>> wrote:
>
> Hi,
>
> Mahesh Jethanandani <[email protected]
<mailto:[email protected]>> 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
<[email protected]
<mailto:[email protected]>> 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
<[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>> 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
>>>> Fax: +49 421 200 3103
<https://www.jacobs-university.de/
<https://www.jacobs-university.de/>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>>
>>>> netmod mailing list
>>>>
>>>> [email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>
>>>>
>>>> https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
<https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>>
>>>>
>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> [email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
>>>> https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
<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
>>> Fax: +49 421 200 3103
<https://www.jacobs-university.de/
<https://www.jacobs-university.de/>
<https://www.jacobs-university.de/
<https://www.jacobs-university.de/>>>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> [email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
>>> https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
<https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>>
>> Mahesh Jethanandani
>> [email protected] <mailto:[email protected]>
>>
_______________________________________________
Netconf mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netconf
<https://www.ietf.org/mailman/listinfo/netconf>
_______________________________________________
Netconf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netconf
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
