Subject: Re: [netmod] yang 1.1 webex on wednesday october 29th

From: Randy Presuhn <[email-masked]>
Date: Thu, 30 Oct 2014 14:42:32 -0700 (GMT-07:00)

Hi -

>From: Martin Bjorklund <[email-masked]>
>Sent: Oct 30, 2014 1:14 AM
>To: [email-masked]
>Cc: [email-masked]
>Subject: Re: [netmod] yang 1.1 webex on wednesday october 29th
>
>Randy Presuhn <[email-masked]> wrote:
>> Hi -
>> 
>> >From: Andy Bierman <[email-masked]>
>> >Sent: Oct 29, 2014 5:04 PM
>> >To: Juergen Schoenwaelder <[email-masked]>, Andy Bierman <[email-masked]>, "[email-masked]" <[email-masked]>
>> >Subject: Re: [netmod] yang 1.1 webex on wednesday october 29th
>> ...
>> >None of the SNMP server code I worked on supported multiple revisions
>> >of any module in the agent.  There was 1 module loaded for each module name.
>> >SMIv2 has no way to import a specific revision of a definition.
>> 
>> FWIW, though, it's really easy to support this in systems using
>> subagent technology, in part due to the SMI's restrictive rules
>> for revising modules.  It's not terribly likely in single vendor
>> single processor boxes where all the firmware is kept in synch.
>> In "open" systems, and ones in which subagent soft/firmware
>> resides on more-or-less independently updated line cards or similar
>> modules, it can very easily happen.  Coping with this gracefully
>> is one of the big plusses of subagent technologies.
>
>I don't think the subagent mechanism solves the problem.  Suppose you
>have a column in some table in v1 of a MIB.  In v2 this column's
>syntax has an expanded range.

Prohibited by SMIv2's extensibility rules, except for the
very special cases of adding BITS or enumerations.  See RFC 2578
section 10.2.  But anyway...

>  Now, suppose subagent A implements v1
>of the MIB, and registers for one row in the table, and subagent B
>implements v2 of the MIB and registers for another row.  How does the
>SNMP manager know which instances of column C support the new values
>introduced in v2, and which don't?

In SNMP, in general and independently of whether subagent technologies
are in play, the manager doesn't know whether an attempt to set
something to a particular value will succeed until a response
arrives from the agent indicating success or failure, or it
decides that no response is coming.  When there are multiple
instances of an object, success or failure attempting
to set one instance generally doesn't give the manager reliable
information about the likelihood of success or failure for any other
instance.

One *could* use smuxPidentity or agentxSessionObjectID
to point to AGENT-CAPABILITIES statements, but I'm not
aware of anyone bothering to do much of anything with that
information.  I guess that's largely because building robust
SNMP management applications requires tolerating / working
around managed systems' sometimes enigmatic refusals to
do what they are told, and adding version-specific logic
would add complexity without commensurate value.

Randy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 30 Oct 2014 22:58:41 +0100 (CET)

Randy Presuhn <[email-masked]> wrote:
> >> >To: Juergen Schoenwaelder <[email-masked]>, Andy
> >> >Bierman <[email-masked]>, "[email-masked]" <[email-masked]>
> very special cases of adding BITS or enumerations.

... and thus is not prohibited.  I should have been more explicit:

  Suppose you have an enumeration column in some table in v1 of a MIB.
  In v2 this column's syntax has an expanded range.

> would add complexity without commensurate value.

My point was that your statement:

  it's really easy to support this in systems using subagent
  technology,

isn't quite correct.  It seems you are saying that a manager cannot
really know what to expect from the agent.  Of course, as Andy noted,
things are simpler when we're doing monitoring rather than
configuration.

/martin