Subject: Re: PerfHist-TC-MIB

From: Ken Chapman <[email-masked]>
Date: Thu, 28 May 1998 13:19:08 -0400

I agree.  I was not thinking of the PROCESS when I raised the issue.
It just seemed to make sence to put all the TCs together in one MIB.  
I'll draft a Supplemental-PerfHist-TC-MIB to go along with the 
DS1, DS3 and SONET Supplemental MIBs.

Now that I've got your attention, I have an important question of scope.
I think that each supplemental MIB should just address a specific 
standard, in this case ANSI T1.231.  Does anyone think otherwise?
Actually I want to submit another new MIB for SONET APS, but I don't think
it should be bundled in.  Likewise, I looked at the draft of the
DS3 sup MIB and think that the PLCP stuff belongs somewhere else.
	Ken

At 09:11 AM 5/28/98 -0400, Kaj Tesink wrote:
>At 05:36 PM 5/27/98 -0400, David Fowler wrote:
>>> Why not put PerfDayCount
>>> (and any other TCs needed to support the supplemental trunk MIBs) in a
>>> Supplemental-PerfHist-TC-MIB?
>>
>>Exactly.  The trunk MIBs have taken forever to get out.  Let's get them
done and
>>then add new things.
>
>I agree with this. And one more point:
>
>It would be questionable to define TCs that are not actually used in
>any MIB module (to date). We can only stick in TCs in the current 
>TC module that are used elsewhere or where we are very sure
>that 
>a) they will be used elsewhere within the foreseeable future
>b) they are correct
>
>Ken asked recently whether there is interest in a Supplemental
>SONET/SDH MIB that would be a potential user of such TCs.
>Is there any interest? Ken has some good stuff that can be leveraged.
>
>And what about the Supplemental DS0/1/2/3 MIBs?
>
>Kaj
>
>
>
>
>_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
>_/                                                                      _/
>_/  Kaj Tesink                                                          _/
>_/  Bellcore                                                            _/
>_/  Business Internet Professional Services  vmail (732) 758-5254       _/
>_/  331 Newman Springs Rd.                   email [email-masked]  _/
>_/  Red Bank, NJ 07701                     faxmail (732) 758-2269       _/
>_/                                                                      _/
>_/  * NOTE AREA CODE CHANGE (908) --> (732) EFFECTIVE JUNE 1, 1997 *    _/
>_/                                                                      _/
>_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
>
>
>

---

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Thu, 28 May 1998 11:30:16 -0700 (PDT)

On Thu, 28 May 1998, Ken Chapman wrote:
[ ... ]
> standard, in this case ANSI T1.231.  Does anyone think otherwise?

That sounds quite reasonable, and is in line with the goals set forth
for the supplemental trunk MIBs when they was proposed some time ago.
I do, however, think that any new work should be based on T1.231-1997
and not on T1.231-1993.

> it should be bundled in.

If the purpose in generating the supplemental trunk MIBs is to provide an
SNMP implementation of all of the mandatory or conditionally mandatory
performance parameters in T1.231 then the SONET supplemental MIB should
include the protection switching count (PSC) line layer parameter, and
the conformance statements should note that it is required if line-switched
protection is implemented (section 9.1.1).  Other protection switching
stuff probably should be relegated to a different MIB.

> Likewise, I looked at the draft of the

Agreed, since it is ATM- and SMDS-specific.

> 	Ken

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

---

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Thu, 28 May 1998 11:30:16 -0700 (PDT)

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

---

From: Kaj Tesink <[email-masked]>
Date: Thu, 28 May 1998 17:07:30 -0400

>On Thu, 28 May 1998, Ken Chapman wrote:
[..]
>Agreed, since it is ATM- and SMDS-specific.

I dont recall what PLCP stuff this was but rfc1694 and 1695
already have PLCP stuff... or are there even more beans that need
to be counted? :-|

kaj

---

From: Kaj Tesink <[email-masked]>
Date: Thu, 28 May 1998 17:07:30 -0400

[..]

kaj