Subject: [netmod] yang-push issue: draft-ietf-netconf-yang-push-12 and default values and RFC 6243

From: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
Date: Wed, 17 Jan 2018 13:26:56 +0000

All,

In discussions with some customers and on implementation, the issue of defaults has come up. For get/get-config we have the “with defaults capability” defined in RFC 6243 that allows us to control the behaviour with respect to defaults. To remind folk with an example, we could have:

    <rpc message-id="101"
         xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <get>
        <filter type="subtree">
          <interfaces xmlns="http://example.com/ns/interfaces"/>
        </filter>
        <with-defaults
         xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">
          report-all
        </with-defaults>
      </get>
    </rpc>

The addition of the “with-defaults” tag and value determines the behavior of the get in this example (taken from A.3.1 in RFC 6243<https://tools.ietf.org/html/rfc6243#page-22>).

It strikes me that we need to have a similar mechanism for telemetry, allowing a user to specify, for example, that for a periodic subscription on a subtree, they also wish default values to be reported. I think at minimum we need clarification on this, as section 3.7 of draft-ietf-netconf-yang-push-12 currently says:

The content of the update record is equivalent to the contents that would be obtained had the same data been explicitly retrieved using e.g., a NETCONF "get" operation, with the same filters applied.

This text can currently only refer to a “get” as defined in RFC 6241 as there is no reference to RFC 6243 as yet. I think we need to address this issue now to define expectations, even if it is to explicitly not consider an RFC 6243-like mechanism or to say that we only consider explicitly set values in telemetry, or…

Cheers,

Einar

---

From: Alexander Clemm <[email-masked]>
Date: Wed, 17 Jan 2018 19:09:52 +0000

Hi Einar,

I suggest we add clarification that default values must be reported.  For on-change, clearly all changes need to be reported, whether the change is to a default value or not, everything else would be confusing.  Also for periodic, it would be confusing to leave out readings when a value is at default  versus not (the object might also have been deleted, etc).  So, I don’t think we need to add a flag or such that would allow to exclude defaults which appear to be of limited benefit to applications while introducing a lot more complexity to deal with corner cases such as the ones described.

--- Alex

From: netmod [mailto:[email-masked]] On Behalf Of Einar Nilsen-Nygaard (einarnn)
Sent: Wednesday, January 17, 2018 5:27 AM
To: [email-masked]
Subject: [netmod] yang-push issue: draft-ietf-netconf-yang-push-12 and default values and RFC 6243

All,

    <rpc message-id="101"

Cheers,

Einar

---

From: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
Date: Wed, 17 Jan 2018 20:33:05 +0000

On 17 Jan 2018, at 19:09, Alexander Clemm <[email-masked]<mailto:[email-masked]>> wrote:

Hi Einar,

I suggest we add clarification that default values must be reported.

einarnn> I’m afraid I do not agree with that, especially when it comes to configuration leaves. Platforms can have vast numbers of configuration defaults that they run with when the end user makes a relatively simple configuration change. Take the example of creating  a loopback interface on IOS-XE. If we look at the defaults for that, we would have over 60 default leaves that would be reported if a subscription was established on that interface…even though the explicit end-user config may only be a couple of leaves, say description and an IPv4 address

For on-change, clearly all changes need to be reported, whether the change is to a default value or not, everything else would be confusing.

einarnn> I agree that a change to or away from the default value needs to be reported. And I can also agree that if a default value is explicitly set by an end user, then that default value should be reported on an ongoing basis.

einarnn> As you can see, my primary concerns are about configuration data. As yet, I haven’t thought so much about the implications on config false data.

Also for periodic, it would be confusing to leave out readings when a value is at default  versus not (the object might also have been deleted, etc).

einarnn> For config, I don’t agree.

So, I don’t think we need to add a flag or such that would allow to exclude defaults which appear to be of limited benefit to applications while introducing a lot more complexity to deal with corner cases such as the ones described.

einarnn> And I still do not agree, especially when configuration may have a large number of default settings that are relatively uninteresting in terms of reporting when one puts in place telemetry. After all, the consumer knows what the defaults are from the model. Why send all that data that, typically, a platform will need to work harder to extract.

einarnn> I think this is an important issue, or I wouldn’t have raised it, but I am strongly opposed to making the behavior of telemetry the equivalent of RFC 6243 “report-all” behavior.

Cheers,

Einar

--- Alex

From: netmod [mailto:[email-masked]] On Behalf Of Einar Nilsen-Nygaard (einarnn)
Sent: Wednesday, January 17, 2018 5:27 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [netmod] yang-push issue: draft-ietf-netconf-yang-push-12 and default values and RFC 6243

All,

    <rpc message-id="101"

Cheers,

Einar

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 17 Jan 2018 21:44:22 +0100

For what its worth, the NMDA documents for NETCONF and RESTCONF posted
today state that with-defaults only applies to non-operational
datastores and that values are always reported for operational
datastores, regardless whether they match any defaults.

/js

> _______________________________________________
> netmod mailing list
> [email-masked]
> 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/>

---

From: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
Date: Wed, 17 Jan 2018 21:17:24 +0000

Juergen,

Thanks for that! That is a useful note, and it can reduce the problem space here, and I’m fine with that. As you may have seen from my response, though, my main concerns is about configuration.

Remind me — under NMDA will configuration leaves be reported back via “operational datastores”? Meaning that default configuration data is expected to always be returned when accessed via an “operational datastore”. Apologies if this is a dumb question, but I’ve not been able to track NMDA close enough to answer this question immediately.

Cheers,

Einar

> On 17 Jan 2018, at 20:44, Juergen Schoenwaelder <[email-masked]> wrote:
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 17 Jan 2018 23:29:53 +0100

> Remind me — under NMDA will configuration leaves be reported back via “operational datastores”? Meaning that default configuration data is expected to always be returned when accessed via an “opera…

With NMDA, you have the (short) configuration of the interface lo in
<running> and once this has been applied, you have the (possibly long)
applied configuration and state of the interface lo in <operational>.

/js

---

From: Robert Wilton <[email-masked]>
Date: Wed, 17 Jan 2018 22:43:17 +0000

HI Alex,

Note, that when it comes to the NMDA <operational> datastore there are 
no default values.  Only the values that are "in use".

Thanks,
Rob

On 17/01/2018 19:09, Alexander Clemm wrote:
> For on-change, clearly all changes need to be reported, whether the 
> change is to a default value or not, everything else would be 
> confusing.  Also for periodic, it would be confusing to leave out 
> readings when a value is at default  versus not (the object might also 
> have been deleted, etc).  So, I don’t think we need to add a flag or 
> such that would allow to exclude defaults which appear to be of 
> limited benefit to applications while introducing a lot more 
> complexity to deal with corner cases such as the ones described.
>
> --- Alex
>
> *From:*netmod [mailto:[email-masked]] *On Behalf Of *Einar 
> Nilsen-Nygaard (einarnn)
> *Sent:* Wednesday, January 17, 2018 5:27 AM
> *To:* [email-masked]
> *Subject:* [netmod] yang-push issue: draft-ietf-netconf-yang-push-12 
> and default values and RFC 6243
>
> All,
>
> In discussions with some customers and on implementation, the issue of 
> defaults has come up. For get/get-config we have the “with defaults 
> capability” defined in RFC 6243 that allows us to control the 
> behaviour with respect to defaults. To remind folk with an example, we 
> could have:
>
> <rpc message-id="101"
>
> The addition of the “with-defaults” tag and value determines the 
> behavior of the get in this example (taken from A.3.1 in RFC 6243 
> <https://tools.ietf.org/html/rfc6243#page-22>).
>
> It strikes me that we need to have a similar mechanism for telemetry, 
> allowing a user to specify, for example, that for a periodic 
> subscription on a subtree, they also wish default values to be 
> reported. I think at minimum we need clarification on this, as section 
> 3.7 of draft-ietf-netconf-yang-push-12 currently says:
>
>     /The content of the update record is equivalent to the contents
>     that would be obtained had the same data been explicitly retrieved
>     using e.g., a NETCONF "get" operation, with the same filters applied./
>
> This text can currently only refer to a “get” as defined in RFC 6241 
> as there is no reference to RFC 6243 as yet. I think we need to 
> address this issue now to define expectations, even if it is to 
> explicitly not consider an RFC 6243-like mechanism or to say that we 
> only consider explicitly set values in telemetry, or…
>
> Cheers,
>
> Einar
>
>
>

---

From: Alexander Clemm <[email-masked]>
Date: Wed, 17 Jan 2018 23:47:01 +0000

Thanks, Rob and Juergen, for pointing this out!

I guess we should add this to the text as well.

--- Alex

From: Robert Wilton [mailto:[email-masked]]
Sent: Wednesday, January 17, 2018 2:43 PM
To: Alexander Clemm <[email-masked]>; Einar Nilsen-Nygaard (einarnn) <[email-masked]>; [email-masked]
Subject: Re: [netmod] yang-push issue: draft-ietf-netconf-yang-push-12 and default values and RFC 6243

HI Alex,

Note, that when it comes to the NMDA <operational> datastore there are no default values.  Only the values that are "in use".
Thanks,
Rob

--- Alex

All,

    <rpc message-id="101"

Cheers,

Einar

netmod mailing list

[email-masked]<mailto:[email-masked]>