Subject: Re: Last Call: The Interfaces Group MIB to Draft Standard

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Tue, 14 Dec 1999 11:19:50 -0800 (PST)

On Tue, 7 Dec 1999, The IESG wrote:

> The IESG has received a request from the Interfaces MIB Working Group
> to consider The Interfaces Group MIB <draft-ietf-ifmib-ifmib2-01.txt>
> as a Draft Standard.
>
> This document will obsolete RFC1573 and RFC2233, currently Proposed
> Standards.
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [email-masked] or [email-masked] mailing lists by December 20, 1999.

There is an anomaly in the conformance information for this MIB module,
carried over from RFC 2233, which should probably be corrected before the
document is advanced.  Specifically, the compliance statement (ifCompliance3)
lists ifCounterDiscontinuityGroup as a mandatory group.  The implication is
that a conforming implementation is obliged to instantiate that group (i.e.
the object ifCounterDiscontinuityTime) for every interface -- even those that
have no counters (DS1, DS3, and SONET interfaces are some examples).

The following justification was offered:

% From: Keith McCloghrie <[email-masked]>
% Message-Id: <[email-masked]>
% Subject: Re: ifCounterDiscontinuityGroup question
% To: [email-masked] (Gary Hanson)
% Date: Tue, 19 May 1998 13:41:25 -0700 (PDT)
% Cc: [email-masked]
...
% > Does anybody know why ifCounterDiscontinuityGroup was listed in RFC
% > 2233 as a mandatory group?
%
% To encourage implementation.
%
% There are very few devices (probably none) which legimately have every
% interface supporting only the ifGeneralInformationGroup.  For those
% that have at least one ifEntry with counters, support for the
% ifCounterDiscontinuityTime really is necessary.  It's easy for such
% an implementation to support ifCounterDiscontinuityTime for interfaces
% which don't have discontinuities: always return zero.

It is not obvious what benefit is gained by instantiating
ifCounterDiscontinuityTime for interfaces that lack counters.  Doing so
does not provide any extra information, nor does it help to avoid "holes"
in ifTable and ifXTable -- those tables have holes in any case.  It is hard
to see how making it a requirement serves to "encourage implementation".

I recently started work to upgrade an RFC 1213-based implementation of the
interfaces group to make it comply with <draft-ietf-ifmib-ifmib2-01.txt>.
A number of the mandatory objects in the ifXTable (notably ifName, ifAlias,
and ifTableLastChange) are not useful in the specific environment in which
I am working.  Nevertheless, I can accept being required to implement them,
because there are environments in which they are useful.  I find it
somewhat harder to accept requirements which are not useful at all.

In my view, it would be much more logical if the ifCounterDiscontinuityGroup
were mandatory only for interfaces with counters.  A context diff containing
edits that would effect that change is attached below my signature.

Mike
--
C. M. Heard/VVNET, Inc.
[email-masked]

*** draft-ietf-ifmib-ifmib2-01.txt	Fri Oct 22 10:11:37 1999
--- draft-ietf-ifmib-ifmib2_revised	Sun Dec 12 12:27:04 1999
***************
*** 2568,2575 ****
  
      MODULE  -- this module
          MANDATORY-GROUPS { ifGeneralInformationGroup,
!                            linkUpDownNotificationsGroup,
!                            ifCounterDiscontinuityGroup }
  
  -- The groups:
  --        ifFixedLengthGroup
--- 2568,2574 ----
  
      MODULE  -- this module
          MANDATORY-GROUPS { ifGeneralInformationGroup,
!                            linkUpDownNotificationsGroup }
  
  -- The groups:
  --        ifFixedLengthGroup
***************
*** 2578,2584 ****
  --        ifHCPacketGroup
  --        ifVHCPacketGroup
  -- are mutually exclusive; at most one of these groups is implemented
! -- for a particular interface
  
          GROUP       ifFixedLengthGroup
          DESCRIPTION
--- 2577,2585 ----
  --        ifHCPacketGroup
  --        ifVHCPacketGroup
  -- are mutually exclusive; at most one of these groups is implemented
! -- for a particular interface.  When any of these groups is implemented
! -- for a particular interface, then ifCounterDiscontinuityGroup must
! -- also be implemented for that interface.
  
          GROUP       ifFixedLengthGroup
          DESCRIPTION
***************
*** 2621,2626 ****
--- 2622,2634 ----
              which are packet-oriented and for which the value of the
              corresponding instance of ifSpeed is greater than
              650,000,000 bits/second."
+ 
+         GROUP       ifCounterDiscontinuityGroup
+         DESCRIPTION
+             "This group is mandatory for those network interfaces that
+             are required to maintain counters (i.e., those for which
+             the ifFixedLengthGroup, ifHCFixedLengthGroup, ifPacketGroup,
+             ifHCPacketGroup, or ifVHCPacketGroup is mandatory)."
  
          GROUP       ifRcvAddressGroup
          DESCRIPTION

---

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Tue, 14 Dec 1999 18:00:37 -0800 (PST)

On Tue, 14 Dec 1999, Hanson,Gary wrote:
>
> [ ... ] I am not sure that there is a whole lot to be gained from
> removing the ifCounterDiscontinuityGroup from the MANDATORY-GROUPS
> list of ifCompliance3.  I agree with Keith's assessment that the
> object can simply be reported as zero for interfaces that have no
> counters (we have done so in our agents with little grief), and that
> defining it as mandatory in the way he did was an expedient way to
> encourage implementation (even if there had been a more logical way
> to encourage it for ONLY those interfaces that really needed it,
> such as what you presented below).

Gary,

I agree that the burden on the implementation is small.  Once I've
written the class to implement ifCounterDiscontinuityTime it costs
me one line of source code and about 40 bytes of memory per interface
to instantiate it.  Still, that is pure dead weight for interfaces
that don't need the object.  The only thing it that leaving it the
MANDATORY-GROUPS buys us is to make the MIB module a few lines shorter.
I made the suggestion to change it now since we probably will not have
another opportunity to do so.

Regards,

Mike
--
C. M. Heard/VVNET, Inc.
[email-masked]