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

From: Murwin William-LWM008 <[email-masked]>
Date: Wed, 20 Aug 2003 14:15:12 -0400

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, 

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: Murwin William-LWM008 <[email-masked]>
Date: Wed, 20 Aug 2003 15:08:59 -0400

Sorry I meant to say, "A Docsis 1.0 device does *NOT* have an entry in the QOS MIB, as QOS is a feature of DOCSIS 1.1/2.0"

-Will

-----Original Message-----
From: Murwin William-LWM008 
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]; [email-masked];
[email-masked]; [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

-----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

---

From: Murwin William-LWM008 <[email-masked]>
Date: Wed, 20 Aug 2003 14:15:12 -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

---

From: "Raftus, David" <[email-masked]>
Date: Thu, 21 Aug 2003 05:09:23 -0700

Hi Eduardo and all,

Regarding the status of the proposed rf mib updates, there have been two
additions since the original list was circulated:

18) Add new object docsIfCmtsCmStatusValueLastUpdate as per oss-n-03068.
19) Update references to latest rf/oss specs, also to new versions of snmpv3
RFCs

Current development status of draft v7 (note v6 expires end of September):
1) complete
2) complete
3) open
4) complete
5) complete
6) open
7) open - after consideration, not sure this is a good idea - may not
implement
8) complete
9) open 
10) complete
11) complete
12) complete
13) open
14) open - a large task - not sure will be done for v7.
15) open
16) open
17) open
18) complete
19) open

Dave

************************************
David Raftus
Software Manager
Terayon Communications Canada
340 Terry Fox Drive, Suite 202
Ottawa Canada  K2K 3A2

[email-masked]           
613.592.1052  ext 222

-----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]; [email-masked];
[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

NOTICE: This communication contains information which may be proprietary,
privileged or confidential.  If you are not the intended recipient (or
authorized to receive for the intended recipient), or believe that you have
received this communication in error, please do not print, copy, retransmit,
disseminate, disclose or otherwise use the information.  Also, please
indicate to the sender that you have received this communication in error
and delete the copy you received.  Thank you.

---

From: "Raftus, David" <[email-masked]>
Date: Fri, 22 Aug 2003 09:49:46 -0700

Hi,
 
I regret to say that new additions to draft v7 of the RF mib need to be
restricted to the list already posted to the community, which was debated at
length between March and June of this year. Any new proposals such as the
one below will need to be debated and accepted by the community, and will
presumably be intended for draft v8 of the mib. In keeping with the 6 month
expiry period for drafts, v8 can be expected before Mar 31/04.
 
This statement does not cast aspersions on the merits of new suggestions -
it is simply necessary to establish a line so a deadline goal can be met.
 
Thanks,
Dave

[email-masked]           
613.592.1052  ext 222

-----Original Message-----
From: Dan Rice [mailto:[email-masked]]
Sent: Friday, August 22, 2003 11:11 AM
To: Raftus, David; Minnie Lu
Cc: Eduardo Cardona; [email-masked]; Docsis 20 Reflector (E-mail);
Ipcdn List (E-mail)
Subject: RE: rf mib draft v6 to draft v7 suggestions Then DOCS-QOS-MIB sug
gestions
 
I am not sure if there's time to open any additional items, but one useful
item would be an object in docsIfUpstreamChannelTable named
docsIfUpChannelRxPowerset  that would be read-create and report what receive
power level at the CMTS has been set for this channel.  This would save MSO
NMSs from having to average the RX power across all of the CMs to find the
set point that they then use to see who is not reaching the CMTS at the
right power.  
 
Thanks
Dan
 
-----Original Message-----
From: Raftus, David [mailto:[email-masked]] 
Sent: Friday, August 22, 2003 8:50 AM
To: 'Minnie Lu'
Cc: 'Eduardo Cardona'; [email-masked]; Docsis 20 Reflector
(E-mail); Ipcdn List (E-mail)
Subject: RE: rf mib draft v6 to draft v7 suggestions Then DOCS-QOS-MIB sug
gestions
 
Hi Minnie, 
I think the DESCRIPTION field of the docsIfCmtsChannelUtilizationInterval
would be the appropriate place for such a clarification. I'm afraid I don't
quite understand your second suggested sentence - "Users should consider the
steady conditions like 2nd or 3rd window." 
Your first sentence is probably sufficient clarification - would you agree? 
Thanks, 
Dave 
************************************ 
David Raftus 
Software Manager 
Terayon Communications Canada 
340 Terry Fox Drive, Suite 202 
Ottawa Canada  K2K 3A2 
[email-masked]           
613.592.1052  ext 222 
************************************               
 
-----Original Message----- 
From: Minnie Lu [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Thursday, August 21, 2003 8:06 PM 
To: Raftus, David 
Cc: 'Eduardo Cardona'; [email-masked] 
Subject: RE: rf mib draft v6 to draft v7 suggestions Then DOCS-QOS-MIB sug
gestions 
Hi, David, 
   I know it takes already  lots of efforts to update the MIB for such long 
list.  Possible to take more ? I would to request to clarify things in this 
revision if possible.  Thanks a lot in advance ! 
   1. I have sent out several questions regarding the 
docsIfCmtsChannelUtilizationInterval (attached for your reference).  If we 
could have more clarification in the next revision of rfmib, that will be 
great helpful for devtest and vendor to implement this object.  My 
suggestion would be in the document Section 3.1.3 docsIfCmtsObjects, 
docsIfCmtsChannelUtilizationTable, or the comments before 
docsIfCmtsChannelUtilizationInterval object in the MIB file, add one more 
sentence similar to below. 
    " It is vendor specific implementation whether to restart the timer 
when docsIfCmtsChannelUtilizationInterval is changed during utilization 
reporting is in progress. Users should consider the steady conditions like 
2nd or 3rd 
window." 
     If I miss any thing, please correct me. 
    Thanks a lot for your help ! 
    Minnie 
At 05:09 AM 8/21/2003 -0700, Raftus, David wrote: 
>19) Update references to latest rf/oss specs, also to new versions of 
>snmpv3 RFCs 
> 
>From: Eduardo Cardona 
>[< mailto:[email-masked] <mailto:[email-masked]> >
mailto:[email-masked] <mailto:[email-masked]> ] 
(E-mail) 
>From: Raftus, David 
>[< mailto:[email-masked] <mailto:[email-masked]> >
mailto:[email-masked] <mailto:[email-masked]> ] 
>authorized to receive for the intended recipient), or believe that you 
>have received this communication in error, please do not print, copy, 
>retransmit, disseminate, disclose or otherwise use the information.  Also, 
>please indicate to the sender that you have received this communication in 
>error and delete the copy you received.  Thank you.

---

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

I am not sure if there's time to open any additional items, but one
useful item would be an object in docsIfUpstreamChannelTable named
docsIfUpChannelRxPowerset  that would be read-create and report what
receive power level at the CMTS has been set for this channel.  This
would save MSO NMSs from having to average the RX power across all of
the CMs to find the set point that they then use to see who is not
reaching the CMTS at the right power.  
 
Thanks
Dan
 
-----Original Message-----
From: Raftus, David [mailto:[email-masked]] 
Sent: Friday, August 22, 2003 8:50 AM
To: 'Minnie Lu'
Cc: 'Eduardo Cardona'; [email-masked]; Docsis 20 Reflector
sug gestions
 
Hi Minnie, 
I think the DESCRIPTION field of the
docsIfCmtsChannelUtilizationInterval would be the appropriate place for
such a clarification. I'm afraid I don't quite understand your second
suggested sentence - "Users should consider the steady conditions like
2nd or 3rd window." 
Your first sentence is probably sufficient clarification - would you
agree? 
Thanks, 
Dave 
************************************ 
David Raftus 
Software Manager 
Terayon Communications Canada 
340 Terry Fox Drive, Suite 202 
Ottawa Canada  K2K 3A2 
[email-masked]           
613.592.1052  ext 222 
************************************               
 
-----Original Message----- 
From: Minnie Lu [mailto:[email-masked]] 
Sent: Thursday, August 21, 2003 8:06 PM 
To: Raftus, David 
Cc: 'Eduardo Cardona'; [email-masked] 
Subject: RE: rf mib draft v6 to draft v7 suggestions Then DOCS-QOS-MIB
sug gestions 
Hi, David, 
   I know it takes already  lots of efforts to update the MIB for such
long 
list.  Possible to take more ? I would to request to clarify things in
this 
revision if possible.  Thanks a lot in advance ! 
   1. I have sent out several questions regarding the 
docsIfCmtsChannelUtilizationInterval (attached for your reference).  If
we 
could have more clarification in the next revision of rfmib, that will
be 
great helpful for devtest and vendor to implement this object.  My 
suggestion would be in the document Section 3.1.3 docsIfCmtsObjects, 
docsIfCmtsChannelUtilizationTable, or the comments before 
docsIfCmtsChannelUtilizationInterval object in the MIB file, add one
more 
sentence similar to below. 
    " It is vendor specific implementation whether to restart the timer 
when docsIfCmtsChannelUtilizationInterval is changed during utilization 
reporting is in progress. Users should consider the steady conditions
like 
2nd or 3rd 
window." 
     If I miss any thing, please correct me. 
    Thanks a lot for your help ! 
    Minnie 
At 05:09 AM 8/21/2003 -0700, Raftus, David wrote: 
>[<mailto:[email-masked]>mailto:[email-masked]] 
[email-masked]; 
(E-mail) 

>[<mailto:[email-masked]>mailto:[email-masked]] 

>Contributors - Victor Hou Juniper, Rich Woundy IPCDN/Comcast, Kirk 
NOTICE: This communication contains information which may be
proprietary, privileged or confidential.  If you are not the intended
recipient (or authorized to receive for the intended recipient), or
believe that you have received this communication in error, please do
not print, copy, retransmit, disseminate, disclose or otherwise use the
information.  Also, please indicate to the sender that you have received
this communication in error and delete the copy you received.  Thank
you.