Subject: [ipcdn] RE: rf mib draft v6 to draft v7 suggestions Then DOCS-QOS-MIB suggestions

From: "Eduardo Cardona" <[email-masked]>
Date: Wed, 20 Aug 2003 11:57:35 -0600

Hi David, 

I would like to recap your outstanding open issues list and see the
status of several of them: 

like a short list to focus in the pending ones:
items 1.. 17 Status
1 CLOSED/OPEN? 
2
3......

From the list : CM  counters for 1.0 CM 1.0 Interoperability

items 14, 15 16

Although I like your proposal of counters per subscriber (16), for
multiple flows and Dynamic flows may not be clear how it works. or
duplicated and hard to correlate (see 3)

1) the table CmtsCmStatusTable le is getting really big, ( although a
GetBulk can be selective)
    - not all CMTSes Caches docsIfCmtsCmStatusIndex, Would be this
table/counters persistent? 
    - if desired persisntent CmtsCmStatusIndex When would it will stop
growing?  ( hopping CMs around CMTSes in same plant)  
2) AUGMENT extension can be an option , but same questions

3) as much as I think of that, QOS mib, the docsQos Log is to me a more
centralized placed
, but... 
   - not introduce conflicts with ParamSetTable, fully mapping Service
ID with  SFID US/DS for 

  * ) Implement Andrew Solution Item ( augmenting the
docsIfCmtsServiceTable OutOctets, OutPackets)
      No counters for 1.1/2.0 CMs, docsQos already have those on a
per-flow basis, 
      so later agregation is an operative task 

Consider : David's Question for DS counters from original email:
                     "NOTE: Not sure it is possible to get from a CMTS
agent from the Standard MIBs the number of 
                         of packets transmitted to a single docsis 1.0
cable modem."
Since some vendors already count CM DS packets I do not see any problem
with that 

  **) My proposal is for Log stats into the  docsQosServiceFlowLogTable
for 1.0 mode as soon as Service ID is deleted ( cm boots, etc.)

	Would be convenient ClassName have a FIX Tag for 1.0 CMs like
"CoS:xxx"  with a CoS:basic as default but vendors may assign different
names after colon if a CoS Management in the CMTS is present:
In such way
- MSOS can pool for real time statistics:
  docsQosServiceFlowStatsTable for 1.1 and 2.0 Cms and
docsIfCmtsServiceTable for 1.0
- For accululated flows: docsQosServiceFlowLogTable for 1.0/1.1/2.0

For 1.0 CM US traffic 
docsQosServiceFlowLogIndex
docsQosServiceFlowLogIfIndex
docsQosServiceFlowLogSFID     SID 
docsQosServiceFlowLogCmMac    
docsQosServiceFlowLogPkts
docsQosServiceFlowLogOctets
docsQosServiceFlowLogTimeDeleted  t1 Time creation
docsQosServiceFlowLogTimeCreated  t1 
docsQosServiceFlowLogTimeActive   
docsQosServiceFlowLogDirection    'upstream' 
docsQosServiceFlowLogPrimary      'true'
docsQosServiceFlowLogServiceClassName CoS:basic or
Cos:VendorXUSScheduler, etc 
docsQosServiceFlowLogPolicedDropPkts 0 | (optional) 
docsQosServiceFlowLogPolicedDelayPkts 0 | (optional)

For 1.0 CM DS traffic 
docsQosServiceFlowLogIndex
docsQosServiceFlowLogIfIndex
docsQosServiceFlowLogSFID     SID 
docsQosServiceFlowLogCmMac    
docsQosServiceFlowLogPkts
docsQosServiceFlowLogOctets
docsQosServiceFlowLogTimeDeleted  t1 Time creation
docsQosServiceFlowLogTimeCreated  t1 
docsQosServiceFlowLogTimeActive   
docsQosServiceFlowLogDirection    'dowstream' 
docsQosServiceFlowLogPrimary      'true'
docsQosServiceFlowLogServiceClassName CoS:basic or
Cos:VendorXDSScheduler, etc 
docsQosServiceFlowLogPolicedDropPkts 0 | (optional) 
docsQosServiceFlowLogPolicedDelayPkts 0 | (optional)

Note: 
docsQosServiceFlowLogSFID   May would conflict with SFID in the 1.1 QOS
assignemt but the real key ( aggregate field key for a device is MAC
address) 

For DOCS-QOS-MIB:

I think William is trying to add a better control for the
docsQosServiceFlowLogTable :
- Count total number of existing rows: ( I believe is for draft 09) to
optimize getbulks requests:
- first, last index ? 

Am I correct?
One more would be a 

docsQosServiceFlowLogControlRangeIni under ::= { docsQosMIBObjects 12 } 
docsQosServiceFlowLogControlRangeEnd
docsQosServiceFlowLogControlRangeClear
 after a bulk of n rows the polling system knows the last row index so
can intruct the docsQosServiceFlowLogControlRangeClear object to clear
automatically records Ini to End

Eduardo

 -----Original Message-----
From: Raftus, David [mailto:[email-masked]] 
Sent: Tuesday, June 17, 2003 9:37 AM
To: Rich Woundy (Work) (E-mail); [email-masked]'; [email-masked]';
[email-masked]'; [email-masked]'; Eduardo Cardona; Greg
White; [email-masked]'; [email-masked]'; [email-masked]';
[email-masked]'; [email-masked]';
[email-masked]'; [email-masked]'; [email-masked]';
[email-masked]'; [email-masked]'; [email-masked]'
Cc: DOCSIS 2.0 Majordomo List; DOCSIS OSS Majordomo List; Ipcdn List
(E-mail); Raftus, David
Subject: rf mib draft v6 to draft v7 suggestions

Hi everyone,
 
Since RF mib v2 draft 6 was released in March, I have received publicly
or privately 17 requests for updates/changes to appear in draft v7. The
people on the To: list have participated in either initiating or
commenting on the suggestions. 
 
Could I ask these people to please verify their suggestions as they are
listed below? This mib update from v6 to v7 is extensive - want to
ensure data is accurate before undertaking. The wider communities are
also welcome to comment.
 
Thanks for your time,
Dave

1) Return name to pre draft v6 DOCS-IF-MIB from draft v6
DOCS-IETF-RFI-MIB. 

Contributors - Rich Woundy IPCDN/Comcast, Minnie Lu Cisco, Steve
Malenfant Com21

2) docsIfCmtsChannelUtUtilization formula - remove line (100 * ((raw
bytes - stuffed bytes) / raw bytes))
since it assumes that MPEG payload consists only DOC MAC payload. As we 
know, MPEG could consist video payload and NULL packets. Suggest to
remove 
this line since the first 2 lines in the formula are good enough.

Contributor - Minnie Lu    Cisco

3) Add discontinuity descriptions to all counters related to an
interface.

Contributor - Minnie Lu    Cisco

4) docsIfCmtsInsertInterval - For the docsIfCmtsInsertInterval object,
there is no such thing as a 
"broadcast station maintenance" interval for new modems joining the
network.   Station should be 
changed to initial to make the text read - "The amount of time to elapse
between each broadcast 
initial maintenance grant.  Broadcast initial maintenance grants are
used to allow new cable modems 
to join the network.  Zero indicates that a vendor-specific algorithm is
used instead of a fixed time.  
Maximum amount of time permitted by the specification is 2 seconds."

Contributor - Margo Dolas Broadcom

5) docsIfCmtsModPreambleType - (Joel) In docsIfCmtsModulationTable, the
docsIfCmtsModPreambleType object has 
2 possible values qpsk0(1) and qpsk1(2). It seems like it's the only
object in this table without a 
meaningful default value when this parameter does not make sense. For
instance, for a TDMA modulation 
profile using QAM16, the actual preamble type is indeed not QPSK0 but
something else. Does it make sense 
to have a value of 0 in this case, like
docsIfCmtsModScdmaInterleaverStepSize for non-SCDMA profiles?

(Eduardo) for the benefit of clarifications wouldn't be good to have a
enumeration unknown(0) for this 
object when not a 2.0 burst ?
Also a note in the DESCRIPTION like "if docsIfCmtsModChannelType is
tdma(1) a value unknown(0) is used for this object" 
I would say unknown(0) rather than unknown(3) since it looks like the
possible current implementation may be reporting  
'0' , and defendable in IETF since RFC 3291 uses '0' for inetAddressType

Contributors - Joel Demarty Juniper, Eduardo Cardona Cablelabs

6) docsIfUpstreamChannelTable clone mechanism - improve descriptive
wording. The spec is vague about the minimum set of parameters 
that the 
CMTS must transfer during a clone operation to be DOCSIS 2.0 compliant.
Only those starting with docsIfUpChannelScdma or 
all parameters defining an SCDMA channel, like the channel width? Then
what about the frequency? 
Definitely, this clone mechanism is sophisticated enough that it would
deserve a more detailed specification 
(and testing) and, as a consequence, an ECR.

Contributor - Joel Demarty Juniper

7) docsIfUpChannelPreEqEnable - add DEFVAL clause.

Contributor - John Gillis ADC

8) docsIfCmtsUpChnlCtrUcastGrantedMslots - In Cisco CMTS, we use IUC14
(reserved) and SID (HEX): 1FFF (max. of 
unicast sid number) for quite some time.
Q: Should it be counted in docsIfCmtsUpChnlCtrUcastGrantedMslots ?
My personal think that this objects seems to mean the 
meaningful  UNICAST SID, so user could get a good idea about the how
many 
minislots really assigned to some meaningful CM.  So, the reserved IUCs 
should be excluded from this object though minislots for reserved IUCs
are 
still be counted into docsIfCmtsUpChnlCtrTotalMslots.
Minnie,
I agree, I think IUC14 grants to SID 1FFF (assuming the CMTS reserves
that SID to mean no CM) should not be counted in UcastGrantedMslots.
I also think (and maybe this case is more obvious) than grants to SID 0
should not be counted in UcastGrantedMslots.
This brings up a question that I've had for some time.  Why does the
Cisco CMTS use IUC14 and SID 1FFF????  The use of IUC14 is prohibited by
the spec, since it is labeled as "Reserved", and SID 0 is already
defined to mean "no CM".
-Greg

Contributors - Minnie Lu Cisco, Greg White Cablelabs

9) docsIfCmStatusTable - possibly add new objects for successful/failed
ucc transactions. 
Hi, Alex,
I do not think that this is good idea. What will you count into
docsQosDCCAcks? The relationships between DCC Req/Rsp/Ack is important
and
should not be lost because of UCC additions. I guess, the better place
for
this counters is RFI MIB docsIfCmStatusTable. It may be extended in
future
versions.
Regards.
Lucy
Hello all,
A question about counting successful and failed UCC transactions.
It seems like there is no counters dedicated for UCC failed or
succeeded operation as it is for DCC transactions.
The question is, since UCC is a subset of DCC operation for 1.1 modem,
should the modem count UCC transactions in DCC counters (docsQosDCCs,
docsQosDCCFails) ?
Thank you in advance.

Contributors - Lucy Pollak TI, Alex Betis Coresma

10) docsIfUpChannelPreEqEnable, docsIfCmStatusEqualizationData - clarify
descriptions.
Lucy,
Sorry for the delay in responding.  I don't have an objection to your
proposal, as long as the 
format of the object is clear.
To summarize, the object docsIfCmStatusEqualizationData will only
include the "value" from figure 8-23.  
In other words, the first byte reported in the MIB object will be the
main tap location.  A clarification 
should also be made to the description of docsIfUpChannelPreEqEnable to
indicate your interpretation (b). 
Regarding the question about reverse taps, figure 8-23 is a
simplification of figure 6-23 from the 1.1 RFI 
spec (which includes a format to encode reverse taps).  It seems to make
sense to me to use the format 
shown in that figure.  Perhaps this MIB object could be clarified to
reference both figures.
-Greg

Greg,
to summarize our objections:
1. MIB requires equalization data, then type/length is irrelevant.
2. There are 2 possible types 4 (Transmit Equalization Adjust) or 9
(Transmit Equalization Set), which is 
irrelevant after convolution.
3. To be consistent with DS equa data, some TLV should be added also
into it. What?
We propose to use only value from referenced figure without type/length
to avoid questions in the future. If not, 
(2) and (3) should be clarified. I guess, that it will be also very
helpful if clarification (b) will be entered into MIB. 
Best Regards.
Lucy

Contributors - Lucy Pollak TI, Greg White Cablelabs

11) docsIfSignalQualityEntry - clarify wording for back compatibility.
In draft -03 the description of  docsIfSignalQualityEntry was changed 
from : 
docsIfSignalQualityEntry OBJECT-TYPE 
           SYNTAX      DocsIfSignalQualityEntry 
           MAX-ACCESS  not-accessible 
           STATUS      current 
           DESCRIPTION 
               "At the CM, describes the PHY characteristics of a 
                downstream channel. At the CMTS, describes the PHY 
signal 
                quality of an upstream channel. 
                An entry in this table exists for each ifEntry with an 
                ifType of docsCableUpstream(129) for Cable Modem 
Termination 
                Systems and docsCableDownstream(128) for Cable Modems." 
           INDEX { ifIndex } 
           ::= { docsIfSignalQualityTable 1 } 
to : 
docsIfSignalQualityEntry OBJECT-TYPE 
        SYNTAX      DocsIfSignalQualityEntry 
        MAX-ACCESS  not-accessible 
        STATUS      current 
        DESCRIPTION 
            "At the CM, describes the PHY characteristics of a 
             downstream channel. At the CMTS, describes the PHY signal 
             quality of an upstream channel. 
             An entry in this table exists for each ifEntry with an 
             ifType of docsCableUpstreamChannel(205) for Cable Modem 
Termination 
             Systems and docsCableDownstream(128) for Cable Modems." 
        INDEX { ifIndex } 
        ::= { docsIfSignalQualityTable 1 } 
But now RFI mib also apply to 1.1 CMTSes with no concept of ifType 205 
but 129 

Contributor - Eduardo Cardona Cablelabs

12) docsIfCmtsCmStatusValue - add new defined value
registeredBPIInitializing(9),
deprecate former value operational(8).

Contributors - Eduardo Cardona Cablelabs, Lucy Pollak TI, Minnie Lu
Cisco, David White Arris,
Matt Schmitt Arris, Kirk Friedman Correlant, Fred Oko Stargus, Joe Godas
Kar-el, Steve Malenfant Com21

13) Adjust compliance statements for objects designated optional. Add
separate augmentation table for 
optional objects in docsIfCmtsUpChannelCounterTable.

Contributors - Will Murwin Motorola, Rich Woundy IPCDN/Comcast, Mike
StJohns Mindspring, Eduardo Cardona Cablelabs

14) Add section explaining counter interaction between Docsis
1.0/1.1/2.0.
The QOS MIB tried to handle
DOCSIS 1.1 changes to RFC2670. Now that rfc2670 is being obsoleted, the
rf-mib v2 and the DOCSIS OSS Specs is the place
that should clearly state how these counters and other tables interact
in DOCSIS 1.0, DOCSIS 1.1, and DOCSIS 2.0.
I would even hope to see a section in the rf-mib v2, "Interoperation
with the version of DOCSIS" like or to replace
what the DOCSIS QOS MIB has. This is the place to describe what table
are populated under the docsIfMib when the
the modems are registering.
This way this issue can be re-discussed and whatever conculsion is
reached, can be document in the description of those
objects.

Contributor - Will Murwin Motorola, Minnie Lu Cisco

15) Change docsIfCmtsServiceTable to count packets for both upstream and
downstream flows. 
One of the things that has long been an issue with the RF MIB is that
the docsIfCmtsServiceTable only counts 
InOctets and InPackets (i.e. upstream packets only). If the reason for
keeping this table is to support DOCSIS 
1.0 modems would it also make sense to add downstream packet counts to
this table, too? Many CMTS'es already 
count this information and store it in a proprietary MIB. It would be
nice to standardize this as a requirement 
so that NMS such as usage monitoring systems could (a) count on it
existing and (b) find it in a standard location.

Contributor - Andrew Sundelin Stargus

16) Add 4 objects to docsIfCmtsCmStatusTable
While writing DOCS-IETF-QOS-MIB version 9, I find myself still thinking
about Minnie suggestion of having  
docsIfCmtsServiceInPackets and docsIfCmtsServiceInOctets count for
DOCSIS 1.1 and 2.0. Even though the QOS 
MIB has pawned off this discussion, I have had some thoughts on the
subject.
(1) If these counters where used to count the DOCSIS 1.1 and 2.0, than
this would the best place in all 
of the mibs to
    get a quick summary of the upstream data received by a particular
modem, no matter the version.
(2) At the same time, The rest of the docsIfCmtsCmServiceTable might not
make sense for DOCSIS 1.1 or 2.0
However the more I looked around at the different counters that existed
in all of MIB required by DOCSIS, 
the more I kept looking for an overall counter on the CMTS to count data
packet received and transmitted 
for a particular CM. 
I would like to start a discussion on about adding 4 new object to the
docsIfCmtsCmStatusTable:
docsIfCmtsCmStatusInPackets 
docsIfCmtsCmStatusInOctets
docsIfCmtsCmStatusOutPackets
docsIfCmtsCmStatusOutoctets
While I understand that these counts can be gathered by via numerous
objects on both the CMTS and CM 
and then just appling simple math. However I want to query only one
agent and just get a quick summary 
without have to determine which version of DOCSIS the modem is, which
will determine which mibs I look etc.
and objects I query.

For example if I want query only one agent(i.e. the CMTS) and get the
number of transmitted and received 
data for each CM, then 
       (1) GET-NEXT the docsIfCmtsCmStatusRegMode to see what version of
DOCSIS this modem is operting 

       if 'docsis10(1)' then 
                     (2) WALK the entire docsIfCmtsServiceTable for
ifIndex and SID that
                       have docsIfCmtsServiceNewCmStatusIndex that
matches the index for step (1).
       
                     (3) Add the all the instances of
docsIfCmtsServiceInPacket for the
                       ifIndex and SIDs that match from step(2) to get
the total Received packets from a CM.

                     NOTE: Not sure it is possible to get from a CMTS
agent from the Standard MIBs the number of 
                         of packets transmitted to a single docsis 1.0
cable modem.

       else if 'docsis11(2)' or 'docsis20()' then
                     (2) WALK the docsQosCmtsMacToSrvFlowTable all for
the instances of that contain the
                       same mac address.
                     (3) Then GET the docQosServiceFlowPkts using the
ifIndex and
                      service flow id from step(2). Add this to the
total of received or transmitted for this CM.
                         To determine the direction of the flow use the
same index and query the docsQosServiceFlowDirection.
This seems very complicated for something so simple. This is just a
suggestion of simple way the RF MIB v2 can correct the 
mistakes of the past.  

Contributors - Will Murwin Motorola, Minnie Lu Cisco

17) docsIfCmtsCmStatusTimingOffset - possibly change decription of
existing object or
add new object to reconcile unit differences between 1.1/2.0. Still
under discussion.

Contributors - Victor Hou Juniper, Rich Woundy IPCDN/Comcast, Kirk
Friedman Correlant.

 
************************************
David Raftus
Terayon Canada Ltd
340 Terry Fox Drive, Suite 202
Ottawa Canada  K2K 3A2
 
[email-masked]           
613.592.1052  ext 222
************************************               

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "Eduardo Cardona" <[email-masked]>
Date: Wed, 20 Aug 2003 11:57:35 -0600

Hi David, 

items 14, 15 16

For 1.0 CM US traffic 

For 1.0 CM DS traffic 

Note: 

For DOCS-QOS-MIB:

Am I correct?
One more would be a 

Eduardo

 -----Original Message-----
From: Raftus, David [mailto:[email-masked]] 
Sent: Tuesday, June 17, 2003 9:37 AM
To: Rich Woundy (Work) (E-mail); [email-masked]'; [email-masked]';

Hi everyone,

 
Thanks for your time,
Dave

Greg,

       if 'docsis10(1)' then 

 

[email-masked]           
613.592.1052  ext 222

---

From: "Dan Rice" <[email-masked]>
Date: Fri, 22 Aug 2003 11:32:02 -0400

That's still only provision 1.0 in the last sentence

-----Original Message-----
From: Dan Rice 
Sent: Friday, August 22, 2003 11:27 AM
To: Murwin William-LWM008; Eduardo Cardona; Raftus, David; Rich Woundy
(Work) (E-mail); [email-masked]; [email-masked]; [email-masked];
[email-masked]; Greg White; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; Fred Oko;
[email-masked]; Andrew Sundelin; [email-masked]
Cc: DOCSIS 2.0 Majordomo List; DOCSIS OSS Majordomo List; Ipcdn List
(E-mail)
Subject: RE: rf mib draft v6 to draft v7 suggestions Then DOCS-QOS-MIB
suggestions

I am not sure that I like the statustable idea, would it include only
the primary service flow or maybe all provisioned but not dynamic?

The other two options add D1.0 to service table and to QOS table could
make sense.  Several CMTS vendors currently have enterprise service
table extensions and other CMTS vendors also proxy D1.0 modems into QOS
tables to accommodate abuse management NMS functionality.  For sure
standardizing on one of both of these makes sense.

Currently it gets a little messy in mixed D1.0/1.1 environments, you
have to first see if the CMTS supports D1.1, then you need to see if any
CMs are provisioned as 1.1 then you need to collect all of the service
table and the vendor extension and all of the QOS MIB tables and then on
a CM by CM basis choose which data set you use. (all CMs are in service
table with some octets).  Ideally a lot of overhead responding to SNMP
and a lot of joining and post processing could be saved on the CMTS by
having all per CM octet and packet usage data be proxied into a single
set of tables.  The QOS table could provide this functionality and its
being done today.  I understand its not quite right since there are not
really D1.0 Service flows, but it would make practical sense for both
the MSOs and CMTS vendors.

I guess my vote would be for both to accommodate CMTSs that still only
provision 1.1. - Dan

-----Original Message-----
From: Murwin William-LWM008 [mailto:[email-masked]] 
Sent: Wednesday, August 20, 2003 2:15 PM
To: 'Eduardo Cardona'; Raftus, David; Rich Woundy (Work) (E-mail);
[email-masked]; [email-masked]; [email-masked];
[email-masked]; Greg White; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; Fred Oko;
[email-masked]; Andrew Sundelin; [email-masked]
Cc: DOCSIS 2.0 Majordomo List; DOCSIS OSS Majordomo List; Ipcdn List
(E-mail)
Subject: RE: rf mib draft v6 to draft v7 suggestions Then DOCS-QOS-MIB
suggestions

I strongly discourage this idea. A Docsis 1.0 device does have an entry
in the QOS MIB, as QOS is a feature of DOCSIS 1.1/2.0. The
docsQosServiceFlowLogTable is a history of the
docsQosServiceFlowStatsTable, where as docsIfCmtsCmStatusTable is for
all devices no matter the version of DOCSIS the agent is implementing or
version of DOCSIS for CMs connected to the CMTS. 

Also there have been no comments to change the
docsQosServiceFlowLogTable for version 9. 

-----Original Message-----
From: Eduardo Cardona [mailto:[email-masked]]
Sent: Wednesday, August 20, 2003 1:58 PM
To: Raftus, David; Rich Woundy (Work) (E-mail); [email-masked];
[email-masked]; [email-masked]; [email-masked]; Greg White;
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]; Murwin
William-LWM008; [email-masked]; [email-masked]
Cc: DOCSIS 2.0 Majordomo List; DOCSIS OSS Majordomo List; Ipcdn List
(E-mail)
Subject: RE: rf mib draft v6 to draft v7 suggestions Then DOCS-QOS-MIB
suggestions

Hi David, 

items 14, 15 16

For 1.0 CM US traffic 

For 1.0 CM DS traffic 

Note: 

For DOCS-QOS-MIB:

Am I correct?
One more would be a 

Eduardo

 -----Original Message-----
From: Raftus, David [mailto:[email-masked]] 
Sent: Tuesday, June 17, 2003 9:37 AM
To: Rich Woundy (Work) (E-mail); [email-masked]'; [email-masked]';

Hi everyone,

 
Thanks for your time,
Dave

Greg,

       if 'docsis10(1)' then 

 

[email-masked]           
613.592.1052  ext 222

---

From: "Dan Rice" <[email-masked]>
Date: Fri, 22 Aug 2003 11:26:45 -0400

-----Original Message-----
From: Eduardo Cardona [mailto:[email-masked]]
Sent: Wednesday, August 20, 2003 1:58 PM
To: Raftus, David; Rich Woundy (Work) (E-mail); [email-masked];

Hi David, 

items 14, 15 16

For 1.0 CM US traffic 

For 1.0 CM DS traffic 

Note: 

For DOCS-QOS-MIB:

Am I correct?
One more would be a 

Eduardo

 -----Original Message-----
From: Raftus, David [mailto:[email-masked]] 
Sent: Tuesday, June 17, 2003 9:37 AM
To: Rich Woundy (Work) (E-mail); [email-masked]'; [email-masked]';

Hi everyone,

 
Thanks for your time,
Dave

Greg,

       if 'docsis10(1)' then 

 

[email-masked]           
613.592.1052  ext 222