Hi -
On 2021-09-27 11:35 AM, Andy Bierman wrote:
On Mon, Sep 27, 2021 at 10:42 AM Randy Presuhn
<randy_pres...@alumni.stanford.edu
<mailto:randy_pres...@alumni.stanford.edu>> wrote:
Hi -
On 2021-09-27 10:13 AM, Andy Bierman wrote:
...
> SNMP GetNext and GetBulk do not handle missing nodes well at all,
so it
> became
> common practice to return 0 or -1, etc. to simplify client
processing of
> these operations.
> None of the YANG-based protocols have this problem.
In what way would "missing node" processing be substantially different
between the two protocol families? In both cases the server locator
methods need to be able to be able to skip over "not present" instances,
and will get messy if the instrumented code has adopted the otherwise
tidier paradigm of row/instance-wise registration rather than a general
access method for all instances of the class. For the client I can't
see any substantial difference at all between needs to happen to process
the results correctly.
NETCONF and RESTCONF do not have "row skew" problems.
They return subtrees, not individual varbinds like SNMP.
That doesn't change anything for the client or the server.
In both cases the implementation needs to deal with missing values.
(If client code isn't looking at individual varbind index values in
the response to Get-Bulk or Get-Next and somehow assumes that
there's any assurance they'd belong to "the same row", the developer
has yet to earn the title of "rookie" and should be sentenced to
reviewing COBOL accounting software until they repent.)
Retrieving a "table row" in SNMP is much more complicated when some
columns are unimplemented.
That is highly dependent on the tools one is using. In the code
base I know most intimately, no special code (no code at all!) is
needed for unimplemented columns. Where it gets interesting is
where there are "holes" in one or more columns - that is, the sets
of rows represented in the various columns making up a table do not have
the same index value tuples. I see two main sub-cases:
where there is a user-provided locator function for rows or instances,
and where rows have been registered individually with the
infrastructure. In the former case, "holes" are trivial - the
locator skips over any holes, because they don't exist. The latter
case requires more developer work.
From the perspective of generating code to grab values from
instrumentation according to a mapping defined in some IDL, there
should be little difference between SNMP-ish and YANG-ish protocols,
particularly if the information models and the implementation
architecture of the instrumented code are reasonably coherent.
(I know that last bit is sometimes a big assumption.)
A YANG subtree includes all the data the
client is allowed to view, including augmenting nodes.
That's essentially how subagent registration protocols like DPI, SMUX
and AgentX work. Yes, the object-disoriented approach of Get-Next and
Get-Bulk means that lots of stuff irrelevant to the intent of the query
will fly around, both in the subagent protocol as well as the SNMP,
especially with quirky, fine-grained configurations of VACM. But
that does not require the instrumented code to adopted a similarly
scattered implementation strategy. The job of automatically-
generated glue code and infrastructure is to provide the adaptation
between the instrumented implementation, a hopefully somewhat coherent
information model, and the oddities of SNMP protocol. If the developer
has to spend much time worrying about the quirks of a management
protocol, the tools aren't doing their job.
That said, in my non-YANG experience it's a lot cleaner to generate code
to handle sentinel values (and a lot harder for implementers to ignore
them) than it is to assign ambiguous semantics to "missing data" cases.
...
But back to the original issue: In cases like the one under discussion,
the information element in question is *not* absent in the
implementation. Instead, it has a sentinel value chosen to
distinguish one or more interesting situations from the range of
"normal" values suitable for use in other calculations. It seems to
me that using explicit sentinel values in the model (with explicit
labeling of their semantics) is a more accurate reflection
of both the typical implementation strategies as well as providing a
more direct way to communicate the model semantics and avoids
introducing ambiguity.
Randy
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
