On Wed, Feb 7, 2018 at 8:11 AM, Robert Wilton <rwil...@cisco.com> wrote:
>
>
> On 07/02/2018 14:23, Andy Bierman wrote:
>
>
>
> On Wed, Feb 7, 2018 at 3:14 AM, Robert Wilton <rwil...@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 <
>> 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.
>>
>> 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
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')
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.
Thanks,
> Rob
>
>
Andy
>
>
>
>
>> Thanks,
>> Rob
>>
>>
>>
> Andy
>
>
>>
>>
>> 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
>>> <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
>>> >> mjethanand...@gmail.com
>>> >>
>>>
>>> _______________________________________________
>>> Netconf mailing list
>>> netc...@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netconf
>>>
>>
>>
>>
>> _______________________________________________
>> Netconf mailing
>> listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf
>>
>>
>>
>
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
