[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

To: "Raftus, David" <david.raftus@Terayon.com>
Subject: [ipcdn] RE: rf mib draft v6 to draft v7 suggestions Then DOCS-QOS-MIBsug gestions
From: Minnie Lu <milu@cisco.com>
Date: Mon, 25 Aug 2003 10:57:26 -0700
Cc: "'Minnie Lu'" <milu@cisco.com>, "'Eduardo Cardona'" <e.cardona@CableLabs.com>, docsis-oss@CableLabs.com, "Docsis 20 Reflector (E-mail)" <docsis-20@CableLabs.com>, "Ipcdn List (E-mail)" <ipcdn@ietf.org>
In-reply-to: <E54A98375651D511816A00306E06B970C4A7EB@OTNOAMEXCH01>
List-help: <mailto:ipcdn-request@ietf.org?subject=help>
List-id: IP over Cable Data Network <ipcdn.ietf.org>
List-post: <mailto:ipcdn@ietf.org>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,<mailto:ipcdn-request@ietf.org?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,<mailto:ipcdn-request@ietf.org?subject=unsubscribe>
Sender: ipcdn-admin@ietf.org

Hi, David,

Yes. Thanks a lot for your help !
Minnie

At 05:49 AM 8/22/2003 -0700, Raftus, David wrote:

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

david.raftus@terayon.com
613.592.1052 ext 222
************************************

-----Original Message-----
From: Minnie Lu [<mailto:milu@cisco.com>mailto:milu@cisco.com]
Sent: Thursday, August 21, 2003 8:06 PM
To: Raftus, David
Cc: 'Eduardo Cardona'; docsis-oss@CableLabs.com
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:

>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
>
>david.raftus@terayon.com
>613.592.1052 ext 222
>************************************
>
>-----Original Message-----
>From: Eduardo Cardona
>[<<mailto:e.cardona@CableLabs.com>mailto:e.cardona@CableLabs.com>mailto:e .cardona@CableLabs.com]
>Sent: Wednesday, August 20, 2003 1:58 PM
>To: Raftus, David; Rich Woundy (Work) (E-mail); milu@cisco.com;
>stevem@com21.com; mdolas@broadcom.com; jdemarty@juniper.net; Greg White;
>john.gillis@adc.com; lucy.pollak@ti.com; alexb@coresma.com;
>david.white@arrisi.com; matt.schmitt@arrisi.com; kfriedman@correlant.com;
>fred@stargus.com; joe@kar-el.cvnet.com; W.Murwin@motorola.com;
>ASundelin@stargus.com; vhou@juniper.net
>
>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:david.raftus@Terayon.com>mailto:david.raftus@Terayon.com>mailto :david.raftus@Terayon.com]
>Sent: Tuesday, June 17, 2003 9:37 AM
>To: Rich Woundy (Work) (E-mail); 'milu@cisco.com'; 'stevem@com21.com';
>'mdolas@broadcom.com'; 'jdemarty@juniper.net'; Eduardo Cardona; Greg
>White; 'john.gillis@adc.com'; 'lucy.pollak@ti.com'; 'alexb@coresma.com';
>'david.white@arrisi.com'; 'matt.schmitt@arrisi.com';
>'kfriedman@correlant.com'; 'fred@stargus.com'; 'joe@kar-el.cvnet.com';
>'W.Murwin@motorola.com'; 'ASundelin@stargus.com'; 'vhou@juniper.net'
>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
>
>david.raftus@terayon.com
>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.
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.


_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn

References:
- [ipcdn] RE: rf mib draft v6 to draft v7 suggestions Then DOCS-QOS-MIB suggestions
  - From: Raftus, David

Prev by Date: [ipcdn] FW: draft-ietf-ops-mib-review-guidelines-02.txt is now available
Next by Date: [ipcdn] RE: WGLC: BPI+ MIB, draft-ietf-ipcdn-bpiplus-mib-11.txt
Previous by thread: [ipcdn] RE: rf mib draft v6 to draft v7 suggestions Then DOCS-QOS-MIB suggestions
Next by thread: [ipcdn] RE: rf mib draft v6 to draft v7 suggestions Then DOCS-QOS-MIB suggestions
Index(es):
- Date
- Thread