Andy
Thanks
Mahesh Jethanandani
mjethanand...@gmail.com <mailto:mjethanand...@gmail.com>
> On Feb 5, 2018, at 9:43 AM, Martin Bjorklund
<m...@tail-f.com <mailto:m...@tail-f.com>> wrote:
>
> Hi,
>
> Mahesh Jethanandani <mjethanand...@gmail.com
<mailto:mjethanand...@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.schoenwael...@jacobs-university.de
<mailto:j.schoenwael...@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.schoenwael...@jacobs-university.de
<mailto:j.schoenwael...@jacobs-university.de>
<mailto:j.schoenwael...@jacobs-university.de
<mailto:j.schoenwael...@jacobs-university.de>><mailto:j.schoenwael...@jacobs-university.de
<mailto:j.schoenwael...@jacobs-university.de>
<mailto:j.schoenwael...@jacobs-university.de
<mailto:j.schoenwael...@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
>>>> 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>
<mailto:netmod@ietf.org
<mailto:netmod@ietf.org>><mailto: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>
<https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>>
>>>>
>>>
>>>> _______________________________________________
>>>> 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>
<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
>>> 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>
<https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>>
>> Mahesh Jethanandani
>> mjethanand...@gmail.com <mailto:mjethanand...@gmail.com>
>>
_______________________________________________
Netconf mailing list
netc...@ietf.org <mailto:netc...@ietf.org>
https://www.ietf.org/mailman/listinfo/netconf
<https://www.ietf.org/mailman/listinfo/netconf>
_______________________________________________
Netconf mailing list
netc...@ietf.org <mailto:netc...@ietf.org>
https://www.ietf.org/mailman/listinfo/netconf
<https://www.ietf.org/mailman/listinfo/netconf>
