Subject: [netmod] Modelling different "levels" of data in YANG

From: Robert Wilton <[email-masked]>
Date: Mon, 5 Dec 2016 18:10:47 +0000

Hi,

We are currently working on modelling 802.3 Ethernet YANG within the 
802.3 YANG study group.

One interesting issue that has come up is the scope of the operational 
state data that could be modeled:

At the top level, an operator may just want to know whether an Ethernet 
interface is up or down.

At a second level, if the Ethernet interface is down, then there is some 
high level diagnostics information that may be useful to an operator to 
diagnose why the interface isn't up (e.g. alarms information, optical 
power levels, auto-negotiation protocol status).

There is also a third level, of very detailed, 802.3 hardware register 
information defined in 802.3 Clause 45.  Such information is probably of 
most relevance to the engineers developing and programming Ethernet 
chips and PHYs, but is sometimes useful for resolving potential vendor 
inter-operation issues.  Retrieving this information out of the Ethernet 
chips can be comparatively slow.

The question that was being discussed is whether it is appropriate to 
model all three levels on information in the 802.3 Ethernet YANG models, 
or whether only the top level and second level information can/should be 
modeled via YANG?

If we were to model the third level information in YANG then it would 
seem highly desirable for that information to not be returned in 
response to a general NETCONF <get/> request because the information is 
generally not of relevance and has potential performance issues in 
returning it.  Instead, it would seem desirable to only return this data 
if it was specifically requested (e.g. a <get/> request on the node 
containing the third level information), or if a hypothetical filter 
extension was specified and used to explicitly include it in the 
response. Given that there doesn't seem to a great way to currently 
achieve this in YANG, this makes me think that it isn't sensible to 
model this third level of detailed information in YANG at this time.  Do 
others agree?

Have others faced similar issues, and if so, how have you solved them?

Input welcome.  Thanks,
Rob

---

From: Vladimir Vassilev <[email-masked]>
Date: Tue, 6 Dec 2016 11:34:45 +0100

On 12/05/2016 07:10 PM, Robert Wilton wrote:

> At the top level, an operator may just want to know whether an 
> Ethernet interface is up or down.
>
> At a second level, if the Ethernet interface is down, then there is 
> some high level diagnostics information that may be useful to an 
> operator to diagnose why the interface isn't up (e.g. alarms 
> information, optical power levels, auto-negotiation protocol status).
>
> information defined in 802.3 Clause 45.  Such information is probably 
> of most relevance to the engineers developing and programming Ethernet 
> inter-operation issues.  Retrieving this information out of the 
> Ethernet chips can be comparatively slow.
>
> model all three levels on information in the 802.3 Ethernet YANG 
> models, or whether only the top level and second level information 
> can/should be modeled via YANG?
>
> response to a general NETCONF <get/> request because the information 
> is generally not of relevance and has potential performance issues in 
> returning it.  Instead, it would seem desirable to only return this 
> data if it was specifically requested (e.g. a <get/> request on the 
> node containing the third level information), or if a hypothetical 
> filter extension was specified and used to explicitly include it in 
> the response. Given that there doesn't seem to a great way to 
> currently achieve this in YANG, this makes me think that it isn't 
> sensible to model this third level of detailed information in YANG at 
> this time.  Do others agree?
>
How about having this state data reside under a config=true presence 
container e.g. /interfaces/interface/ethernet-detailed-state... . The 
user can then create the container for the interfaces he is interested 
in reading the detailed state data.

Or have dedicated RPC in the model that enables/disables the presence of 
the detailed state information for certain interfaces. Since the state 
container is not mandatory.

In any case a grouping with the 802.3 Clause 45 information data will 
definitely be usefull.

/Vladimir

---

From: Robert Wilton <[email-masked]>
Date: Tue, 6 Dec 2016 14:32:31 +0000

Hi Vladimir,

Thanks for your suggestion.  Please see some comments inline ...

On 06/12/2016 10:34, Vladimir Vassilev wrote:
>> One interesting issue that has come up is the scope of the 
>> operational state data that could be modeled:
>>
>> There is also a third level, of very detailed, 802.3 hardware 
>> register information defined in 802.3 Clause 45.  Such information is 
>> probably of most relevance to the engineers developing and 
>> programming Ethernet chips and PHYs, but is sometimes useful for 
>> resolving potential vendor inter-operation issues.  Retrieving this 
>> information out of the Ethernet chips can be comparatively slow.
>>

I'm not too keen on this approach.  This would mean that an operator 
would need to have NACM permissions to modify the configuration to be 
allowed to retrieve read-only diagnostics information.

>
> Or have dedicated RPC in the model that enables/disables the presence 
> of the detailed state information for certain interfaces. Since the 
> state container is not mandatory.

This would sort of work, but then there is still some magic involved for 
the client and device to have the knowledge not to return the 
diagnostics information in a standard get request.  I was thinking that 
defining an extension to mark the leaves in the schema as being 
diagnostics information might be the right way forward.  However, I was 
also thinking that just getting the basic (non diagnostics) operational 
YANG specified would be a useful first step along the 802.3 Ethernet 
model path.

> In any case a grouping with the 802.3 Clause 45 information data will 

Given that there are a quite a lot of registers to define.  It is quite 
possible that defining YANG for all these registers would be deferred 
until a future phase - do you see any issue with this?

Thanks,
Rob

> .

---

From: Robert Wilton <[email-masked]>
Date: Tue, 6 Dec 2016 14:58:56 +0000

Hi Athanasios,

Thanks for the suggestion.  As per my reply to Vladimir, I think that 
this solves the question of how to get them, but doesn't really solve 
the issue of how a client is expected to know that they wouldn't be 
included in a regular get request.

Thanks,
Rob

On 05/12/2016 18:25, Athanasios Kyparlis wrote:
>
> Maybe not ideal, but could we use an action or rpc for them?
>
> ------------------------------------------------------------------------
> *From:* netmod <[email-masked]> on behalf of Robert Wilton 
> <[email-masked]>
> *Sent:* Monday, December 5, 2016 1:10:47 PM
> *To:* [email-masked]
> *Cc:* Peter Jones
> *Subject:* [netmod] Modelling different "levels" of data in YANG
> Hi,
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Alex Campbell <[email-masked]>
Date: Tue, 6 Dec 2016 21:03:09 +0000

IMO using an action or rpc is an okay solution for now, certainly better than than not including the data at all.

Perhaps in the future the client could specify which YANG modules it cares about, in addition to a subtree filter. Then you could put the extended diagnostic information into another module (using "augment"), and clients that don't know about the extended diagnostic information wouldn't request it, and clients that do would know to only request it when they need it.

The problem also makes me think of ConfD's "hide groups", but it's hard to see how those would be extended to support programmatic interfaces.

________________________________
From: netmod <[email-masked]> on behalf of Robert Wilton <[email-masked]>
Sent: Wednesday, 7 December 2016 3:58 a.m.
To: Athanasios Kyparlis; [email-masked]
Subject: Re: [netmod] Modelling different "levels" of data in YANG

Hi Athanasios,

Thanks for the suggestion.  As per my reply to Vladimir, I think that this solves the question of how to get them, but doesn't really solve the issue of how a client is expected to know that they wouldn't be included in a regular get request.

Thanks,
Rob

________________________________
From: netmod <[email-masked]><mailto:[email-masked]> on behalf of Robert Wilton <[email-masked]><mailto:[email-masked]>
Sent: Monday, December 5, 2016 1:10:47 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Peter Jones
Subject: [netmod] Modelling different "levels" of data in YANG

Hi,

Input welcome.  Thanks,
Rob

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

---

From: Athanasios Kyparlis <[email-masked]>
Date: Tue, 6 Dec 2016 21:27:21 +0000

From: Athanasios Kyparlis
Sent: Tuesday, December 6, 2016 4:06 PM
To: 'Alex Campbell' <[email-masked]>; Robert Wilton <[email-masked]>; [email-masked]
Subject: RE: [netmod] Modelling different "levels" of data in YANG

To answer Rob's question (if I understand it correctly), the client would know the data is not included in a regular get, as the data definition will only exist in the action/rpc output definition.

Thanks

From: Alex Campbell [mailto:[email-masked]]
Sent: Tuesday, December 6, 2016 4:03 PM
To: Robert Wilton <[email-masked]<mailto:[email-masked]>>; Athanasios Kyparlis <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [netmod] Modelling different "levels" of data in YANG

________________________________
From: netmod <[email-masked]<mailto:[email-masked]>> on behalf of Robert Wilton <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, 7 December 2016 3:58 a.m.
To: Athanasios Kyparlis; [email-masked]<mailto:[email-masked]>
Subject: Re: [netmod] Modelling different "levels" of data in YANG

Hi Athanasios,

Thanks,
Rob

Hi,

Input welcome.  Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 Dec 2016 22:40:41 +0100

I fear that a dumb client sending a <get/> without a proper filter to
select the data that is relevant for the client will not necessarily
get smarter by defining additional operations.

Sometimes access control can help to control dumb clients that try to
get everything (and then ignore most of the data they receive); simply
make sure that only the information is accessible to a client that is
actually needed by a client. In other words, the filtering logic does
not have to be hard coded in the data model.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Vladimir Vassilev <[email-masked]>
Date: Wed, 7 Dec 2016 12:25:59 +0100

> not have to be hard coded in the data model.
+1

One additional solution for consideration is a new top level 
config=false container with a list e.g. 
/ethernet-interfaces-state/ethernet-interface/... where the key is 
leafref to /interfaces-state/interface/name With this solution IMO all 
requirements mentioned in the discussion so far are satisfied without 
the need to introduce any RPCs or hard coding filtering logic in the model.

/Vladimir

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 7 Dec 2016 13:57:01 +0100

On Wed, Dec 07, 2016 at 12:25:59PM +0100, Vladimir Vassilev wrote:
> One additional solution for consideration is a new top level config=false
> container with a list e.g. /ethernet-interfaces-state/ethernet-interface/...
> where the key is leafref to /interfaces-state/interface/name With this
> solution IMO all requirements mentioned in the discussion so far are
> satisfied without the need to introduce any RPCs or hard coding filtering
> logic in the model.
>

This may help until the dumb client grabs /ethernet-interfaces-state
as well.

/js

---

From: Vladimir Vassilev <[email-masked]>
Date: Wed, 7 Dec 2016 14:30:12 +0100

On 12/06/2016 10:03 PM, Alex Campbell wrote:

> IMO using an action or rpc is an okay solution for now, certainly 
> better than than not including the data at all.
>
If I have to chose between RPC with 'output' containing the state data 
for selected interface and mapping the data to a container/list not 
under /interfaces-state (e.g. another top level container) I prefer the 
second option since notifications and data models in general can refer 
to it as part of the data tree. It allows for simpler monitoring and 
implementation of alarms etc.
>
>
> Perhaps in the future the client could specify which YANG modules it 
> cares about, in addition to a subtree filter. Then you could put the 
> extended diagnostic information into another module (using "augment"), 
> and clients that don't know about the extended diagnostic information 
> wouldn't request it, and clients that do would know to only request it 
> when they need it.
One can use xpath 1.0 filter. This option is already available. Example 
<get> RPC retrieving only state data of interest.

...
   <get>
     <filter type="xpath" 
select="//*[namespace-uri()='urn:ietf:params:xml:ns:yang:ietf-interfaces' 
or namespace-uri()='urn:ietf:params:xml:ns:yang:ietf-system']"/>
   </get>
...

Sane server implementations will skip the time consuming calbacks 
retrieving detailed data defined in other modules then ietf-intefaces 
and ietf-system.

/Vladimir

---

From: Robert Wilton <[email-masked]>
Date: Wed, 7 Dec 2016 14:39:00 +0000

Hi,

On 07/12/2016 13:30, Vladimir Vassilev wrote:
> under /interfaces-state (e.g. another top level container) I prefer 
> the second option since notifications and data models in general can 
> refer to it as part of the data tree. It allows for simpler monitoring 
> and implementation of alarms etc.

Given that there is a desire (draft-nmdsdt-netmod-revised-datastores-00, 
section 6.4) to deprecate "/foo-state" and to merge it with the 
configuration held under "/foo" then I would think that introducing a 
new top level "/foo-diagnostics" would seem to be heading in the wrong 
direction.

Athanasios' suggestion to just define RPCs for this information, and 
only make the information available via RPC operations, seems like a 
reasonable one.  Clients don't get spammed with stuff that they don't 
care about, but the information is still programmatically available if 
it is required.

>> extended diagnostic information into another module (using 
>> "augment"), and clients that don't know about the extended diagnostic 
>> information wouldn't request it, and clients that do would know to 
>> only request it when they need it.
> One can use xpath 1.0 filter. This option is already available. 
> Example <get> RPC retrieving only state data of interest.
>
> ...
>   <get>
>     <filter type="xpath" 

Alas, xpath filtering is optional, and I'm not sure how many devices 
have implemented support for it.  Further, this still requires every 
client to be coded to avoid receiving the information that they are very 
unlikely to be interested in.

I would much prefer a solution where the clients don't get this (mostly 
noise) data unless they explicitly ask for it.  Otherwise for an 
Ethernet interface you might return 10 leaves of potentially useful 
opstate information, along with 50+ leaves of quite low layer 
diagnostics information that is likely to be of very little use except 
for to the select few people that are actively involved in trying to 
diagnose hardware faults.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 7 Dec 2016 17:13:36 +0100

On Wed, Dec 07, 2016 at 02:39:00PM +0000, Robert Wilton wrote:
> 
> Alas, xpath filtering is optional, and I'm not sure how many devices have
> implemented support for it.  Further, this still requires every client to be
> coded to avoid receiving the information that they are very unlikely to be
> interested in.
> 
> noise) data unless they explicitly ask for it.  Otherwise for an Ethernet
> interface you might return 10 leaves of potentially useful opstate
> information, along with 50+ leaves of quite low layer diagnostics
> information that is likely to be of very little use except for to the select
> few people that are actively involved in trying to diagnose hardware faults.
>

I expect that there will be many augmentations to lets say /interfaces
(or /interfaces-state). How does a data model writer determine which
ones are 'noise' and which ones are not? How does a a data model
writer determine which ones are costly to implement and which ones are
not (since this may vary widely between systems)?

Perhaps it is useful to tell client writers that well behaving clients
should ask for what they need (and understand) and that they should
avoid asking generic 'give me everything you have' questions.

If you have to deal with lazy clients that like to grab everything,
you can control them via NACM. Simply exclude access to some branches.

/js

---

From: Robert Wilton <[email-masked]>
Date: Thu, 8 Dec 2016 17:49:11 +0000

> not (since this may vary widely between systems)?
It isn't so much as it being noise. I see that the two quite different 
sets of config false nodes are:

(1) The first set of nodes are those that are useful to a client to 
manage a device and to determine whether the device's actual behaviour 
matches the expected behaviour based on the configuration.  This is the 
same set of data that has traditionally been modeled via SNMP, and I 
think of as being the operational state of the device.

(2) If it is determined from the nodes above that a device is behaving 
in an abnormal way, then the second set of nodes are aimed at device 
developers/engineers to ascertain why the device is not behaving as 
specified.  A lot of this internal diagnostics information may only be 
of use to a developer who is familiar with the code (or intricacies of 
the hardware), and/or has a deep level of understanding of how a 
particular feature works.  I would see that most of this information is 
very likely to be device specific, and presented in a device specific 
way, and may include internal debug and dumps of internal data-structures.

I believe that most of the time, operators are only interested in 
interacting with that first set of data because that is all that is 
useful and required to manage their devices, and hence that is what I 
think should be modeled in the operational state datastore. However, in 
many cases, having a standard automated way of fetching that second set 
of data is still useful, because it facilitates more efficient 
diagnostic tools to be created in the future.

Specifically for Ethernet, 802.3 specifies a clear separation between 
what they expect to be made available via a management protocol vs what 
is regarded as being an internal API, specifically:
  -802.3 Clause 30 specifies the main management objects, that I would 
expect to be broadly accessible to management clients, and what we are 
planning on basing the Ethernet YANG on.  (This is consistent with what 
is available in the Ethernet related MIBs and the OpenConfig Ethernet 
model).
  - the internal interface is defined as the MDIO registers in 802.3 
Clause 45.  Looking at these register definitions, although the 
registers themselves can be given meaningful names, the values 
themselves would probably just be returned as opaque 16 bit register 
values, since the YANG "bits" type isn't flexible enough to represent 
the packed values they sometimes contain (specifically where they are 
using a set of bits to represent an enumerated value).

> avoid asking generic 'give me everything you have' questions.
I really think that there are two separate classes of data here, and it 
makes more sense to treat them as such.

Defining RPCs to fetch the internal diagnostics data on demand seems OK 
to me, or alternatively marking the nodes as being diagnostics related 
and putting that in a separate datastore would seem to be reasonable.

> you can control them via NACM. Simply exclude access to some branches.
This will likely just mean that every device would have to support this 
NACM to handle the mainline case.  That sounds like a lot of extra 
unnecessary work for everyone.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 8 Dec 2016 20:11:11 +0100

On Thu, Dec 08, 2016 at 05:49:11PM +0000, Robert Wilton wrote:
> It isn't so much as it being noise. I see that the two quite different sets
> of config false nodes are:
> 
> (1) The first set of nodes are those that are useful to a client to manage a
> device and to determine whether the device's actual behaviour matches the
> expected behaviour based on the configuration.  This is the same set of data
> that has traditionally been modeled via SNMP, and I think of as being the
> operational state of the device.
> 
> (2) If it is determined from the nodes above that a device is behaving in an
> abnormal way, then the second set of nodes are aimed at device
> specified.  A lot of this internal diagnostics information may only be of
> use to a developer who is familiar with the code (or intricacies of the
> hardware), and/or has a deep level of understanding of how a particular
> feature works.  I would see that most of this information is very likely to
> be device specific, and presented in a device specific way, and may include
> internal debug and dumps of internal data-structures.

The simply disable this module on a production system.
 
> interacting with that first set of data because that is all that is useful
> and required to manage their devices, and hence that is what I think should
> be modeled in the operational state datastore. However, in many cases,
> having a standard automated way of fetching that second set of data is still
> useful, because it facilitates more efficient diagnostic tools to be created
> in the future.

Than leave the data model active and make NACM grant access to this
data only for engineers.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 09 Dec 2016 11:33:59 +0100

Hi Rob,

I didn't follow the previous discussion closely but a natural solution
seems to be to define a leaf like "debug" - it could be just boolean or
an enumeration of debug levels. And then add the diagnostic
data as an augment that conditionally depends on the value of the
"debug" leaf.

Would this work?

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Robert Wilton <[email-masked]>
Date: Fri, 9 Dec 2016 10:48:46 +0000

Hi Lada,

> data as an augment that conditionally depends on the value of the
I'm not sure.

Historically debug has been separate from configuration.  I.e. you 
wouldn't normally expect debug settings to persist after rebooting the 
device.  Possibly debug could be modeled using I2RS, but that would be 
tying its fate to I2RS, and I'm not sure whether I2RS will gain 
widespread adoption.

Although I raised my concern specification related to Ethernet clause 45 
registers, I think that my question is really more general about whether 
debug/diagnostics should be modeled in YANG and if so how that should be 
done.   Perhaps, we should just concentrate on getting the basis config 
and operational state models sorted out initially and then figure out 
how diagnostics should be modeled at a later date?

Rob

---

From: Robert Wilton <[email-masked]>
Date: Fri, 9 Dec 2016 10:54:14 +0000

> The simply disable this module on a production system.

Alas I don't think that this would help.  The aim is that the 
information is still available on production systems, just not returned 
by default.

> Than leave the data model active and make NACM grant access to this
Assuming that diagnostics information was specified for each of N 
different protocols on a device.  Then this would seem to mean that 
every device would have to install N default NACM deny entries (one for 
each supported protocol) to ensure that the device has sensible default 
operator semantics.  This would seem to be quite a burden on the industry.

A solution that doesn't rely on every server inserting lots of NACM 
entries by default seems like a better choice to me.

Thanks,
Rob

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 9 Dec 2016 11:54:20 +0100

> On 9 Dec 2016, at 11:48, Robert Wilton <[email-masked]> wrote:
> 
> Hi Lada,
> 
> 
> Historically debug has been separate from configuration.  I.e. you wouldn't normally expect debug settings to persist after rebooting the device.

Yes, good point. So what you can do is to have a "debug" RPC, show "debug" value in state data, and still make the augment with diagnostics conditionally dependent on the debug leaf.

Lada

> Possibly debug could be modeled using I2RS, but that would be tying its fate to I2RS, and I'm not sure whether I2RS will gain widespread adoption.
> 
> Although I raised my concern specification related to Ethernet clause 45 registers, I think that my question is really more general about whether debug/diagnostics should be modeled in YANG and if so how that should be done.   Perhaps, we should just concentrate on getting the basis config and operational state models sorted out initially and then figure out how diagnostics should be modeled at a later date?
> 
> Rob
> 
>> Lada
>>

---

From: Robert Wilton <[email-masked]>
Date: Fri, 9 Dec 2016 11:05:47 +0000

> Yes, good point. So what you can do is to have a "debug" RPC, show "debug" value in state data, and still make the augment with diagnostics conditionally dependent on the debug leaf.
OK, so this is closer, but still would mean that enabling the debug flag 
via RPC would potentially cause all clients to start to see the 
diagnostics information (which may break them).

Hence I think that there is a requirement that the diagnostics data is 
restricted to only the specific client session that it has been 
requested on/enabled on.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 9 Dec 2016 12:16:36 +0100

On Fri, Dec 09, 2016 at 11:05:47AM +0000, Robert Wilton wrote:
> 
> OK, so this is closer, but still would mean that enabling the debug flag via
> RPC would potentially cause all clients to start to see the diagnostics
> information (which may break them).
>

A client that breaks when receiving unknown data is a broken client. The
earlier they fall apart the better so that they get fixed.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 9 Dec 2016 12:19:38 +0100

On Fri, Dec 09, 2016 at 10:54:14AM +0000, Robert Wilton wrote:
> 
> Assuming that diagnostics information was specified for each of N different
> protocols on a device.  Then this would seem to mean that every device would
> have to install N default NACM deny entries (one for each supported
> protocol) to ensure that the device has sensible default operator semantics.
> This would seem to be quite a burden on the industry.
> 
> A solution that doesn't rely on every server inserting lots of NACM entries
> by default seems like a better choice to me.
>

Did I say that there need to be N? And why would N hard coded toggles
in data models be simpler and not a burden for the industry? What is
the definition of 'burden for the industry' anyway?

/js

---

From: Robert Wilton <[email-masked]>
Date: Fri, 9 Dec 2016 11:25:35 +0000

> earlier they fall apart the better so that they get fixed.
Even if they don't break, debug and diagnostics information can be very 
verbose.

If a client had 4 connections to a device for monitoring different 
things, then you don't want to suddenly start sending a large amount of 
extra diagnostics data on each of the 4 connections when they have only 
requested it on one connection.  Generating this extra data could 
overload the client or the device, or certainly lead to degraded 
performance in some way or another.

Thanks,
Rob

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 9 Dec 2016 12:43:18 +0100

> On 9 Dec 2016, at 12:05, Robert Wilton <[email-masked]> wrote:
> 
> 
> 
> OK, so this is closer, but still would mean that enabling the debug flag via RPC would potentially cause all clients to start to see the diagnostics information (which may break them).

You can add finer granularity by making "debug" into an action on an interface, and then I think it's not a big deal. 

> 
> Hence I think that there is a requirement that the diagnostics data is restricted to only the specific client session that it has been requested on/enabled on.

Then an RPC returning the diagnostics, as Vladimir suggested, might be the best option.

Lada

---

From: Robert Wilton <[email-masked]>
Date: Fri, 9 Dec 2016 11:46:39 +0000

Hi Juergen,

On 09/12/2016 11:19, Juergen Schoenwaelder wrote:
> Did I say that there need to be N?
No, I had extrapolated. :-)

Please can you expand on your proposed solution if using just one NACM 
entry.

>   And why would N hard coded toggles
> in data models be simpler and not a burden for the industry?
1. Because by default there is no additional filtering cost to excluding 
diagnostics data from get/push requests on the operational state datastore.
2. The names of the RPCs could be defined by convention, and hence 
handled in a generic way.
3. Defining RPCs isn't my preferred solution, but it feels like the most 
pragmatic one available today.  I think that diagnostics is a 
fundamentally different level of operational state data that may be 
better served using a separate datastore that sits below the operational 
state datastore.  I.e. it "sees" everything in the operational state 
datatstore but also contains the extra diagnostics information as well.  
The diagnostic specific nodes would be marked in the schema, same as 
config, i2rs, etc, presumably defined in a YANG extension.

>   What is
OK, I agree that it was a nebulous term, but my two specific concerns are:
1. Everyone who implements the model also needs to implement a NACM 
entry to only return the data that 99% of clients are likely to be 
generally interested in.
2. I am concerned about the server performance overhead of the extra 
NACM entry/entries for the mainline case.
3. I think that it requires client to know by magic that the diagnostics 
information isn't returned by default (but if done in a uniform way this 
could be solved by convention).

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 9 Dec 2016 13:06:53 +0100

On Fri, Dec 09, 2016 at 11:25:35AM +0000, Robert Wilton wrote:
> If a client had 4 connections to a device for monitoring different things,
> then you don't want to suddenly start sending a large amount of extra
> diagnostics data on each of the 4 connections when they have only requested
> it on one connection.  Generating this extra data could overload the client
> or the device, or certainly lead to degraded performance in some way or
> another.
>

Then the client probably should have used a proper filter. Augments
are a key feature of YANG. A client not interested in any additional
data should not (implicitely) ask for it. (It does not matter whether
the additional data is debugging or other information; if you do not
need it, do not as for it if you want to be robust.)

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 9 Dec 2016 13:17:36 +0100

> Please can you expand on your proposed solution if using just one NACM

Perhaps we talk past each other because 'NACM entry' is ambiguous. I mean
one 'rule-list' entry, you probably mean N 'rule' entries.
 
> 2. The names of the RPCs could be defined by convention, and hence handled
> in a generic way.

I generally dislike any solutions that relies on 'naming conventions'.

> pragmatic one available today.  I think that diagnostics is a fundamentally
> different level of operational state data that may be better served using a
> separate datastore that sits below the operational state datastore.  I.e. it
> "sees" everything in the operational state datatstore but also contains the
> extra diagnostics information as well.  The diagnostic specific nodes would
> be marked in the schema, same as config, i2rs, etc, presumably defined in a
> YANG extension.

Perhaps you just want to dynamically enable/disable data models
supported by a device?

/js

---

From: Robert Wilton <[email-masked]>
Date: Fri, 9 Dec 2016 15:00:38 +0000

> need it, do not as for it if you want to be robust.)
Given that an augmentation could be on any container, then I think that 
this ends up that every get request needs a potentially complex subtree 
filter to exclude diagnostics information that they wouldn't really 
expect to be returned in the first place.  Further, if the diagnostics 
information was controlled by a debug leaf then they probably won't ever 
see this problem during testing, only when someone needs to get 
diagnostics information for an Ethernet interface on a production system 
would the extra data start showing up.

To me, this seems to be making YANG models easier for the 0.01% of 
client request at the expense of the 99.99% of client requests.

Thanks,
Rob

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 09 Dec 2016 16:17:12 +0100 (CET)

Robert Wilton <[email-masked]> wrote:
> >> things,
> Given that an augmentation could be on any container, then I think
> that this ends up that every get request needs a potentially complex
> subtree filter to exclude diagnostics information that they wouldn't
> really expect to be returned in the first place.  Further, if the
> diagnostics information was controlled by a debug leaf then they
> probably won't ever see this problem during testing, only when someone
> needs to get diagnostics information for an Ethernet interface on a
> production system would the extra data start showing up.
> 

The problem is that it is a slippery slope.  Anyone that designs a
data model might think that some data probably not is interesting to
all clients, in all cases, so they might just create special RPCs
instead of modelling it as config false data.

It would be better to model it as config false and work on the
protocol to have better filters (like Andy's recently proposed
"topic-filter" maybe).

/martin

---

From: Robert Wilton <[email-masked]>
Date: Fri, 9 Dec 2016 18:10:35 +0000

> instead of modelling it as config false data.
I would say that a clear separation is fairly easy to define, and the 
industry has managed to do this fairly well for the last few decades:
- If the information is necessary to manage or monitor a device then it 
should be included in opstate.
- if the information is only required for an engineer to diagnose why 
the device isn't working to the specification then it isn't part of the 
opstate.

There are lots of examples of this:
  1) a simple car analogy:
  - my car dashboard gives me the useful information that I need to 
safely drive the car, and to monitor that the car is behaving as designed.
  - if the car stops working properly (perhaps it signals a fault on the 
dashboard), then I take it to garage, they connect it to a computer, 
download and analyze the diagnostics to figure out what is wrong 
(normally at large expense).
  - as a user of the car, I do not want to see all of that internal 
diagnostics information on the dashboard all the time.  It would obscure 
the information that is actually important, and I probably wouldn't 
understand what it all means anyway.

2) My alarm system at home has a "User mode" and "Engineer mode", the 
information presented in each mode differs.  I think that this sort of 
example can probably be repeated for nearly all of the consumer 
electronics that I own.

3) The same is for network devices:
As a operator of an Ethernet interface, I care:
  - whether the port is up and able to forward packets, or it is down.
  - if it is down, whether it is something that I can diagnose and fix 
(e.g. config error, dirty cable, missing PHY).
But I don't personally want to know whether the "PHY XS provides 
information on transmit path data
delay in registers 4.1801 through 4.1804" or whether "PHY XGXS is able 
to generate test patterns".  However, an engineer might find this 
information useful to diagnose why the Ethernet port isn't working the 
way that it should.

I think that there is a clear split in the intent of this information, 
and what audience the information is targeted to.

I can't see how always lumping these two discrete sets of data together 
really helps anyone.

Thanks,
Rob

---

From: Andy Bierman <[email-masked]>
Date: Fri, 9 Dec 2016 10:50:13 -0800

On Fri, Dec 9, 2016 at 10:10 AM, Robert Wilton <[email-masked]> wrote:

> - if the information is only required for an engineer to diagnose why the
> device isn't working to the specification then it isn't part of the opstate.
>
>  - my car dashboard gives me the useful information that I need to safely
> drive the car, and to monitor that the car is behaving as designed.
> download and analyze the diagnostics to figure out what is wrong (normally
> at large expense).
> example can probably be repeated for nearly all of the consumer electronics
> that I own.
>
> delay in registers 4.1801 through 4.1804" or whether "PHY XGXS is able to
> generate test patterns".  However, an engineer might find this information
> useful to diagnose why the Ethernet port isn't working the way that it
> should.
>
> I think that there is a clear split in the intent of this information, and
> what audience the information is targeted to.
>

Why can't you use a when-stmt?

 <top>
     <diag-mode>system</diag-mode>
     <service>
         ...
        <diag-stats>
            // config false
            //  when  "/top/diag-mode = 'system'"
        </diag-stats>
     </service>
 </top>

Thanks,
> Rob
Andy

---

From: Kent Watsen <[email-masked]>
Date: Fri, 9 Dec 2016 21:02:24 +0000

>            //  when  "/top/diag-mode = 'system'"

Can we have a solution that is session-oriented, like with-defaults?   Maybe the ‘when’ expression’s context could be extended to the client’s request, or otherwise be triggered by something in the request?

Kent // as a contributor

---

From: Andy Bierman <[email-masked]>
Date: Fri, 9 Dec 2016 13:30:48 -0800

On Fri, Dec 9, 2016 at 1:02 PM, Kent Watsen <[email-masked]> wrote:

> Can we have a solution that is session-oriented, like with-defaults?
> Maybe the ‘when’ expression’s context could be extended to the client’s
> request, or otherwise be triggered by something in the request?
>
>
>

I prefer not to use specialized <get-foo> operations.
In the usage model that Rob described, the service tech will be
setting diag-mode to 'system'  then retrieving the extra 'diag-stats',
then setting diag-mode back to 'user'.

NACM is only needed on the leaf /top/diag-mode to prevent users from
setting it to  system mode.

Kent // as a contributor

Andy

---

From: Kent Watsen <[email-masked]>
Date: Sat, 10 Dec 2016 00:59:08 +0000

> I prefer not to use specialized <get-foo> operations.

Agreed, I was thinking something more along the lines of:

   <get-config>
      <source>
         <operational-state/>
      </source>
      <with-diagnostics/>            <--- note this flag here
      <filter type="subtree">
         <top xmlns="http://example.com/schema/1.2/config">
            <foo>
              <bar/>
            </foo>
         </top>
      </filter>
   </get-config>

Thus explicitly requesting all the extra stuff get returned...

>then setting diag-mode back to 'user'.

Right, but this does not seem ideal as the diag-mode toggle is a global setting that would affect all clients for some window of time, or do we envision diag-mode dropping the system down to single-user mode?

Kent  // contributor

---

From: Robert Wilton <[email-masked]>
Date: Mon, 12 Dec 2016 10:39:04 +0000

Hi Andy,

On 09/12/2016 18:50, Andy Bierman wrote:
<snip/>
>             //  when  "/top/diag-mode = 'system'"
A when statement has two problems:
i) It affects all clients that are making requests to read the data (or 
potentially YANG push subscription requests).
ii)) It turns on diagnostics everywhere.

I don't believe that you can do either of these things safely on a large 
production system, since you could easily be increasing the amount of 
config false data being generated by the system by a factor of 10 or more.

For the systems that I work on, using CLI based commands, there are 3 
ways that diagnostics related information is commonly obtained today:
1) An operator knows that one physical interface (potentially out of a 
thousand) has a problem, and wants to obtain some additional diagnostics 
information for that specific interface, but not affect any other 
interface, or any other management client/request.  I think that 
fetching the Ethernet clause 45 registers fits into this category.
2) For some other issues that need to be diagnosed it isn't immediately 
obvious which area of the system the problem is in. Hence, this second 
set of commands fetches a lot of general operational data and 
diagnostics information from a subset of the daemons in the system.  The 
clause 45 registers could be included in this data set, or they may be 
omitted because they are slow to retrieve from the hardware.
3) The third category is debug that is enabled and then is streamed to 
the console, a telnet session, or a syslog buffer.  For our systems, it 
would be less common to turn on the debug on a production device, and 
more generally this debug would be used during feature development.

It is the data for (1) and (2) that I think could be best served if the 
diagnostics leaves were explicitly labelled in the model, and then if 
get requests/subscriptions could filter on that label. Perhaps putting 
these diagnostics into a separate operational datastore would be a 
cleanest way to handle this?

Thanks,
Rob

>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/netmod>
>
>

---

From: Robert Wilton <[email-masked]>
Date: Mon, 12 Dec 2016 11:10:36 +0000

Hi Kent,

> Thus explicitly requesting all the extra stuff get returned...
Yes, that is roughly along the lines that I was thinking.

Or building on draft-nmdsdt-netmod-revised-datastores:
- presuming the existing of a <get-data/> operation to generically 
return the contents of any datastore,
- defining a new <diagnostics> datastore that contains the contents of 
the <operational-state> along with all config false schema nodes 
labelled as "diagnostics true".

    <get-data>

       <source>

          <diagnostics/>

       </source>

       <filter type="subtree">

         ....

   <get-data/>

Thanks,
Rob

> Right, but this does not seem ideal as the diag-mode toggle is a 
> global setting that would affect all clients for some window of time, 
> or do we envision diag-mode dropping the system down to single-user mode?
>
> Kent  // contributor
>

---

From: Kent Watsen <[email-masked]>
Date: Mon, 12 Dec 2016 16:47:42 +0000

Hi Robert,

You’re right, it should’ve been the <get-data> (not <get-config>).   However, I think that it’s better to use a flag on the <operational-state> datastore, rather than to define a new datastore.  Not only would it mimic how with-defaults works, but it also seems more intuitive from a retrieval perspective, as the diagnostics nodes could be sprinkled throughout a data model, and a single <get-data> could return all nodes (not just the diagnostics) for a given subtree.    Thoughts?

Separately, from a modelling perspective, presumably there would have to be an additional flag to go with the config false flag, something like the below.  Is this what you were envisioning?

    container thermostat {
        leaf configured-temperature {
            type int8;
        }
        leaf current-temperature {
            config false;
            type int8;
        }
        container diagnostics {
            config false;
            diagnostics true;    <-- new flag here
            ...
        }

Is all this leading up to a draft?  ;)

Kent  // contributor

From: Robert Wilton <[email-masked]>
Date: Monday, December 12, 2016 at 6:10 AM
To: Kent Watsen <[email-masked]>, Andy Bierman <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [netmod] Modelling different "levels" of data in YANG

Hi Kent,

   <get-config>
      <source>
         <operational-state/>
      </source>
      <with-diagnostics/>            <--- note this flag here
      <filter type="subtree">
         <top xmlns="http://example.com/schema/1.2/config"<http://example.com/schema/1.2/config>>
            <foo>
              <bar/>
            </foo>
         </top>
      </filter>
   </get-config>

Or building on draft-nmdsdt-netmod-revised-datastores:
- presuming the existing of a <get-data/> operation to generically return the contents of any datastore,
- defining a new <diagnostics> datastore that contains the contents of the <operational-state> along with all config false schema nodes labelled as "diagnostics true".
   <get-data>
      <source>
         <diagnostics/>
      </source>
      <filter type="subtree">
        ....
  <get-data/>

Thanks,
Rob

Kent  // contributor

---

From: Vladimir Vassilev <[email-masked]>
Date: Thu, 15 Dec 2016 20:23:12 +0100

Hi,

Here is a summary of the proposed solutions so far:

* The solution with introduction of YANG statement "diagnostics true;", 
additional datastore and NETCONF protocol change. IMO that sounds heavy 
but valid solution.
* The solution with RPC returning the data as output. IMO has the 
limitation of not presenting the diagnostics data in the data tree (no 
valid instance-identifiers to be used in notifications). But is the 
simplest to have in place.
* The solution with RPC enabling the containers only for a certain session.

I thought also of this alternative solution:  The solution is to avoid 
clobbering the replies to <get>s without filter or <get>s with filter 
matching only parent nodes of the "diagnostics state" container data  
and not return those nodes in the reply except in the cases the filter 
matches data nodes part of the diagnostics data explicitly.

Example for /interfaces-state/interfaces/diagnostics (using xpath filter 
for brevity but valid for the "subtree" case):

These skip "diagnostics":
<get><filter type="xpath" select="/interfaces-state"\></get>
<get><filter type="xpath" select="/interfaces-state/interface"\></get>

These return "diagnostics":
<get><filter type="xpath" select="/interfaces-state/interface/*"\></get>
<get><filter type="xpath" 
select="/interfaces-state/interface/diagnostics"\></get>

This looks like a violation of RFC 6241 6.2.5 bullet 12 but IMO the 
container is non-mandatory diagnostics data so returning it only when 
someone really wants it and not otherwise is the definition of the 
solution to the problem.

/Vladimir

On 12/12/2016 05:47 PM, Kent Watsen wrote:
>
> Hi Robert,
>
> You’re right, it should’ve been the <get-data> (not <get-config>).   
> However, I think that it’s better to use a flag on the 
> <operational-state> datastore, rather than to define a new datastore.  
> Not only would it mimic how with-defaults works, but it also seems 
> more intuitive from a retrieval perspective, as the diagnostics nodes 
> could be sprinkled throughout a data model, and a single <get-data> 
> could return all nodes (not just the diagnostics) for a given 
> subtree.    Thoughts?
>
> Separately, from a modelling perspective, presumably there would have 
> to be an additional flag to go with the config false flag, something 
> like the below.  Is this what you were envisioning?
>
> container thermostat {
>
> *From: *Robert Wilton <[email-masked]>
> *Date: *Monday, December 12, 2016 at 6:10 AM
> *To: *Kent Watsen <[email-masked]>, Andy Bierman <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [netmod] Modelling different "levels" of data in YANG
>
> Hi Kent,
>
>     global setting that would affect all clients for some window of
>     time, or do we envision diag-mode dropping the system down to
>     single-user mode?
>
>     Kent  // contributor
>

---

From: Robert Wilton <[email-masked]>
Date: Fri, 16 Dec 2016 11:19:20 +0000

Hi,

A variant on your suggestion:

Rather than "diagnostics true;" a potentially more general way of 
handling this could be a generalized schema flag to indicate that a 
particular node (and its children) is never returned unless explicitly 
requested.  E.g. "hidden: true" instead of "diagnostics: true".  The 
data would only be returned if either (i) the filter explicitly 
indicated that hidden data should be returned (as per Kent's 
suggestion), or possibly also (ii) if the request path (or filter) 
explicitly specified the hidden node(s).

Thanks,
Rob

On 15/12/2016 19:23, Vladimir Vassilev wrote:
> * The solution with introduction of YANG statement "diagnostics 
> true;", additional datastore and NETCONF protocol change. IMO that 
> sounds heavy but valid solution.
> Example for /interfaces-state/interfaces/diagnostics (using xpath 
> filter for brevity but valid for the "subtree" case):
>
>> <operational-state> datastore, rather than to define a new 
>> datastore.  Not only would it mimic how with-defaults works, but it 
>> also seems more intuitive from a retrieval perspective, as the 
>> diagnostics nodes could be sprinkled throughout a data model, and a 
>> single <get-data> could return all nodes (not just the diagnostics) 
>> for a given subtree.    Thoughts?
>>
>> - defining a new <diagnostics> datastore that contains the contents 
>> of the <operational-state> along with all config false schema nodes