Subject: [netmod] why does deviation-stmt have restrictions?

From: Andy Bierman <[email-masked]>
Date: Mon, 22 Dec 2008 06:12:22 -0800

Hi,

It seems odd that we are placing lots of restrictions on
what a deviation is allowed to change.  I even suggested
that the builtin type MUST NOT change.

I think we have the completely wrong perception
of deviation-stmt.  All these restrictions make
is seem like deviations are an acceptable part of
the data model.  You don't like a clause? -- then just
replace it or remove it with a deviation-stmt.
It's OK in YANG.

There is a strong chance your competitor in the market
will not spin your deviations the same way.  Deviations
are mostly documenting the manner in which the agent does the
WRONG, INCORRECT, NOT COMPLIANT, NON-STANDARD thing.

In that respect, any valid YANG construct should
be OK for a deviation (e.g., you cannot add a units-clause
to a container, but you should replace the units
clause on a leaf if you implemented the units wrong).

Andy

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

---

From: Phil Shafer <[email-masked]>
Date: Mon, 22 Dec 2008 10:47:55 -0500

>WRONG, INCORRECT, NOT COMPLIANT, NON-STANDARD thing.

Completely agree.  Deviations are a means of documenting
how and where the server violates the standard.  They
are not meant to imply that such violations are perfectly
alright, but they are an admission that in the real world,
bad things happen and we are better off knowing about
them that pretending otherwise.

>clause on a leaf if you implemented the units wrong).

Every deviation should be viewed as a impediment to
allowing a box to be managed by a client application.
The more severe the deviation, the worse things get.
Changing ranges is bad, changing units is worse, changing
the meaning is probably fatal.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 22 Dec 2008 08:11:52 -0800

> the meaning is probably fatal.

The NETMOD WG does not have to classify the manner
or perceived severity of every possible deviation.
I was wrong to think this would somehow 'guide' implementors
to do the right thing.

Of course implementing a float32 when the object calls
for a boolean would be really bad.  But this is just
a documentation mechanism and if s/boolean/float32
is what the agent did, then that's what should be reported.

In my SNMP experience, the deviations were rarely as clean
as this YANG mechanism would suggest.  BITS were routinely
implemented wrong, and the NMS just had to hardwire
the 'flip-the-bits' patch or 'bit4-is-really-bit9' patch.

Most deviations can only be specified in a description clause,
such as "will not take effect until next reboot",
or "ARP cache does not get flushed as required by this object."
There are still extremely valuable to the NMS developer,
even though they cannot be automated patches.

Andy