Subject: Re: RFC2493 update

From: [email-masked]
Date: Wed, 10 Oct 2001 13:28:35 -0500

Mike Heard writes

>This was intended as a short-term fix for the lack of a real Gauge64 or
>Unsigned64 in SMIv2.  Frankly I am not pleased with this "solution" but
>it's what the community decided to do.  Based on this precedent, it would
>probably be acceptable to define a set of 64-bit TCs analogous to those
>in RFC 2493.  Note well that these would have to be new TCs, not
>refinements of the ones in RFC 2856, because a TC can't refine a TC.

To summarize, you suggest to combine some of the text in RFC2856 with some
of the text of RFC2493 into three new TCs within a new draft called 
HC-PerfHist-TC-MIB as follows:

HSPerfCurrentCount ::= TEXTUAL-CONVENTION
           STATUS        current
           DESCRIPTION   "appropriate rfc2856 verbiage + rfc2493 verbiage"
           SYNTAX        Counter64
HSPerfIntervalCount ::= TEXTUAL-CONVENTION
           STATUS        current
           DESCRIPTION   "appropriate rfc2856 verbiage + rfc2493 verbiage"
           SYNTAX        Counter64

HSPerfTotalCount ::= TEXTUAL-CONVENTION
           STATUS        current
           DESCRIPTION   "appropriate rfc2856 verbiage + rfc2493 verbiage"
           SYNTAX        Counter64

>Actually, leaving holes for intervals for which no data is available
>is exactly what implementations the current trunk MIBs are expected
>to do.  As explained above, xyzInvalidIntervals is badly named.  All
>it really does is to count the holes.

So cool. 

Would I be preempting any other works in progress by submitting an
individual draft, hopefully to be picked up by adslmib or atommib in SLC,
containing just this?

Anyone?

Bob Ray
Verilink Corporation

"Experience is not what happens to a man; it is what a man does 
with what happens to him."  Aldous Huxley.

---

From: Kaj Tesink <[email-masked]>
Date: Wed, 10 Oct 2001 16:50:13 -0400

>individual draft, hopefully to be picked up by adslmib or atommib in SLC,

what about simply extending the existing 2493?

i dont see any other additions on the horizon so as you say it could be quick

kaj

>with what happens to him."  Aldous Huxley.

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Kaj Tesink
Telcordia Technologies
Email  [email-masked]
Tel    732.758.5254
Fax    732.758.2269
Postal 331 Newman Springs Rd
        Red Bank, NJ 07701
        USA

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 10 Oct 2001 17:25:34 -0700 (PDT)

> i dont see any other additions on the horizon so as you say it could be quick

I think we'd be better served to put this in a module by itself,
and in a separate RFC.  Otherwise we will probably have to recycle
RFC 2493 at proposed.  That in turn would cause the MIBs that
depend on it -- i.e., all the trunk MIBs -- to recycle as well.

Is there any downside whatever to making this a separate document?

As for Bob's original question, an individual submission I-D
would be a good way to get the ball rolling.

Mike

---

From: Kaj Tesink <[email-masked]>
Date: Thu, 11 Oct 2001 11:55:06 -0400

>depend on it -- i.e., all the trunk MIBs -- to recycle as well.

very good point

>Is there any downside whatever to making this a separate document?

my only reason was that it is a lot tidier to keep things together.
but your point oon the impact on the other rfcs clearly outweighs
that.

>would be a good way to get the ball rolling.

lets go

kaj

Kaj Tesink
Telcordia Technologies