Subject: Re: WG last call for feb 12

From: "Carl W. Kalbfleisch" <[email-masked]>
Date: Mon, 08 Feb 1999 06:20:55 -0600

Ted,

I had posted a note about a month ago concerning the use of the
conformance groups of the IF MIB along with implentations of the DS1/DS3
MIBs. It seems there are devices in our network today which operate in
such a manner as to not implement any of the packet group objects (IE
there is no value for ifInOctets, ifOutOctets, errors, etc) for these
interfaces although based on the configuration of the interface one
would expect these values to be there. Perhaps this could be clarified
some place so that these attributes are implemented. Could 

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

be changed to indicate at least one of these groups is implemented?

Carl

Ted Brunner wrote:
> 
> Hello everyone-
> 
> The draft of the ifmib in the Internet-Drafts directory now
> (draft-ietf-ifmib-ifmib2-00.txt)
> has been their a while without change.
> The remaining issue about inverse stack table was decided
> in favor of a separate document.
> A new version (draft-ietf-ifmib-invstackmib-01.txt) differs
> from the -00.txt version now in the I-D directory
> in small editorial ways, should be sent to you shortly.
> 
> I believe that we have talked ourselves into being
> happiest with these drafts (least unhappy?).
> The next stop for (draft-ietf-ifmib-ifmib2-00.txt)
> is DRAFT-STANDARD, while the next stop for
> (draft-ietf-ifmib-invstackmib-01.txt) is PROPOSED-STANDARD.
> 
> So it is my intention to issue a last call within this working group
> now, with a ending date of 2 weeks from now - feb 12 1999.
> 
> Take a look and think about it, and see if you can be happy
> with these versions.
> 
> In a note to me, Keith mentioned two issues left on the ifmib2
> draft.  I will paraphrase his summary of the situation,
> and offer resolutions to those two issues:
> 
> a) the IANAifTypeMIB from RFC 1573 was omitted from RFC 2233.
> There is no obvious reason to reverse that, and include it now.
> Note this does leave a problem with managing edits to that MIB,
> given changes to IANA's process.  But it is not an obvious
> reason to delay this mib.
> 
> b) ifDuplex.  There was no solid agreement that its inclusion
> will not delay ifmib2's progress to draft.  The hub mib
> draft-ietf-hubmib-etherif-mib-v2-01.txt has an equivalent object,
> and no request has been made to this WG to add a general one.
> The obvious suggestion is not to include it.
> 
> Thanks.
> 
> Ted Brunner             VideoTele.com
>                         Tektronix
>                         MS 50-475
> [email-masked]     14150 SW Karl Braun
> 503.627.1317            Beaverton OR 97005
> 

--
Carl W. Kalbfleisch
Manager NMS Development
Verio Inc., http://www.verio.net

---

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Thu, 11 Feb 1999 21:04:24 -0800 (PST)

Ted Brunner wrote:

> (draft-ietf-ifmib-ifmib2-00.txt) has been their a while without change.
 [ ... ]
> now, with a ending date of 2 weeks from now - feb 12 1999.

I would like to take this opportunity to re-iterate some comments
that I sent to [email-masked] back on 25 Aug 1998.
Specifically, I object to the fact that in draft-ietf-ifmib-ifmib2-00.txt
the ifCounterDiscontinuityGroup is still mandatory.

I think that it should not be, for the reasons outlined
on 19 May 1998 in a message from Gary Hanson, namely that

(a) ifGeneralInformationGroup contains no counters and

(b) some interfaces (e.g., sonet(39), sonetPath(50), and sonetVT(51))
are not required to implement any counters, but only the objects in
the ifGeneralInformationGroup.

The current draft has removed ifStackGroup2 from the list
of mandatory groups;  I suggest that the next version should
remove ifCounterDiscontinuityGroup also.

Cordially,

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

On Tue, 19 May 1998, Gary Hanson wrote:

> Does anybody know why ifCounterDiscontinuityGroup was listed in RFC
> 2233 as a mandatory group?
>
> Given that the group contains only the ifCounterDiscontinuityTime
> object, and given that there are no Counter32 or Counter64 objects
> included in the ifGeneralInformationGroup, it seems odd that this
> object that relates only to Counter32 and Counter64 objects would
> be considered mandatory for all ifTable entries.

On Tue, 19 May 1998, Keith McCloghrie answered:

> 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.
>
> I don't think this has ever been discussed by the WG previously.  When
> the WG decided to add ifCounterDiscontinuityTime, the editor (me) was
> chartered to update the document.  In doing so, I obviously had to make
> a decision of whether ifCounterDiscontinuityGroup should be mandatory
> or not.  You see what I decided, and no one in the WG commented when
> the WG reviewed the updates I made.

---

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Thu, 11 Feb 1999 21:04:24 -0800 (PST)

[ ... ]

Cordially,

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