Subject: Re: [RMONMIB] smilint messages for APM-MIB

From: Randy Presuhn <[email-masked]>
Date: Tue, 6 Aug 2002 17:32:25 -0700 (PDT)

Hi -

> Message-Id: <[email-masked]>
> Date: Tue, 06 Aug 2002 17:11:49 -0700
> To: Randy Presuhn <[email-masked]>
> From: Andy Bierman <[email-masked]>
> Subject: Re:  [RMONMIB] smilint messages for APM-MIB
> Cc: [email-masked], [email-masked]
> In-Reply-To: <[email-masked]>
...
> Should the RFC 1905 update increase the limit to the same value the
> SMIng WG will use?  IMO, this CLR is too restrictive and has proven
> to be too low a number considering current MIB design practices.
> This CLR was added to SNMP to benefit MIB compiler and MIB engine
> developers, at the expense of MIB designers. 
...

Although in my experience this rule actually complicated MIB
compiler and SNMP engine implementation, and although I've
never liked the limitation, I feel it's important to point
out that RFC 2741 strongly assumes this limitation in the ad
hoc encoding rules it employes.  For example, the AgentX pdu
format only allocates eight bits to locate a sub-identifier.
(I've BCC-ed the AgentX list so that folks there are aware of
this discussion.)

Despite the number of WGs that this would impact, could we
discuss it in just one place?  I really hate adding to the
cross-posting list.

If the proposal is to change the RFC 1905 update, I believe
this belongs on the snmpv3 WG mailing list.

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  1-3141
 [email-masked]  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------

---

From: Bob Natale <[email-masked]>
Date: Fri, 09 Aug 2002 13:09:20 -0400

>At 8/6/2002:08:32 PM, Randy Presuhn wrote:

Hi Randy,

>(I've BCC-ed the AgentX list so that folks there are aware of

Thanks.  An AgentX PDU encodes an OID value using an 8-bit
"m_subid" field (as part of a 4-byte OID-header element) to
record the number of sub-id elements in the OID, with the
corresponding number of 32-bit sub-id values following 
contiguously.  A comment in RFC2741 currently indicates
that the range of "m_subid" is "0-128".

I think AgentX could deal with this by modifying the elements
of procedure to say that if the "m_subid" value in the AgentX
OID header is less than 255 then it contains the number of sub-
id elements as before, but if the value is 255 then the first
32-bit value following the four OID header bytes specifies the
number of sub-id elements comprising the OID, the 32-bit values
for which then follow contiguously as before.

Of course, this would require a change to the specs that
would require re-certifying for interoperability (I suppose).

>discuss it in just one place?  I really hate adding to the

Agreed, I have bcc'd the AgentX list, just to make sure that
any interested parties there join in.

>this belongs on the snmpv3 WG mailing list.

Agreed, but I've kept this reply to [email-masked] until
someone else makes the locus decision.

Cheers,

BobN

---

From: Mark Ellison <[email-masked]>
Date: Fri, 09 Aug 2002 16:17:44 -0400

Hi Bob,

From my perspective, setting h.version = 2 in the AgentX PDU header might
be a better way to start out as I think there will be some additional
AgentX requirements that emerge from current OPS WG efforts.

For example, there may be a need to support a more data-structure oriented
version of the SMI.  Such a change may  impact rules for subtree
registrations, rules for determining authoritative regions, as well as
impacting the AgentX PDU encoding.

It seems it might be nicer/better/easier to bundle together these changes
as version 2 of the AgentX specification.

Regards,

Mark

> >> Subject: Re:  [RMONMIB] smilint messages for APM-MIB

[deletions]

> for which then follow contiguously as before.

[deletions]