Subject: RE: IF-MIB (RFC 2233) Question & Errata

From: Jason Perreault <[email-masked]>
Date: Fri, 16 Jan 1998 20:26:28 -0500

More questions related to RFC2233 IF-MIB conformance:

Q1 ---------------------------------------------------------------------

Consistency of DESCRIPTIONs

Reading the DESCRIPTIONs under "GROUP ifFixedLengthGroup"
and "GROUP ifHCFixedLengthGroup" leads me to expect that 
ifFixedLengthGroup will declare objects applicable to all FixedLength 
interfaces regardless of speed, and ifHCFixedLengthGroup will declare 
*supplemental* objects applicable only to HCFixedLength interfaces.

But looking at the OBJECT-GROUP declarations, ifHCFixedLengthGroup
contains all of the objects in ifFixedLengthGroup (in addition to the
HC octet counters), i.e. it is a superset, not a supplemental set.

So, the DESCRIPTIONs of the GROUPs seem a bit misleading. What's
the right fix (assuming anybody agrees there ought to be one)?

Q2 ---------------------------------------------------------------------

AGENT-CAPABILITIES

For a product that supports two or more interface GROUP
categories, how is the AGENT-CAPABILITIES phrased?
Specify all relevant GROUPs, or just the one that describes
the counter set of the most capable interface the agent can
support?

E.g., if an agent has a serial port and an OC-3 ATM port, does it
claim support for ifFixedLengthGroup and ifHCFixedLengthGroup,
or only for ifHCFixedLengthGroup (the superset)?

Is there any issue with the redundant object references
among the GROUPs, when more than one is referenced in a 
capabilities statement?

Is it legal for an agent to advertise, in sysORTable, multiple
capabilities statements for IF-MIB, each expressing support 
for one of the LC/HC/VHC groups? And these sysORTable entries 
are dynamically added/deleted in sync with e.g. installation/removal
of hardware interfaces supporting those capabilities?

Q3 ---------------------------------------------------------------------

Alternate Counter GROUP Decomposition

Why not instead partition counters into disjoint sets as follows:

1. Basic		ifIn/OutOctets, ifIn/OutErrors
2. Packet		ifMtu, 32-bit packet counters (except for
ifIn/OutErrors)
3. HCBasic		ifHCIn/OutOctets
4. HCPacket	64-bit packet counters

with the following GROUP support mappings:

LC fixed length:		1
LC packet:			1,2
HC fixed length:		1,3
HC packet:			1,2,3
VHC packet:		1,2,3,4

Jason

> -----Original Message-----
> From:	Jeff Johnson [SMTP:[email-masked]]
> Sent:	Friday, January 16, 1998 3:41 PM
> To:	[email-masked]
> Cc:	[email-masked]
> Subject:	IF-MIB (RFC 2233) Question & Errata
> 
> [JJP]  <linkUp/linkDown text deleted>
> 
> 2) The DESCRIPTION clause for GROUP ifHCPacketGroup in the
> ifCompliance2 compliance statement is incorrect.  The speed limit
> specified is actually applicable to the ifVHCPacketGroup.  Further,
> GROUP ifVHCPacketGroup was omitted from the compliance statement.
> In other words, there are three PacketGroups defined, but only two
> referenced in the compliance statement.
> 
> thanks
> /jeff

---

From: Keith McCloghrie <[email-masked]>
Date: Sun, 1 Mar 1998 16:10:06 -0800 (PST)

> the right fix (assuming anybody agrees there ought to be one)?

The definitive statement on this issue is in the comment immediately
preceding the group definitions:

   -- the following five groups are mutually exclusive; at most
   -- one of these groups is implemented for any interface

Thus, a clarification is in order to the conformance statement for
ifFixedLengthGroup (i.e., its DESCRIPTION in "GROUP ifFixedLengthGroup")
to make it consistent with the definition of the group (i.e., the
DESCRIPTION for the OBJECT-GROUP).

> the counter set of the most capable interface the agent can
 
Specify all relevant GROUPs.

> or only for ifHCFixedLengthGroup (the superset)?

This particular case doesn't arise, see above.

> among the GROUPs, when more than one is referenced in a 

No.

> of hardware interfaces supporting those capabilities?

Yes.

> with the following GROUP support mappings:
 
While we could have done this, I suggest that 2233's partitioning is
more naturally extensible, e.g., if we needed to define new GROUPs
which might include new objects with some but not all of the objects
in any one existing GROUP.

Keith.