Hello,
On 06/14/2017 01:18 PM, Bogaert, Bart (Nokia - BE/Antwerp) wrote:
That's why these counters are optional in the model: if there is nothing to
return we should indeed not return 0...
-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email protected]]
Sent: 14 June 2017 11:40
To: Robert Wilton <[email protected]>
Cc: Vladimir Vassilev <[email protected]>; Andy Bierman
<[email protected]>; Bogaert, Bart (Nokia - BE/Antwerp)
<[email protected]>; [email protected]
Subject: Re: [netmod] Question on intefaces-state model
On Wed, Jun 14, 2017 at 10:15:22AM +0100, Robert Wilton wrote:
Returning zero values here is not useful, in fact it is misleading. I
think that if a server doesn't have a value to return for a particular
node it is much better to return nothing than to return a false value.
+1.
It took us years to kill this attitude in SNMP land. Saying a counter is
zero and never changes is largely misleading if you actually have no such
counter. It is easy to waste hours of expensive engineering time by given
people fake counters.
/js
I agree that the statistics counter leafs as defined in ietf-interfaces
are optional except the discontinuity-time ("mandatory true;") leaf. You
were right it makes the entire /interfaces-state/interface/statistics
container mandatory even if none of the optional counters are implemented.
The context of the example was the statement by Andy who seemed to
differ on the counters being optional. I was not sure what he ment and
added an example of device not implementing some of the counters without
breaking conformity with ietf-interfaces:
On 06/13/2017 11:15 AM, Vladimir Vassilev wrote:
On 06/12/2017 08:31 PM, Andy Bierman wrote: an <rpc-reply> must
contain an instance of the mandatory leaf.
The mandatory-stmt is very confusing for config=false nodes.
Mandatory=true means
Mandatory=false does not mean optional-to-implement although it sure
looks that way for config=false nodes. Only if-feature can make a
node optional to implement.
If we take serial interface with hardware that only has in-octets and
out-octets counters I would expect to only find these two in
/interfaces-state/interface/statistics + discontinuity-time. Do you
say the rest of the counters must be present (e.g. allways 0) for
proper implementation of ietf-interfaces?
That said you probably also agree that a model with optional leafs is
equivalent to an employment contract where the monthly salary is
optional. State data models should avoid the entropy of allowing
implementations to either implement or not leafs without this being
formal conformance deviation (this being especially valid for basic
counters part of the base ietf model like ietf-interfaces). That causes
greater waste of not only engineering time but runtime traffic as well.
Management applications have to be designed to poll the leafs and make
conditional decisions for each instance and handle missing leafs to
conform to the model.
For example an option to do automated validation of all point to point
links in a topology (by checking counters at source and destination
ports - out-unicast-pkts=in-unicast-pkts ... etc.). All the devices
implement the required capability - ietf-interfaces but some do not
return out-unicast-pkts, out-broadcast-pkts, out-multicast-pkts since
the hardware only provides them with out-total-pkts and in-total-pkts
(not part of ietf-interfaces model).
With that example in mind I have another relevant question:
Is there consensus that this is valid YANG 1.1 and with a mandatory
counters defined like that the stated conformance actually brings some
guarantees the required counter will be implemented:
...
yang-version 1.1;
...
augment "/if:interfaces-state/if:interface/if:statistics" {
leaf in-total-pkts {
mandatory true;
type yang:counter64;
}
leaf out-total-pkts {
mandatory true;
type yang:counter64;
}
}
...
pyang does not like that ("cannot augment with mandatory node
in-total-pkts") and I think it should be valid to add mandatory true
counter leafs to /interfaces-state/interface/statistics
Vladimir
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
