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