From mailnull@www1.ietf.org  Wed Jun  4 20:18:04 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19030
	for <ipcdn-archive@odin.ietf.org>; Wed, 4 Jun 2003 20:18:04 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h550Ha901158
	for ipcdn-archive@odin.ietf.org; Wed, 4 Jun 2003 20:17:36 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h550HUB01152;
	Wed, 4 Jun 2003 20:17:30 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h550GBB01092
	for <ipcdn@optimus.ietf.org>; Wed, 4 Jun 2003 20:16:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19017
	for <ipcdn@ietf.org>; Wed, 4 Jun 2003 20:16:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19NiOY-0001WZ-00
	for ipcdn@ietf.org; Wed, 04 Jun 2003 20:14:18 -0400
Received: from ftpbox.mot.com ([129.188.136.101])
	by ietf-mx with esmtp (Exim 4.12)
	id 19NiOX-0001WW-00
	for ipcdn@ietf.org; Wed, 04 Jun 2003 20:14:17 -0400
Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242])
	by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h550G8qj019097
	for <ipcdn@ietf.org>; Wed, 4 Jun 2003 17:16:08 -0700 (MST)
Received: from ma07exm01.dma.isg.mot.com (ma07exm01.dma.isg.mot.com [150.21.2.102])
	by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id h550G4sZ009707
	for <ipcdn@ietf.org>; Wed, 4 Jun 2003 19:16:05 -0500
Received: by ma07exm01.dma.isg.mot.com with Internet Mail Service (5.5.2656.59)
	id <HNFXFLFA>; Wed, 4 Jun 2003 20:16:04 -0400
Message-ID: <19CD0E423FC1D611893500508B6F0B9CF396E8@ma07exm01.dma.isg.mot.com>
From: Murwin William-LWM008 <W.Murwin@motorola.com>
To: "Docsis-Oss (E-mail) (E-mail)" <docsis-oss@cablelabs.com>,
        "IPCDN (E-mail) (E-mail)" <ipcdn@ietf.org>
Cc: Murwin William-LWM008 <W.Murwin@motorola.com>,
        Patrick Michael-LZZ007
	 <Michael.Patrick@motorola.com>
Date: Wed, 4 Jun 2003 20:16:03 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [ipcdn] Descriptions for docsQosSer
Sender: ipcdn-admin@ietf.org
Errors-To: ipcdn-admin@ietf.org
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=subscribe>

When draft-ietf-ipcdn-qos-mib-08.txt was submitted to the mailling list there had been a disscusion about the descriptions for the objects:
docsQosServiceFlowPkts
docsQosServiceFlowOctets
docsQosServiceFlowPolicedDropPkts
docsQosServiceFlowPolicedDelayPkts

Please review the current descriptions from draft-ietf-ipcdn-qos-mib-08.txt  :

docsQosServiceFlowPkts OBJECT-TYPE
    SYNTAX          Counter64
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION    "The number of Packet Data PDUs classified to this 
                    service flow and forwarded beyond a service flow
                    maximum rate policing function.
                    This object does not count MAC-specific
                    management messages.
                    CMs not classifying downstream packets may report 
                    this object's value as 0.
		
		    Particularly for UGS flows, packets sent on the
                    primary service flow in violation of the UGS grant 
                    size should be counted only on the primary service 
                    flow's counters.	    	
	            
		    Unclassified upstream user data packets (i.e. non 
		    MAC-management) forwarded to the default upstream
		    service flow should be incremented for this object.

		    This object does include packets counted by 
                    docsQosServiceFlowPolicedDelayPkts, but does not include
                    packets counted by docsQosServiceFlowPolicedDropPkts.

		    This counter's last discontinuity is the 
	            ifCounterDiscontinuityTime for same ifIndex that 
		    indexes this object."
    ::= { docsQosServiceFlowStatsEntry 1 }

docsQosServiceFlowOctets OBJECT-TYPE
    SYNTAX          Counter64
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION    "The number of octets from the byte after the MAC 
	            header HCS to the end of the CRC for all packets counted 
                    in the docsQosServiceFlowPkts object for this row. 
                    Note that this counts the octets after payload header
                    suppression has been applied. CMs not classifying to a
                    downstream service flow may report this object's 
                    value as 0 for that flow.

                    This counter's last discontinuity is the 
	            ifCounterDiscontinuityTime for same ifIndex that 
		    indexes this object."
    ::= { docsQosServiceFlowStatsEntry 2 }

docsQosServiceFlowPolicedDropPkts OBJECT-TYPE
    SYNTAX          Counter32
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION    "The number of Packet Data PDUs classified to this
                    service flow dropped due to:
	               (1) implementation-dependent excessive delay while
	                   enforcing the Maximum Sustained Traffic Rate; or
		       (2) UGS packets dropped due to exceeding the 
	                   Unsolicited Grant Size with a 
	                   Request/Transmission policy that requires such 
                           packets to be dropped.
		    Classified packets dropped due to other reasons must be
	            counted in ifOutDiscards for interface of this 
	            service flow.

		    This counter's last discontinuity is the 
	            ifCounterDiscontinuityTime for same ifIndex that 
		    indexes this object."
    ::= { docsQosServiceFlowStatsEntry 6 }

docsQosServiceFlowPolicedDelayPkts OBJECT-TYPE
    SYNTAX          Counter32
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION    "This object counts only packets delayed in order to 
		    maintain the Maximum Sustained Traffic Rate. This object 
	            will always report a value of 0 for UGS flows because the
		    Maximum Sustained Traffic Rate does not apply.

		    This counter's last discontinuity is the 
	            ifCounterDiscontinuityTime for same ifIndex that 
		    indexes this object."	
    ::= { docsQosServiceFlowStatsEntry 7 }


We do not want to have the same discussion about the description of these objects when we send our for comments version 9 of the DOCS-QOS-MIB.
If there are any more comments please send then as soon as possible.
Thank you again for reviewing this.

Sincerely,
Mike Patrick & Will Murwin


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



From mailnull@www1.ietf.org  Thu Jun  5 18:28:58 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20756
	for <ipcdn-archive@odin.ietf.org>; Thu, 5 Jun 2003 18:28:58 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h55MSY916382
	for ipcdn-archive@odin.ietf.org; Thu, 5 Jun 2003 18:28:34 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55MSIB16351;
	Thu, 5 Jun 2003 18:28:18 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55MRNB16291
	for <ipcdn@optimus.ietf.org>; Thu, 5 Jun 2003 18:27:23 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20709
	for <ipcdn@ietf.org>; Thu, 5 Jun 2003 18:27:17 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19O3Aj-0004Bg-00
	for ipcdn@ietf.org; Thu, 05 Jun 2003 18:25:25 -0400
Received: from [66.63.144.170] (helo=mail.correlant.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19O3Aj-0004BE-00
	for ipcdn@ietf.org; Thu, 05 Jun 2003 18:25:25 -0400
Received: from kfriedman (67.82.218.209.transedge.com [209.218.82.67])
	by mail.correlant.com (Postfix) with SMTP
	id 2D13ABC118; Thu,  5 Jun 2003 15:27:43 -0700 (PDT)
From: "Kirk Friedman" <kfriedman@correlant.com>
To: "'Murwin William-LWM008'" <W.Murwin@motorola.com>,
        "'Docsis-Oss (E-mail) (E-mail)'" <docsis-oss@cablelabs.com>,
        "'IPCDN (E-mail) (E-mail)'" <ipcdn@ietf.org>
Cc: "'Patrick Michael-LZZ007'" <Michael.Patrick@motorola.com>
Subject: RE: [ipcdn] Descriptions for docsQosSer
Date: Thu, 5 Jun 2003 15:26:40 -0700
Message-ID: <000801c32bb1$8a145560$4352dad1@correlant.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <19CD0E423FC1D611893500508B6F0B9CF396E8@ma07exm01.dma.isg.mot.com>
Content-Transfer-Encoding: 7bit
Sender: ipcdn-admin@ietf.org
Errors-To: ipcdn-admin@ietf.org
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Will and Mike,

Thanks for doing all this work.  The descriptions seem to be written from a
CM only perspective.  The compliance statement puts
DocsQosServiceFlowStatsTable into the base group for CMs and CMTS.  Section
2.4.2 seems to imply that these statistics are only kept for packets going
to/from the RF interface.  That might also need to be rewritten unless that
is what is intended.

If that is what is intended, then the individual parameters or compliances
should be indicate which directions for the CMTS the parameters apply to.
Perhaps the equivalent of "CMTS' MUST report this as 0 for upstream service
flows" for the PolicedDrop/Delay packet counters.  Otherwise I have some
questions:

1) From a CMTS perspective, why is docsQosServiceFlowPolicedDelayPkts
applied to upstream SFs at all?  This would be very difficult with
concatenation of multiple packets inside of one burst.

2) Regarding docsQosServiceFlowPolicedDropPkts.  Part of the description is
"Classified packets dropped due to other reasons must be counted in
ifOutDiscards for interface of this service flow."  But for the CMTS, the
OSS spec has ifOutDiscards as MUST be 0 for upstream interfaces.


Thanks,

Kirk Friedman
Correlant Communications
15110 Avenue Of Science
San Diego, CA., 92128


-----Original Message-----
From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of
Murwin William-LWM008
Sent: Wednesday, June 04, 2003 5:16 PM
To: Docsis-Oss (E-mail) (E-mail); IPCDN (E-mail) (E-mail)
Cc: Murwin William-LWM008; Patrick Michael-LZZ007
Subject: [ipcdn] Descriptions for docsQosSer


When draft-ietf-ipcdn-qos-mib-08.txt was submitted to the mailling list
there had been a disscusion about the descriptions for the objects:
docsQosServiceFlowPkts
docsQosServiceFlowOctets
docsQosServiceFlowPolicedDropPkts
docsQosServiceFlowPolicedDelayPkts

Please review the current descriptions from draft-ietf-ipcdn-qos-mib-08.txt
:

docsQosServiceFlowPkts OBJECT-TYPE
    SYNTAX          Counter64
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION    "The number of Packet Data PDUs classified to this
                    service flow and forwarded beyond a service flow
                    maximum rate policing function.
                    This object does not count MAC-specific
                    management messages.
                    CMs not classifying downstream packets may report
                    this object's value as 0.

		    Particularly for UGS flows, packets sent on the
                    primary service flow in violation of the UGS grant
                    size should be counted only on the primary service
                    flow's counters.

		    Unclassified upstream user data packets (i.e. non
		    MAC-management) forwarded to the default upstream
		    service flow should be incremented for this object.

		    This object does include packets counted by
                    docsQosServiceFlowPolicedDelayPkts, but does not include
                    packets counted by docsQosServiceFlowPolicedDropPkts.

		    This counter's last discontinuity is the
	            ifCounterDiscontinuityTime for same ifIndex that
		    indexes this object."
    ::= { docsQosServiceFlowStatsEntry 1 }

docsQosServiceFlowOctets OBJECT-TYPE
    SYNTAX          Counter64
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION    "The number of octets from the byte after the MAC
	            header HCS to the end of the CRC for all packets counted
                    in the docsQosServiceFlowPkts object for this row.
                    Note that this counts the octets after payload header
                    suppression has been applied. CMs not classifying to a
                    downstream service flow may report this object's
                    value as 0 for that flow.

                    This counter's last discontinuity is the
	            ifCounterDiscontinuityTime for same ifIndex that
		    indexes this object."
    ::= { docsQosServiceFlowStatsEntry 2 }

docsQosServiceFlowPolicedDropPkts OBJECT-TYPE
    SYNTAX          Counter32
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION    "The number of Packet Data PDUs classified to this
                    service flow dropped due to:
	               (1) implementation-dependent excessive delay while
	                   enforcing the Maximum Sustained Traffic Rate; or
		       (2) UGS packets dropped due to exceeding the
	                   Unsolicited Grant Size with a
	                   Request/Transmission policy that requires such
                           packets to be dropped.
		    Classified packets dropped due to other reasons must be
	            counted in ifOutDiscards for interface of this
	            service flow.

		    This counter's last discontinuity is the
	            ifCounterDiscontinuityTime for same ifIndex that
		    indexes this object."
    ::= { docsQosServiceFlowStatsEntry 6 }

docsQosServiceFlowPolicedDelayPkts OBJECT-TYPE
    SYNTAX          Counter32
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION    "This object counts only packets delayed in order to
		    maintain the Maximum Sustained Traffic Rate. This object
	            will always report a value of 0 for UGS flows because the
		    Maximum Sustained Traffic Rate does not apply.

		    This counter's last discontinuity is the
	            ifCounterDiscontinuityTime for same ifIndex that
		    indexes this object."
    ::= { docsQosServiceFlowStatsEntry 7 }


We do not want to have the same discussion about the description of these
objects when we send our for comments version 9 of the DOCS-QOS-MIB.
If there are any more comments please send then as soon as possible.
Thank you again for reviewing this.

Sincerely,
Mike Patrick & Will Murwin


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

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



From mailnull@www1.ietf.org  Fri Jun  6 09:25:15 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22519
	for <ipcdn-archive@odin.ietf.org>; Fri, 6 Jun 2003 09:25:15 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h56DOnu22905
	for ipcdn-archive@odin.ietf.org; Fri, 6 Jun 2003 09:24:49 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56DOmB22892;
	Fri, 6 Jun 2003 09:24:48 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5582dB10774
	for <ipcdn@optimus.ietf.org>; Thu, 5 Jun 2003 04:02:39 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10718
	for <ipcdn@ietf.org>; Thu, 5 Jun 2003 04:02:37 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Npfy-00044G-00
	for ipcdn@ietf.org; Thu, 05 Jun 2003 04:00:46 -0400
Received: from go4.ext.ti.com ([192.91.75.132])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Npfx-00043s-00
	for ipcdn@ietf.org; Thu, 05 Jun 2003 04:00:45 -0400
Received: from dlep51.itg.ti.com ([157.170.141.75])
	by go4.ext.ti.com (8.12.9/8.12.9) with ESMTP id h55824wD005383;
	Thu, 5 Jun 2003 03:02:04 -0500 (CDT)
Received: from dlep98.itg.ti.com (localhost [127.0.0.1])
	by dlep51.itg.ti.com (8.12.9/8.12.9) with ESMTP id h55823lp029931;
	Thu, 5 Jun 2003 03:02:03 -0500 (CDT)
Received: from dile70.itg.ti.com (dile70.itg.ti.com [137.167.177.22])
	by dlep98.itg.ti.com (8.9.3/8.9.3) with ESMTP id DAA16815;
	Thu, 5 Jun 2003 03:02:02 -0500 (CDT)
Received: by dile70.itg.ti.com with Internet Mail Service (5.5.2653.19)
	id <M2D1A881>; Thu, 5 Jun 2003 11:02:01 +0300
Message-ID: <7DF2A1B372BBD611912F00508BDFBA9A9C1A58@dile03.itg.ti.com>
From: "Pollak, Lucy" <Lucy.pollak@ti.com>
To: "'Murwin William-LWM008'" <W.Murwin@motorola.com>,
        "Docsis-Oss (E-mail) (E-mail)" <docsis-oss@cablelabs.com>,
        "IPCDN (E-mail) (E-mail)" <ipcdn@ietf.org>
Cc: Patrick Michael-LZZ007 <Michael.Patrick@motorola.com>
Date: Thu, 5 Jun 2003 11:01:58 +0300 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [ipcdn] RE: Descriptions for docsQosSer
Sender: ipcdn-admin@ietf.org
Errors-To: ipcdn-admin@ietf.org
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=subscribe>

Mike and Will.
I still have a number of unanswered questions. 
1. The "Note that this counts the octets after payload header suppression
has been applied." is asymmetric for sender and receiver. It may be
understood for receiver as "after payload header de-suppression..." if
consider "payload header suppression" as common name for
suppression/de-supression operation. May be it will be better: "Note that
the octets suppressed by payload header suppression are not counted into
this object."
2. Please, correct the text in MIB preamble:
	 "The docsQosServiceFlowPkts object 
   counts the total number of packets forwarded beyond the policing 
   function intended for eventual transmission onto the DOCSIS RF 
   network."
It does not match new MIB text for same object.
3. The docsQosServiceFlowPHSUnknowns is not still clarified in your
proposal. It is not defined what to do for DS if classification is not
executed. Is it also permitted to return 0? Is it recommended to count all
the packets into primary DS SF?

Thanks.
Lucy

-----Original Message-----
From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com]
Sent: Thursday, June 05, 2003 3:16 AM
To: Docsis-Oss (E-mail) (E-mail); IPCDN (E-mail) (E-mail)
Cc: Murwin William-LWM008; Patrick Michael-LZZ007
Subject: Descriptions for docsQosSer


When draft-ietf-ipcdn-qos-mib-08.txt was submitted to the mailling list
there had been a disscusion about the descriptions for the objects:
docsQosServiceFlowPkts
docsQosServiceFlowOctets
docsQosServiceFlowPolicedDropPkts
docsQosServiceFlowPolicedDelayPkts

Please review the current descriptions from draft-ietf-ipcdn-qos-mib-08.txt
:

docsQosServiceFlowPkts OBJECT-TYPE
    SYNTAX          Counter64
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION    "The number of Packet Data PDUs classified to this 
                    service flow and forwarded beyond a service flow
                    maximum rate policing function.
                    This object does not count MAC-specific
                    management messages.
                    CMs not classifying downstream packets may report 
                    this object's value as 0.
		
		    Particularly for UGS flows, packets sent on the
                    primary service flow in violation of the UGS grant 
                    size should be counted only on the primary service 
                    flow's counters.	    	
	            
		    Unclassified upstream user data packets (i.e. non 
		    MAC-management) forwarded to the default upstream
		    service flow should be incremented for this object.

		    This object does include packets counted by 
                    docsQosServiceFlowPolicedDelayPkts, but does not include
                    packets counted by docsQosServiceFlowPolicedDropPkts.

		    This counter's last discontinuity is the 
	            ifCounterDiscontinuityTime for same ifIndex that 
		    indexes this object."
    ::= { docsQosServiceFlowStatsEntry 1 }

docsQosServiceFlowOctets OBJECT-TYPE
    SYNTAX          Counter64
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION    "The number of octets from the byte after the MAC 
	            header HCS to the end of the CRC for all packets counted

                    in the docsQosServiceFlowPkts object for this row. 
                    Note that this counts the octets after payload header
                    suppression has been applied. CMs not classifying to a
                    downstream service flow may report this object's 
                    value as 0 for that flow.

                    This counter's last discontinuity is the 
	            ifCounterDiscontinuityTime for same ifIndex that 
		    indexes this object."
    ::= { docsQosServiceFlowStatsEntry 2 }

docsQosServiceFlowPolicedDropPkts OBJECT-TYPE
    SYNTAX          Counter32
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION    "The number of Packet Data PDUs classified to this
                    service flow dropped due to:
	               (1) implementation-dependent excessive delay while
	                   enforcing the Maximum Sustained Traffic Rate; or
		       (2) UGS packets dropped due to exceeding the 
	                   Unsolicited Grant Size with a 
	                   Request/Transmission policy that requires such 
                           packets to be dropped.
		    Classified packets dropped due to other reasons must be
	            counted in ifOutDiscards for interface of this 
	            service flow.

		    This counter's last discontinuity is the 
	            ifCounterDiscontinuityTime for same ifIndex that 
		    indexes this object."
    ::= { docsQosServiceFlowStatsEntry 6 }

docsQosServiceFlowPolicedDelayPkts OBJECT-TYPE
    SYNTAX          Counter32
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION    "This object counts only packets delayed in order to 
		    maintain the Maximum Sustained Traffic Rate. This object

	            will always report a value of 0 for UGS flows because
the
		    Maximum Sustained Traffic Rate does not apply.

		    This counter's last discontinuity is the 
	            ifCounterDiscontinuityTime for same ifIndex that 
		    indexes this object."	
    ::= { docsQosServiceFlowStatsEntry 7 }


We do not want to have the same discussion about the description of these
objects when we send our for comments version 9 of the DOCS-QOS-MIB.
If there are any more comments please send then as soon as possible.
Thank you again for reviewing this.

Sincerely,
Mike Patrick & Will Murwin

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



From mailnull@www1.ietf.org  Fri Jun  6 09:25:19 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22551
	for <ipcdn-archive@odin.ietf.org>; Fri, 6 Jun 2003 09:25:19 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h56DOr122928
	for ipcdn-archive@odin.ietf.org; Fri, 6 Jun 2003 09:24:53 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56DOpB22921;
	Fri, 6 Jun 2003 09:24:51 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55NAgB19866
	for <ipcdn@optimus.ietf.org>; Thu, 5 Jun 2003 19:10:42 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21838
	for <ipcdn@ietf.org>; Thu, 5 Jun 2003 19:10:35 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19O3qd-0004UU-00
	for ipcdn@ietf.org; Thu, 05 Jun 2003 19:08:43 -0400
Received: from sj-core-5.cisco.com ([171.71.177.238])
	by ietf-mx with esmtp (Exim 4.12)
	id 19O3qc-0004U4-00
	for ipcdn@ietf.org; Thu, 05 Jun 2003 19:08:42 -0400
Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h55NA0jc020923;
	Thu, 5 Jun 2003 16:10:00 -0700 (PDT)
Received: from milu-w2k.cisco.com (dhcp-171-71-51-93.cisco.com [171.71.51.93])
	by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR)
	with ESMTP id AIB19791;
	Thu, 5 Jun 2003 16:09:59 -0700 (PDT)
Message-Id: <4.3.2.7.2.20030605160123.04660b18@mira-sjc5-1.cisco.com>
X-Sender: milu@mira-sjc5-1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 05 Jun 2003 16:09:59 -0700
To: Murwin William-LWM008 <W.Murwin@motorola.com>
From: Minnie Lu <milu@cisco.com>
Cc: "Docsis-Oss (E-mail) (E-mail)" <docsis-oss@cablelabs.com>,
        "IPCDN (E-mail) (E-mail)" <ipcdn@ietf.org>,
        Murwin William-LWM008 <W.Murwin@motorola.com>,
        Patrick Michael-LZZ007 <Michael.Patrick@motorola.com>
In-Reply-To: <19CD0E423FC1D611893500508B6F0B9CF396E8@ma07exm01.dma.isg.m
 ot.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [ipcdn] Re: Descriptions for docsQosSer
Sender: ipcdn-admin@ietf.org
Errors-To: ipcdn-admin@ietf.org
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=subscribe>

Hi,

Probably I miss something.  I don't know why the word "classified" was 
added into these counters.  These counters might be used for usage billing 
purpose.  With the word "classified", CMTS will only MUST report downtream 
service flows traffic statistics because CMTS only MUST classify downtream 
traffic to active downstream service flows.  Any reason could these 
counters not be used for the traffic sent or received via the service flow ?

Thanks !
Minnie

At 08:16 PM 6/4/2003 -0400, Murwin William-LWM008 wrote:
>When draft-ietf-ipcdn-qos-mib-08.txt was submitted to the mailling list 
>there had been a disscusion about the descriptions for the objects:
>docsQosServiceFlowPkts
>docsQosServiceFlowOctets
>docsQosServiceFlowPolicedDropPkts
>docsQosServiceFlowPolicedDelayPkts
>
>Please review the current descriptions from draft-ietf-ipcdn-qos-mib-08.txt  :
>
>docsQosServiceFlowPkts OBJECT-TYPE
>     SYNTAX          Counter64
>     MAX-ACCESS      read-only
>     STATUS          current
>     DESCRIPTION    "The number of Packet Data PDUs classified to this
>                     service flow and forwarded beyond a service flow
>                     maximum rate policing function.
>                     This object does not count MAC-specific
>                     management messages.
>                     CMs not classifying downstream packets may report
>                     this object's value as 0.
>
>                     Particularly for UGS flows, packets sent on the
>                     primary service flow in violation of the UGS grant
>                     size should be counted only on the primary service
>                     flow's counters.
>
>                     Unclassified upstream user data packets (i.e. non
>                     MAC-management) forwarded to the default upstream
>                     service flow should be incremented for this object.
>
>                     This object does include packets counted by
>                     docsQosServiceFlowPolicedDelayPkts, but does not include
>                     packets counted by docsQosServiceFlowPolicedDropPkts.
>
>                     This counter's last discontinuity is the
>                     ifCounterDiscontinuityTime for same ifIndex that
>                     indexes this object."
>     ::= { docsQosServiceFlowStatsEntry 1 }
>
>docsQosServiceFlowOctets OBJECT-TYPE
>     SYNTAX          Counter64
>     MAX-ACCESS      read-only
>     STATUS          current
>     DESCRIPTION    "The number of octets from the byte after the MAC
>                     header HCS to the end of the CRC for all packets counted
>                     in the docsQosServiceFlowPkts object for this row.
>                     Note that this counts the octets after payload header
>                     suppression has been applied. CMs not classifying to a
>                     downstream service flow may report this object's
>                     value as 0 for that flow.
>
>                     This counter's last discontinuity is the
>                     ifCounterDiscontinuityTime for same ifIndex that
>                     indexes this object."
>     ::= { docsQosServiceFlowStatsEntry 2 }
>
>docsQosServiceFlowPolicedDropPkts OBJECT-TYPE
>     SYNTAX          Counter32
>     MAX-ACCESS      read-only
>     STATUS          current
>     DESCRIPTION    "The number of Packet Data PDUs classified to this
>                     service flow dropped due to:
>                        (1) implementation-dependent excessive delay while
>                            enforcing the Maximum Sustained Traffic Rate; or
>                        (2) UGS packets dropped due to exceeding the
>                            Unsolicited Grant Size with a
>                            Request/Transmission policy that requires such
>                            packets to be dropped.
>                     Classified packets dropped due to other reasons must be
>                     counted in ifOutDiscards for interface of this
>                     service flow.
>
>                     This counter's last discontinuity is the
>                     ifCounterDiscontinuityTime for same ifIndex that
>                     indexes this object."
>     ::= { docsQosServiceFlowStatsEntry 6 }
>
>docsQosServiceFlowPolicedDelayPkts OBJECT-TYPE
>     SYNTAX          Counter32
>     MAX-ACCESS      read-only
>     STATUS          current
>     DESCRIPTION    "This object counts only packets delayed in order to
>                     maintain the Maximum Sustained Traffic Rate. This object
>                     will always report a value of 0 for UGS flows because the
>                     Maximum Sustained Traffic Rate does not apply.
>
>                     This counter's last discontinuity is the
>                     ifCounterDiscontinuityTime for same ifIndex that
>                     indexes this object."
>     ::= { docsQosServiceFlowStatsEntry 7 }
>
>
>We do not want to have the same discussion about the description of these 
>objects when we send our for comments version 9 of the DOCS-QOS-MIB.
>If there are any more comments please send then as soon as possible.
>Thank you again for reviewing this.
>
>Sincerely,
>Mike Patrick & Will Murwin

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



From mailnull@www1.ietf.org  Fri Jun  6 10:46:59 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26651
	for <ipcdn-archive@odin.ietf.org>; Fri, 6 Jun 2003 10:46:59 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h56EkZ929743
	for ipcdn-archive@odin.ietf.org; Fri, 6 Jun 2003 10:46:35 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56EkWB29736;
	Fri, 6 Jun 2003 10:46:32 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56EjxB29684
	for <ipcdn@optimus.ietf.org>; Fri, 6 Jun 2003 10:45:59 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26609
	for <ipcdn@ietf.org>; Fri, 6 Jun 2003 10:45:52 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19OIRj-0002fo-00
	for ipcdn@ietf.org; Fri, 06 Jun 2003 10:43:59 -0400
Received: from motgate2.mot.com ([136.182.1.10])
	by ietf-mx with esmtp (Exim 4.12)
	id 19OIRi-0002fl-00
	for ipcdn@ietf.org; Fri, 06 Jun 2003 10:43:59 -0400
Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131])
	by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h56Ejpu5009085
	for <ipcdn@ietf.org>; Fri, 6 Jun 2003 07:45:52 -0700 (MST)
Received: from ma07exm01.dma.isg.mot.com (ma07exm01.dma.isg.mot.com [150.21.2.102])
	by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h56Ejp8B008795
	for <ipcdn@ietf.org>; Fri, 6 Jun 2003 09:45:51 -0500
Received: by ma07exm01.dma.isg.mot.com with Internet Mail Service (5.5.2656.59)
	id <HNFXF35Z>; Fri, 6 Jun 2003 10:45:51 -0400
Message-ID: <19CD0E423FC1D611893500508B6F0B9CAB736A@ma07exm01.dma.isg.mot.com>
From: Patrick Michael-LZZ007 <Michael.Patrick@motorola.com>
To: "'Pollak, Lucy'" <Lucy.pollak@ti.com>,
        Murwin William-LWM008
	 <W.Murwin@motorola.com>,
        "Docsis-Oss (E-mail) (E-mail)"
	 <docsis-oss@cablelabs.com>,
        "IPCDN (E-mail) (E-mail)" <ipcdn@ietf.org>
Subject: RE: [ipcdn] RE: Descriptions for docsQosSer
Date: Fri, 6 Jun 2003 10:45:49 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: ipcdn-admin@ietf.org
Errors-To: ipcdn-admin@ietf.org
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=subscribe>

Lucy,

I thought the wording "after payload header supression has been applied" would be reasonably understood by all readers as not including the bytes that were removed by suppression, for both sender and receiver.
Has there been any instances of a reader (i.e. implementor or tester) that did not get that impression?

-mike


-----Original Message-----
From: Pollak, Lucy [mailto:Lucy.pollak@ti.com] 
Sent: Thursday, June 05, 2003 4:02 AM
To: Murwin William-LWM008; Docsis-Oss (E-mail) (E-mail); IPCDN (E-mail) (E-mail)
Cc: Patrick Michael-LZZ007
Subject: [ipcdn] RE: Descriptions for docsQosSer


Mike and Will.
I still have a number of unanswered questions. 
1. The "Note that this counts the octets after payload header suppression has been applied." is asymmetric for sender and receiver. It may be understood for receiver as "after payload header de-suppression..." if consider "payload header suppression" as common name for suppression/de-supression operation. May be it will be better: "Note that the octets suppressed by payload header suppression are not counted into this object." 2. Please, correct the text in MIB preamble:
	 "The docsQosServiceFlowPkts object 
   counts the total number of packets forwarded beyond the policing 
   function intended for eventual transmission onto the DOCSIS RF 
   network."
It does not match new MIB text for same object.
3. The docsQosServiceFlowPHSUnknowns is not still clarified in your proposal. It is not defined what to do for DS if classification is not executed. Is it also permitted to return 0? Is it recommended to count all the packets into primary DS SF?

Thanks.
Lucy

-----Original Message-----
From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com]
Sent: Thursday, June 05, 2003 3:16 AM
To: Docsis-Oss (E-mail) (E-mail); IPCDN (E-mail) (E-mail)
Cc: Murwin William-LWM008; Patrick Michael-LZZ007
Subject: Descriptions for docsQosSer


When draft-ietf-ipcdn-qos-mib-08.txt was submitted to the mailling list there had been a disscusion about the descriptions for the objects: docsQosServiceFlowPkts docsQosServiceFlowOctets docsQosServiceFlowPolicedDropPkts docsQosServiceFlowPolicedDelayPkts

Please review the current descriptions from draft-ietf-ipcdn-qos-mib-08.txt
:

docsQosServiceFlowPkts OBJECT-TYPE
    SYNTAX          Counter64
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION    "The number of Packet Data PDUs classified to this 
                    service flow and forwarded beyond a service flow
                    maximum rate policing function.
                    This object does not count MAC-specific
                    management messages.
                    CMs not classifying downstream packets may report 
                    this object's value as 0.
		
		    Particularly for UGS flows, packets sent on the
                    primary service flow in violation of the UGS grant 
                    size should be counted only on the primary service 
                    flow's counters.	    	
	            
		    Unclassified upstream user data packets (i.e. non 
		    MAC-management) forwarded to the default upstream
		    service flow should be incremented for this object.

		    This object does include packets counted by 
                    docsQosServiceFlowPolicedDelayPkts, but does not include
                    packets counted by docsQosServiceFlowPolicedDropPkts.

		    This counter's last discontinuity is the 
	            ifCounterDiscontinuityTime for same ifIndex that 
		    indexes this object."
    ::= { docsQosServiceFlowStatsEntry 1 }

docsQosServiceFlowOctets OBJECT-TYPE
    SYNTAX          Counter64
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION    "The number of octets from the byte after the MAC 
	            header HCS to the end of the CRC for all packets counted

                    in the docsQosServiceFlowPkts object for this row. 
                    Note that this counts the octets after payload header
                    suppression has been applied. CMs not classifying to a
                    downstream service flow may report this object's 
                    value as 0 for that flow.

                    This counter's last discontinuity is the 
	            ifCounterDiscontinuityTime for same ifIndex that 
		    indexes this object."
    ::= { docsQosServiceFlowStatsEntry 2 }

docsQosServiceFlowPolicedDropPkts OBJECT-TYPE
    SYNTAX          Counter32
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION    "The number of Packet Data PDUs classified to this
                    service flow dropped due to:
	               (1) implementation-dependent excessive delay while
	                   enforcing the Maximum Sustained Traffic Rate; or
		       (2) UGS packets dropped due to exceeding the 
	                   Unsolicited Grant Size with a 
	                   Request/Transmission policy that requires such 
                           packets to be dropped.
		    Classified packets dropped due to other reasons must be
	            counted in ifOutDiscards for interface of this 
	            service flow.

		    This counter's last discontinuity is the 
	            ifCounterDiscontinuityTime for same ifIndex that 
		    indexes this object."
    ::= { docsQosServiceFlowStatsEntry 6 }

docsQosServiceFlowPolicedDelayPkts OBJECT-TYPE
    SYNTAX          Counter32
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION    "This object counts only packets delayed in order to 
		    maintain the Maximum Sustained Traffic Rate. This object

	            will always report a value of 0 for UGS flows because the
		    Maximum Sustained Traffic Rate does not apply.

		    This counter's last discontinuity is the 
	            ifCounterDiscontinuityTime for same ifIndex that 
		    indexes this object."	
    ::= { docsQosServiceFlowStatsEntry 7 }


We do not want to have the same discussion about the description of these objects when we send our for comments version 9 of the DOCS-QOS-MIB. If there are any more comments please send then as soon as possible. Thank you again for reviewing this.

Sincerely,
Mike Patrick & Will Murwin

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



From mailnull@www1.ietf.org  Fri Jun  6 11:01:42 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27404
	for <ipcdn-archive@odin.ietf.org>; Fri, 6 Jun 2003 11:01:42 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h56F1Iw30707
	for ipcdn-archive@odin.ietf.org; Fri, 6 Jun 2003 11:01:18 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56F1HB30685;
	Fri, 6 Jun 2003 11:01:17 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56F0oB30562
	for <ipcdn@optimus.ietf.org>; Fri, 6 Jun 2003 11:00:50 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27332
	for <ipcdn@ietf.org>; Fri, 6 Jun 2003 11:00:44 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19OIg7-0002oR-00
	for ipcdn@ietf.org; Fri, 06 Jun 2003 10:58:51 -0400
Received: from motgate4.mot.com ([144.189.100.102])
	by ietf-mx with esmtp (Exim 4.12)
	id 19OIg6-0002oN-00
	for ipcdn@ietf.org; Fri, 06 Jun 2003 10:58:50 -0400
Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132])
	by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h56F0hwI013196
	for <ipcdn@ietf.org>; Fri, 6 Jun 2003 08:00:44 -0700 (MST)
Received: from ma07exm01.dma.isg.mot.com (ma07exm01.dma.isg.mot.com [150.21.2.102])
	by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id h56F0fdD017666
	for <ipcdn@ietf.org>; Fri, 6 Jun 2003 10:00:42 -0500
Received: by ma07exm01.dma.isg.mot.com with Internet Mail Service (5.5.2656.59)
	id <HNFXF37W>; Fri, 6 Jun 2003 11:00:41 -0400
Message-ID: <19CD0E423FC1D611893500508B6F0B9CAB736B@ma07exm01.dma.isg.mot.com>
From: Patrick Michael-LZZ007 <Michael.Patrick@motorola.com>
To: "'Minnie Lu'" <milu@cisco.com>,
        Murwin William-LWM008
	 <W.Murwin@motorola.com>
Cc: "Docsis-Oss (E-mail) (E-mail)" <docsis-oss@cablelabs.com>,
        "IPCDN (E-mail) (E-mail)" <ipcdn@ietf.org>
Date: Fri, 6 Jun 2003 11:00:40 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: [ipcdn] RE: Descriptions for docsQosSer
Sender: ipcdn-admin@ietf.org
Errors-To: ipcdn-admin@ietf.org
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=subscribe>

Minnie,

I used the word "classified" deliberately because the DOCSIS 1.1 architecture defines the set of packets onto a flow based on a classifer: "The basic model is that the Classifiers associate packets into exactly one Service Flow" (RFIv1.1-IO5 section 8.1.6).  I certainly do NOT want to use the word "transmitted" or "received", both of which introduce the much-discussed complexity regarding whether or not a packet is transmitted. 

The description explictly handles the sole exception, where CMs are not required to classify received packets.   

Are you aware of any instance where an implementor or tester misinterpreted the description wording?

-mike


-----Original Message-----
From: Minnie Lu [mailto:milu@cisco.com] 
Sent: Thursday, June 05, 2003 7:10 PM
To: Murwin William-LWM008
Cc: Docsis-Oss (E-mail) (E-mail); IPCDN (E-mail) (E-mail); Murwin William-LWM008; Patrick Michael-LZZ007
Subject: Re: Descriptions for docsQosSer


Hi,

Probably I miss something.  I don't know why the word "classified" was 
added into these counters.  These counters might be used for usage billing 
purpose.  With the word "classified", CMTS will only MUST report downtream 
service flows traffic statistics because CMTS only MUST classify downtream 
traffic to active downstream service flows.  Any reason could these 
counters not be used for the traffic sent or received via the service flow ?

Thanks !
Minnie

At 08:16 PM 6/4/2003 -0400, Murwin William-LWM008 wrote:
>When draft-ietf-ipcdn-qos-mib-08.txt was submitted to the mailling list
>there had been a disscusion about the descriptions for the objects:
>docsQosServiceFlowPkts
>docsQosServiceFlowOctets
>docsQosServiceFlowPolicedDropPkts
>docsQosServiceFlowPolicedDelayPkts
>
>Please review the current descriptions from 
>draft-ietf-ipcdn-qos-mib-08.txt  :
>
>docsQosServiceFlowPkts OBJECT-TYPE
>     SYNTAX          Counter64
>     MAX-ACCESS      read-only
>     STATUS          current
>     DESCRIPTION    "The number of Packet Data PDUs classified to this
>                     service flow and forwarded beyond a service flow
>                     maximum rate policing function.
>                     This object does not count MAC-specific
>                     management messages.
>                     CMs not classifying downstream packets may report
>                     this object's value as 0.
>
>                     Particularly for UGS flows, packets sent on the
>                     primary service flow in violation of the UGS grant
>                     size should be counted only on the primary service
>                     flow's counters.
>
>                     Unclassified upstream user data packets (i.e. non
>                     MAC-management) forwarded to the default upstream
>                     service flow should be incremented for this 
> object.
>
>                     This object does include packets counted by
>                     docsQosServiceFlowPolicedDelayPkts, but does not include
>                     packets counted by 
> docsQosServiceFlowPolicedDropPkts.
>
>                     This counter's last discontinuity is the
>                     ifCounterDiscontinuityTime for same ifIndex that
>                     indexes this object."
>     ::= { docsQosServiceFlowStatsEntry 1 }
>
>docsQosServiceFlowOctets OBJECT-TYPE
>     SYNTAX          Counter64
>     MAX-ACCESS      read-only
>     STATUS          current
>     DESCRIPTION    "The number of octets from the byte after the MAC
>                     header HCS to the end of the CRC for all packets counted
>                     in the docsQosServiceFlowPkts object for this row.
>                     Note that this counts the octets after payload header
>                     suppression has been applied. CMs not classifying to a
>                     downstream service flow may report this object's
>                     value as 0 for that flow.
>
>                     This counter's last discontinuity is the
>                     ifCounterDiscontinuityTime for same ifIndex that
>                     indexes this object."
>     ::= { docsQosServiceFlowStatsEntry 2 }
>
>docsQosServiceFlowPolicedDropPkts OBJECT-TYPE
>     SYNTAX          Counter32
>     MAX-ACCESS      read-only
>     STATUS          current
>     DESCRIPTION    "The number of Packet Data PDUs classified to this
>                     service flow dropped due to:
>                        (1) implementation-dependent excessive delay while
>                            enforcing the Maximum Sustained Traffic Rate; or
>                        (2) UGS packets dropped due to exceeding the
>                            Unsolicited Grant Size with a
>                            Request/Transmission policy that requires such
>                            packets to be dropped.
>                     Classified packets dropped due to other reasons must be
>                     counted in ifOutDiscards for interface of this
>                     service flow.
>
>                     This counter's last discontinuity is the
>                     ifCounterDiscontinuityTime for same ifIndex that
>                     indexes this object."
>     ::= { docsQosServiceFlowStatsEntry 6 }
>
>docsQosServiceFlowPolicedDelayPkts OBJECT-TYPE
>     SYNTAX          Counter32
>     MAX-ACCESS      read-only
>     STATUS          current
>     DESCRIPTION    "This object counts only packets delayed in order to
>                     maintain the Maximum Sustained Traffic Rate. This object
>                     will always report a value of 0 for UGS flows because the
>                     Maximum Sustained Traffic Rate does not apply.
>
>                     This counter's last discontinuity is the
>                     ifCounterDiscontinuityTime for same ifIndex that
>                     indexes this object."
>     ::= { docsQosServiceFlowStatsEntry 7 }
>
>
>We do not want to have the same discussion about the description of 
>these
>objects when we send our for comments version 9 of the DOCS-QOS-MIB.
>If there are any more comments please send then as soon as possible.
>Thank you again for reviewing this.
>
>Sincerely,
>Mike Patrick & Will Murwin
_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn



From mailnull@www1.ietf.org  Fri Jun  6 11:19:40 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28187
	for <ipcdn-archive@odin.ietf.org>; Fri, 6 Jun 2003 11:19:40 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h56FJCd32723
	for ipcdn-archive@odin.ietf.org; Fri, 6 Jun 2003 11:19:12 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56FJAB32715;
	Fri, 6 Jun 2003 11:19:10 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56FIRB32667
	for <ipcdn@optimus.ietf.org>; Fri, 6 Jun 2003 11:18:27 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28148
	for <ipcdn@ietf.org>; Fri, 6 Jun 2003 11:18:25 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19OIxE-00030M-00
	for ipcdn@ietf.org; Fri, 06 Jun 2003 11:16:32 -0400
Received: from [144.189.100.106] (helo=motgate6.mot.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19OIxD-00030J-00
	for ipcdn@ietf.org; Fri, 06 Jun 2003 11:16:31 -0400
Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134])
	by motgate6.mot.com (Motorola/Motgate6) with ESMTP id h56FIPff001031
	for <ipcdn@ietf.org>; Fri, 6 Jun 2003 08:18:25 -0700 (MST)
Received: from ma07exm01.dma.isg.mot.com (ma07exm01.dma.isg.mot.com [150.21.2.102])
	by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h56FINcl030570
	for <ipcdn@ietf.org>; Fri, 6 Jun 2003 10:18:24 -0500
Received: by ma07exm01.dma.isg.mot.com with Internet Mail Service (5.5.2656.59)
	id <HNFXF39L>; Fri, 6 Jun 2003 11:18:23 -0400
Message-ID: <19CD0E423FC1D611893500508B6F0B9CAB736C@ma07exm01.dma.isg.mot.com>
From: Patrick Michael-LZZ007 <Michael.Patrick@motorola.com>
To: "'Kirk Friedman'" <kfriedman@correlant.com>,
        Murwin William-LWM008
	 <W.Murwin@motorola.com>,
        "'Docsis-Oss (E-mail) (E-mail)'"
	 <docsis-oss@cablelabs.com>,
        "'IPCDN (E-mail) (E-mail)'" <ipcdn@ietf.org>
Subject: RE: [ipcdn] Descriptions for docsQosSer
Date: Fri, 6 Jun 2003 11:18:20 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: ipcdn-admin@ietf.org
Errors-To: ipcdn-admin@ietf.org
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=subscribe>

Kirk,

The compliance statement is correct in that both CMs and CMTSs are required to implement docsQosServiceFlowStats table.  For example, both ends classify outgoing packets to SFs, and so the stats are applicable. For the individual objects which might not be applicable, the description clause explains how to handle the case.

As for your questions, 

1) I had not intended docsQosServiceFlowPolicedDelayPkts to apply to received packets, only transmitted packets that were delayed before transmitting on the RF interface.  In the case of the CMTS, however, it is scheduling bursts (even concatenated ones) to a SID which is associated with a single service flow.  A reasonable question is whether the CMTS is required to increment this counter if it delays granting a request in order to limit the max rate to the SF of the SID.  DOCSIS already requires the CM to not even -make- such a request, so I don't think its reasonable to require the CMTS to count such delays.  Is there any objection (that means you, docsis-oss!) to clarifying that the value reported (by CMs and CMTSs) for docsQosServiceFlowPolicedDelayPkts of incoming flows is implementation-dependent, and may be zero?

2) Likewise, is there any objection to adding to the description that the reported value of docsQosServiceFlowPolicedDropPkts for incoming SFs is implementation-dependent and may be zero?
We'll also clarify that the ifOutDiscards clause will only apply to outgoing SFs. 

-mike & will


-----Original Message-----
From: Kirk Friedman [mailto:kfriedman@correlant.com] 
Sent: Thursday, June 05, 2003 6:27 PM
To: Murwin William-LWM008; 'Docsis-Oss (E-mail) (E-mail)'; 'IPCDN (E-mail) (E-mail)'
Cc: Patrick Michael-LZZ007
Subject: RE: [ipcdn] Descriptions for docsQosSer


Will and Mike,

Thanks for doing all this work.  The descriptions seem to be written from a CM only perspective.  The compliance statement puts DocsQosServiceFlowStatsTable into the base group for CMs and CMTS.  Section 2.4.2 seems to imply that these statistics are only kept for packets going to/from the RF interface.  That might also need to be rewritten unless that is what is intended.

If that is what is intended, then the individual parameters or compliances should be indicate which directions for the CMTS the parameters apply to. Perhaps the equivalent of "CMTS' MUST report this as 0 for upstream service flows" for the PolicedDrop/Delay packet counters.  Otherwise I have some
questions:

1) From a CMTS perspective, why is docsQosServiceFlowPolicedDelayPkts
applied to upstream SFs at all?  This would be very difficult with concatenation of multiple packets inside of one burst.

2) Regarding docsQosServiceFlowPolicedDropPkts.  Part of the description is "Classified packets dropped due to other reasons must be counted in ifOutDiscards for interface of this service flow."  But for the CMTS, the OSS spec has ifOutDiscards as MUST be 0 for upstream interfaces.


Thanks,

Kirk Friedman
Correlant Communications
15110 Avenue Of Science
San Diego, CA., 92128


-----Original Message-----
From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Murwin William-LWM008
Sent: Wednesday, June 04, 2003 5:16 PM
To: Docsis-Oss (E-mail) (E-mail); IPCDN (E-mail) (E-mail)
Cc: Murwin William-LWM008; Patrick Michael-LZZ007
Subject: [ipcdn] Descriptions for docsQosSer


When draft-ietf-ipcdn-qos-mib-08.txt was submitted to the mailling list there had been a disscusion about the descriptions for the objects: docsQosServiceFlowPkts docsQosServiceFlowOctets docsQosServiceFlowPolicedDropPkts docsQosServiceFlowPolicedDelayPkts

Please review the current descriptions from draft-ietf-ipcdn-qos-mib-08.txt
:

docsQosServiceFlowPkts OBJECT-TYPE
    SYNTAX          Counter64
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION    "The number of Packet Data PDUs classified to this
                    service flow and forwarded beyond a service flow
                    maximum rate policing function.
                    This object does not count MAC-specific
                    management messages.
                    CMs not classifying downstream packets may report
                    this object's value as 0.

		    Particularly for UGS flows, packets sent on the
                    primary service flow in violation of the UGS grant
                    size should be counted only on the primary service
                    flow's counters.

		    Unclassified upstream user data packets (i.e. non
		    MAC-management) forwarded to the default upstream
		    service flow should be incremented for this object.

		    This object does include packets counted by
                    docsQosServiceFlowPolicedDelayPkts, but does not include
                    packets counted by docsQosServiceFlowPolicedDropPkts.

		    This counter's last discontinuity is the
	            ifCounterDiscontinuityTime for same ifIndex that
		    indexes this object."
    ::= { docsQosServiceFlowStatsEntry 1 }

docsQosServiceFlowOctets OBJECT-TYPE
    SYNTAX          Counter64
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION    "The number of octets from the byte after the MAC
	            header HCS to the end of the CRC for all packets counted
                    in the docsQosServiceFlowPkts object for this row.
                    Note that this counts the octets after payload header
                    suppression has been applied. CMs not classifying to a
                    downstream service flow may report this object's
                    value as 0 for that flow.

                    This counter's last discontinuity is the
	            ifCounterDiscontinuityTime for same ifIndex that
		    indexes this object."
    ::= { docsQosServiceFlowStatsEntry 2 }

docsQosServiceFlowPolicedDropPkts OBJECT-TYPE
    SYNTAX          Counter32
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION    "The number of Packet Data PDUs classified to this
                    service flow dropped due to:
	               (1) implementation-dependent excessive delay while
	                   enforcing the Maximum Sustained Traffic Rate; or
		       (2) UGS packets dropped due to exceeding the
	                   Unsolicited Grant Size with a
	                   Request/Transmission policy that requires such
                           packets to be dropped.
		    Classified packets dropped due to other reasons must be
	            counted in ifOutDiscards for interface of this
	            service flow.

		    This counter's last discontinuity is the
	            ifCounterDiscontinuityTime for same ifIndex that
		    indexes this object."
    ::= { docsQosServiceFlowStatsEntry 6 }

docsQosServiceFlowPolicedDelayPkts OBJECT-TYPE
    SYNTAX          Counter32
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION    "This object counts only packets delayed in order to
		    maintain the Maximum Sustained Traffic Rate. This object
	            will always report a value of 0 for UGS flows because the
		    Maximum Sustained Traffic Rate does not apply.

		    This counter's last discontinuity is the
	            ifCounterDiscontinuityTime for same ifIndex that
		    indexes this object."
    ::= { docsQosServiceFlowStatsEntry 7 }


We do not want to have the same discussion about the description of these objects when we send our for comments version 9 of the DOCS-QOS-MIB. If there are any more comments please send then as soon as possible. Thank you again for reviewing this.

Sincerely,
Mike Patrick & Will Murwin


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



From mailnull@www1.ietf.org  Fri Jun  6 16:19:50 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11192
	for <ipcdn-archive@odin.ietf.org>; Fri, 6 Jun 2003 16:19:50 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h56KJNX26344
	for ipcdn-archive@odin.ietf.org; Fri, 6 Jun 2003 16:19:23 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56KJKB26335;
	Fri, 6 Jun 2003 16:19:20 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56KIuB26285
	for <ipcdn@optimus.ietf.org>; Fri, 6 Jun 2003 16:18:56 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11151
	for <ipcdn@ietf.org>; Fri, 6 Jun 2003 16:18:52 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ONdx-00066n-00
	for ipcdn@ietf.org; Fri, 06 Jun 2003 16:16:57 -0400
Received: from motgate.mot.com ([129.188.136.100])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ONdt-00066k-00
	for ipcdn@ietf.org; Fri, 06 Jun 2003 16:16:53 -0400
Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234])
	by motgate.mot.com (Motorola/Motgate) with ESMTP id h56KImcf021881
	for <ipcdn@ietf.org>; Fri, 6 Jun 2003 13:18:49 -0700 (MST)
Received: from ma07exm01.dma.isg.mot.com (ma07exm01.dma.isg.mot.com [150.21.2.102])
	by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h56KIcVN014928
	for <ipcdn@ietf.org>; Fri, 6 Jun 2003 15:18:40 -0500
Received: by ma07exm01.dma.isg.mot.com with Internet Mail Service (5.5.2656.59)
	id <HNFXFP57>; Fri, 6 Jun 2003 16:18:38 -0400
Message-ID: <19CD0E423FC1D611893500508B6F0B9CAB7378@ma07exm01.dma.isg.mot.com>
From: Patrick Michael-LZZ007 <Michael.Patrick@motorola.com>
To: "'Minnie Lu'" <milu@cisco.com>
Cc: Murwin William-LWM008 <W.Murwin@motorola.com>,
        "Docsis-Oss (E-mail) (E-mail)" <docsis-oss@cablelabs.com>,
        "IPCDN (E-mail) (E-mail)" <ipcdn@ietf.org>
Date: Fri, 6 Jun 2003 16:18:37 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: [ipcdn] RE: Descriptions for docsQosSer
Sender: ipcdn-admin@ietf.org
Errors-To: ipcdn-admin@ietf.org
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=subscribe>

Minnie,

I don't suppose you'd let me take a liberal interpretation of the word "classified" for the CMTS upstream flows to mean the CM did the classification :-) ?

The reason for adding the word "classified" was to avoid having to adjust the count if the packet couldn't actually be transmitted due to other reasons (like being too long for a UGS grant, for instance). 
It certainly was not our intention for the CMTS to stop counting -received- service flow packets !!

I suppose we could clarify that "classified" applies to outgoing flows, and the incoming flows (to the CMTS) include those packets which were received. 

This opens a can of worms concerning errors in the receive process. Does anyone feel docsQosServiceFlowPackets has to explicitly specify whether a CMTS counts upstream packets received with errors like checksum errors? [IMO it shouldn't]   Or should it count grants given to a particular service flow even if the CM didn't send a packet in that grant? [IMO, it shouldn't]
Both of these cases involve error troubleshooting that is, IMO, beyond the scope of the docsQosMib.

-mike



-----Original Message-----
From: Minnie Lu [mailto:milu@cisco.com] 
Sent: Friday, June 06, 2003 2:12 PM
To: Patrick Michael-LZZ007
Cc: 'Minnie Lu'; Murwin William-LWM008; Docsis-Oss (E-mail) (E-mail); IPCDN (E-mail) (E-mail)
Subject: RE: Descriptions for docsQosSer


Hi, Patrick,

  Thanks for your reply.  Then please help me to understand why "sole 
exception" only apply to CM ?

RFIv1.1-I09-020830, Section 8.1.6, "The CMTS MUST classify downstream 
traffic to Active Downstream Service Flows.". Does it mean that with the 
word "classified", for CMTS which does not classify the upstream traffic, 
those counters with "classified" word will also allow to report 0 for CMTS ?

As I know, some customers could use the service flow counters for usage 
based billing.  SAMIS ECN OSS-N-02197 reports the service flows counters 
for downtreams and upstreams.  Then how could these service flows counters 
be used for usage billing from CMTS's point of view  ?

Another concern is the backward capability. The 
draft-ietf-ipcdn-qos-mib-04.txt which is now used in the field for most of 
vendors' CMTS does not have the word 'classified'. If I remembered right, 
there will be NO NEW ECR for OSSIv1.1 spec. That is, the DOCS-QOS-MIB 
version is still draft-ietf-ipcdn-qos-mib-04.txt in OSSIv1.1 spec..

draft-ietf-ipcdn-qos-mib-04.txt :
docsQosServiceFlowPkts
  "The number of packet counted on this service flow." docsQosServiceFlowOctets
   "The number of octets counted on this service flow
                     after payload header suppression."

Thanks a lot for your help again !
Minnie

At 11:00 AM 6/6/2003 -0400, Patrick Michael-LZZ007 wrote:
>Minnie,
>
>I used the word "classified" deliberately because the DOCSIS 1.1
>architecture defines the set of packets onto a flow based on a classifer: 
>"The basic model is that the Classifiers associate packets into exactly 
>one Service Flow" (RFIv1.1-IO5 section 8.1.6).  I certainly do NOT want to 
>use the word "transmitted" or "received", both of which introduce the 
>much-discussed complexity regarding whether or not a packet is transmitted.
>
>The description explictly handles the sole exception, where CMs are not
>required to classify received packets.
>
>Are you aware of any instance where an implementor or tester
>misinterpreted the description wording?
>
>-mike
>
>
>-----Original Message-----
>From: Minnie Lu [mailto:milu@cisco.com]
>Sent: Thursday, June 05, 2003 7:10 PM
>To: Murwin William-LWM008
>Cc: Docsis-Oss (E-mail) (E-mail); IPCDN (E-mail) (E-mail); Murwin
>William-LWM008; Patrick Michael-LZZ007
>Subject: Re: Descriptions for docsQosSer
>
>
>Hi,
>
>Probably I miss something.  I don't know why the word "classified" was 
>added into these counters.  These counters might be used for usage 
>billing purpose.  With the word "classified", CMTS will only MUST 
>report downtream service flows traffic statistics because CMTS only 
>MUST classify downtream traffic to active downstream service flows.  
>Any reason could these counters not be used for the traffic sent or 
>received via the service flow ?
>
>Thanks !
>Minnie
>
>At 08:16 PM 6/4/2003 -0400, Murwin William-LWM008 wrote:
> >When draft-ietf-ipcdn-qos-mib-08.txt was submitted to the mailling 
> >list there had been a disscusion about the descriptions for the 
> >objects: docsQosServiceFlowPkts docsQosServiceFlowOctets
> >docsQosServiceFlowPolicedDropPkts
> >docsQosServiceFlowPolicedDelayPkts
> >
> >Please review the current descriptions from 
> >draft-ietf-ipcdn-qos-mib-08.txt  :
> >
> >docsQosServiceFlowPkts OBJECT-TYPE
> >     SYNTAX          Counter64
> >     MAX-ACCESS      read-only
> >     STATUS          current
> >     DESCRIPTION    "The number of Packet Data PDUs classified to this
> >                     service flow and forwarded beyond a service flow
> >                     maximum rate policing function.
> >                     This object does not count MAC-specific
> >                     management messages.
> >                     CMs not classifying downstream packets may report
> >                     this object's value as 0.
> >
> >                     Particularly for UGS flows, packets sent on the
> >                     primary service flow in violation of the UGS grant
> >                     size should be counted only on the primary service
> >                     flow's counters.
> >
> >                     Unclassified upstream user data packets (i.e. non
> >                     MAC-management) forwarded to the default upstream
> >                     service flow should be incremented for this 
> > object.
> >
> >                     This object does include packets counted by
> >                     docsQosServiceFlowPolicedDelayPkts, but does not
> include
> >                     packets counted by 
> > docsQosServiceFlowPolicedDropPkts.
> >
> >                     This counter's last discontinuity is the
> >                     ifCounterDiscontinuityTime for same ifIndex that
> >                     indexes this object."
> >     ::= { docsQosServiceFlowStatsEntry 1 }
> >
> >docsQosServiceFlowOctets OBJECT-TYPE
> >     SYNTAX          Counter64
> >     MAX-ACCESS      read-only
> >     STATUS          current
> >     DESCRIPTION    "The number of octets from the byte after the MAC
> >                     header HCS to the end of the CRC for all packets
> counted
> >                     in the docsQosServiceFlowPkts object for this row.
> >                     Note that this counts the octets after payload header
> >                     suppression has been applied. CMs not classifying to a
> >                     downstream service flow may report this object's
> >                     value as 0 for that flow.
> >
> >                     This counter's last discontinuity is the
> >                     ifCounterDiscontinuityTime for same ifIndex that
> >                     indexes this object."
> >     ::= { docsQosServiceFlowStatsEntry 2 }
> >
> >docsQosServiceFlowPolicedDropPkts OBJECT-TYPE
> >     SYNTAX          Counter32
> >     MAX-ACCESS      read-only
> >     STATUS          current
> >     DESCRIPTION    "The number of Packet Data PDUs classified to this
> >                     service flow dropped due to:
> >                        (1) implementation-dependent excessive delay while
> >                            enforcing the Maximum Sustained Traffic Rate; or
> >                        (2) UGS packets dropped due to exceeding the
> >                            Unsolicited Grant Size with a
> >                            Request/Transmission policy that requires such
> >                            packets to be dropped.
> >                     Classified packets dropped due to other reasons must be
> >                     counted in ifOutDiscards for interface of this
> >                     service flow.
> >
> >                     This counter's last discontinuity is the
> >                     ifCounterDiscontinuityTime for same ifIndex that
> >                     indexes this object."
> >     ::= { docsQosServiceFlowStatsEntry 6 }
> >
> >docsQosServiceFlowPolicedDelayPkts OBJECT-TYPE
> >     SYNTAX          Counter32
> >     MAX-ACCESS      read-only
> >     STATUS          current
> >     DESCRIPTION    "This object counts only packets delayed in order to
> >                     maintain the Maximum Sustained Traffic Rate. 
> >This
> object
> >                     will always report a value of 0 for UGS flows
> because the
> >                     Maximum Sustained Traffic Rate does not apply.
> >
> >                     This counter's last discontinuity is the
> >                     ifCounterDiscontinuityTime for same ifIndex that
> >                     indexes this object."
> >     ::= { docsQosServiceFlowStatsEntry 7 }
> >
> >
> >We do not want to have the same discussion about the description of 
> >these objects when we send our for comments version 9 of the 
> >DOCS-QOS-MIB. If there are any more comments please send then as soon 
> >as possible. Thank you again for reviewing this.
> >
> >Sincerely,
> >Mike Patrick & Will Murwin
_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn



From mailnull@www1.ietf.org  Fri Jun  6 17:04:34 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12845
	for <ipcdn-archive@odin.ietf.org>; Fri, 6 Jun 2003 17:04:34 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h56L48a30107
	for ipcdn-archive@odin.ietf.org; Fri, 6 Jun 2003 17:04:08 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56L46B30095;
	Fri, 6 Jun 2003 17:04:06 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56ICIB16808
	for <ipcdn@optimus.ietf.org>; Fri, 6 Jun 2003 14:12:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05500
	for <ipcdn@ietf.org>; Fri, 6 Jun 2003 14:12:13 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19OLfN-00052M-00
	for ipcdn@ietf.org; Fri, 06 Jun 2003 14:10:17 -0400
Received: from sj-core-5.cisco.com ([171.71.177.238])
	by ietf-mx with esmtp (Exim 4.12)
	id 19OLfL-00051n-00
	for ipcdn@ietf.org; Fri, 06 Jun 2003 14:10:16 -0400
Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h56IBWjc027433;
	Fri, 6 Jun 2003 11:11:32 -0700 (PDT)
Received: from milu-w2k.cisco.com (dhcp-171-71-51-93.cisco.com [171.71.51.93])
	by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR)
	with ESMTP id AIC01936;
	Fri, 6 Jun 2003 11:11:31 -0700 (PDT)
Message-Id: <4.3.2.7.2.20030606104835.02213920@mira-sjc5-1.cisco.com>
X-Sender: milu@mira-sjc5-1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 06 Jun 2003 11:11:31 -0700
To: Patrick Michael-LZZ007 <Michael.Patrick@motorola.com>
From: Minnie Lu <milu@cisco.com>
Cc: "'Minnie Lu'" <milu@cisco.com>,
        Murwin William-LWM008 <W.Murwin@motorola.com>,
        "Docsis-Oss (E-mail) (E-mail)" <docsis-oss@cablelabs.com>,
        "IPCDN (E-mail) (E-mail)" <ipcdn@ietf.org>
In-Reply-To: <19CD0E423FC1D611893500508B6F0B9CAB736B@ma07exm01.dma.isg.m
 ot.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [ipcdn] RE: Descriptions for docsQosSer
Sender: ipcdn-admin@ietf.org
Errors-To: ipcdn-admin@ietf.org
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=subscribe>

Hi, Patrick,

  Thanks for your reply.  Then please help me to understand why "sole 
exception" only apply to CM ?

RFIv1.1-I09-020830, Section 8.1.6, "The CMTS MUST classify downstream 
traffic to Active Downstream Service Flows.". Does it mean that with the 
word "classified", for CMTS which does not classify the upstream traffic, 
those counters with "classified" word will also allow to report 0 for CMTS ?

As I know, some customers could use the service flow counters for usage 
based billing.  SAMIS ECN OSS-N-02197 reports the service flows counters 
for downtreams and upstreams.  Then how could these service flows counters 
be used for usage billing from CMTS's point of view  ?

Another concern is the backward capability. The 
draft-ietf-ipcdn-qos-mib-04.txt which is now used in the field for most of 
vendors' CMTS does not have the word 'classified'. If I remembered right, 
there will be NO NEW ECR for OSSIv1.1 spec. That is, the DOCS-QOS-MIB 
version is still draft-ietf-ipcdn-qos-mib-04.txt in OSSIv1.1 spec..

draft-ietf-ipcdn-qos-mib-04.txt :
docsQosServiceFlowPkts
  "The number of packet counted on this service flow."
docsQosServiceFlowOctets
   "The number of octets counted on this service flow
                     after payload header suppression."

Thanks a lot for your help again !
Minnie

At 11:00 AM 6/6/2003 -0400, Patrick Michael-LZZ007 wrote:
>Minnie,
>
>I used the word "classified" deliberately because the DOCSIS 1.1 
>architecture defines the set of packets onto a flow based on a classifer: 
>"The basic model is that the Classifiers associate packets into exactly 
>one Service Flow" (RFIv1.1-IO5 section 8.1.6).  I certainly do NOT want to 
>use the word "transmitted" or "received", both of which introduce the 
>much-discussed complexity regarding whether or not a packet is transmitted.
>
>The description explictly handles the sole exception, where CMs are not 
>required to classify received packets.
>
>Are you aware of any instance where an implementor or tester 
>misinterpreted the description wording?
>
>-mike
>
>
>-----Original Message-----
>From: Minnie Lu [mailto:milu@cisco.com]
>Sent: Thursday, June 05, 2003 7:10 PM
>To: Murwin William-LWM008
>Cc: Docsis-Oss (E-mail) (E-mail); IPCDN (E-mail) (E-mail); Murwin 
>William-LWM008; Patrick Michael-LZZ007
>Subject: Re: Descriptions for docsQosSer
>
>
>Hi,
>
>Probably I miss something.  I don't know why the word "classified" was
>added into these counters.  These counters might be used for usage billing
>purpose.  With the word "classified", CMTS will only MUST report downtream
>service flows traffic statistics because CMTS only MUST classify downtream
>traffic to active downstream service flows.  Any reason could these
>counters not be used for the traffic sent or received via the service flow ?
>
>Thanks !
>Minnie
>
>At 08:16 PM 6/4/2003 -0400, Murwin William-LWM008 wrote:
> >When draft-ietf-ipcdn-qos-mib-08.txt was submitted to the mailling list
> >there had been a disscusion about the descriptions for the objects:
> >docsQosServiceFlowPkts
> >docsQosServiceFlowOctets
> >docsQosServiceFlowPolicedDropPkts
> >docsQosServiceFlowPolicedDelayPkts
> >
> >Please review the current descriptions from
> >draft-ietf-ipcdn-qos-mib-08.txt  :
> >
> >docsQosServiceFlowPkts OBJECT-TYPE
> >     SYNTAX          Counter64
> >     MAX-ACCESS      read-only
> >     STATUS          current
> >     DESCRIPTION    "The number of Packet Data PDUs classified to this
> >                     service flow and forwarded beyond a service flow
> >                     maximum rate policing function.
> >                     This object does not count MAC-specific
> >                     management messages.
> >                     CMs not classifying downstream packets may report
> >                     this object's value as 0.
> >
> >                     Particularly for UGS flows, packets sent on the
> >                     primary service flow in violation of the UGS grant
> >                     size should be counted only on the primary service
> >                     flow's counters.
> >
> >                     Unclassified upstream user data packets (i.e. non
> >                     MAC-management) forwarded to the default upstream
> >                     service flow should be incremented for this
> > object.
> >
> >                     This object does include packets counted by
> >                     docsQosServiceFlowPolicedDelayPkts, but does not 
> include
> >                     packets counted by
> > docsQosServiceFlowPolicedDropPkts.
> >
> >                     This counter's last discontinuity is the
> >                     ifCounterDiscontinuityTime for same ifIndex that
> >                     indexes this object."
> >     ::= { docsQosServiceFlowStatsEntry 1 }
> >
> >docsQosServiceFlowOctets OBJECT-TYPE
> >     SYNTAX          Counter64
> >     MAX-ACCESS      read-only
> >     STATUS          current
> >     DESCRIPTION    "The number of octets from the byte after the MAC
> >                     header HCS to the end of the CRC for all packets 
> counted
> >                     in the docsQosServiceFlowPkts object for this row.
> >                     Note that this counts the octets after payload header
> >                     suppression has been applied. CMs not classifying to a
> >                     downstream service flow may report this object's
> >                     value as 0 for that flow.
> >
> >                     This counter's last discontinuity is the
> >                     ifCounterDiscontinuityTime for same ifIndex that
> >                     indexes this object."
> >     ::= { docsQosServiceFlowStatsEntry 2 }
> >
> >docsQosServiceFlowPolicedDropPkts OBJECT-TYPE
> >     SYNTAX          Counter32
> >     MAX-ACCESS      read-only
> >     STATUS          current
> >     DESCRIPTION    "The number of Packet Data PDUs classified to this
> >                     service flow dropped due to:
> >                        (1) implementation-dependent excessive delay while
> >                            enforcing the Maximum Sustained Traffic Rate; or
> >                        (2) UGS packets dropped due to exceeding the
> >                            Unsolicited Grant Size with a
> >                            Request/Transmission policy that requires such
> >                            packets to be dropped.
> >                     Classified packets dropped due to other reasons must be
> >                     counted in ifOutDiscards for interface of this
> >                     service flow.
> >
> >                     This counter's last discontinuity is the
> >                     ifCounterDiscontinuityTime for same ifIndex that
> >                     indexes this object."
> >     ::= { docsQosServiceFlowStatsEntry 6 }
> >
> >docsQosServiceFlowPolicedDelayPkts OBJECT-TYPE
> >     SYNTAX          Counter32
> >     MAX-ACCESS      read-only
> >     STATUS          current
> >     DESCRIPTION    "This object counts only packets delayed in order to
> >                     maintain the Maximum Sustained Traffic Rate. This 
> object
> >                     will always report a value of 0 for UGS flows 
> because the
> >                     Maximum Sustained Traffic Rate does not apply.
> >
> >                     This counter's last discontinuity is the
> >                     ifCounterDiscontinuityTime for same ifIndex that
> >                     indexes this object."
> >     ::= { docsQosServiceFlowStatsEntry 7 }
> >
> >
> >We do not want to have the same discussion about the description of
> >these
> >objects when we send our for comments version 9 of the DOCS-QOS-MIB.
> >If there are any more comments please send then as soon as possible.
> >Thank you again for reviewing this.
> >
> >Sincerely,
> >Mike Patrick & Will Murwin

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



From mailnull@www1.ietf.org  Fri Jun  6 17:32:44 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14210
	for <ipcdn-archive@odin.ietf.org>; Fri, 6 Jun 2003 17:32:44 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h56LWJc32461
	for ipcdn-archive@odin.ietf.org; Fri, 6 Jun 2003 17:32:19 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56LWHB32454;
	Fri, 6 Jun 2003 17:32:17 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56LV9B32411
	for <ipcdn@optimus.ietf.org>; Fri, 6 Jun 2003 17:31:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14194
	for <ipcdn@ietf.org>; Fri, 6 Jun 2003 17:31:04 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19OOlq-0006o6-00
	for ipcdn@ietf.org; Fri, 06 Jun 2003 17:29:10 -0400
Received: from coral.tci.com ([198.178.8.81] helo=dapsang.tci.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19OOlp-0006nN-00
	for ipcdn@ietf.org; Fri, 06 Jun 2003 17:29:09 -0400
Received: from entexchimc03.broadband.att.com ([127.0.0.1])
	by dapsang.tci.com (8.12.9/8.12.9) with ESMTP id h56LUVeJ009070
	for <ipcdn@ietf.org>; Fri, 6 Jun 2003 15:30:31 -0600 (MDT)
Received: by entexchimc03.broadband.att.com with Internet Mail Service (5.5.2653.19)
	id <MM0Y6B3V>; Fri, 6 Jun 2003 15:30:30 -0600
Message-ID: <6732623D2548D61193C90002A5C88DCC05663B4D@entmaexch02.broadband.att.com>
From: "Woundy, Richard" <Richard_Woundy@cable.comcast.com>
To: "IPCDN WG (E-mail)" <ipcdn@ietf.org>
Date: Fri, 6 Jun 2003 15:30:26 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [ipcdn] FW: VLAn ID
Sender: ipcdn-admin@ietf.org
Errors-To: ipcdn-admin@ietf.org
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=subscribe>

FYI only. The email below relates to using the VlanIdOrAny TC in the DOCSIS
QoS MIB, and possibly other IPCDN MIBs...

-- Rich

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Friday, June 06, 2003 11:30 AM
To: Tony Jeffree
Cc: mibs@ops.ietf.org; Bridge-Mib (E-mail)
Subject: RE: VLAn ID


Tony... am I copy-ing the mailing lists on which
we discussed this, so that people can chime in

Thanks,
Bert 

> -----Original Message-----
> From: Tony Jeffree [mailto:tony@jeffree.co.uk]
> Sent: vrijdag 6 juni 2003 17:16
> To: Wijnen, Bert (Bert)
> Subject: RE: VLAn ID
> 
> 
> Bert et al -
> 
> We have concluded that the use of 4095 as a wildcard is acceptable to 
> 802.1, and we will make any necessary changes to 802.1Q in 
> due course to 
> relax the current stated restriction. However, we need to 
> know whether that 
> is all that needs to be done to 802.1Q - i.e., is there any 
> need to change 
> our definitions of the managed objects in the document (Clause 12) to 
> reflect the interpretation of 4095 as a wildcard, or is this 
> simply an 
> issue for the SNMP machinery to handle?
> 
> Regards,
> Tony
> 
> 
> At 11:58 07/05/2003 +0200, you wrote:
> >Any chance you can stirr up that 'ballot' process?
> >Some people are waiting for a solution in IETF MIB land.
> >
> >Thanks,
> >Bert
> >
> > > -----Original Message-----
> > > From: Les Bell [mailto:Les_Bell@eur.3com.com]
> > > Sent: woensdag 7 mei 2003 9:06
> > > To: Wijnen, Bert (Bert)
> > > Cc: Andrew Smith; 'Bridge-Mib (E-mail)'; mibs@ops.ietf.org;
> > > tony@jeffree.co.uk; mick_seaman@ieee.org
> > > Subject: RE: VLAn ID
> > >
> > >
> > >
> > >
> > >
> > > This was discussed at the March meeting.  The decision was to
> > > conduct an email
> > > 'ballot' to determine if anyone had any objections to using
> > > 4095 as a wildcard
> > > VLAN ID.  I have not heard about the details of how, or when,
> > > this will take
> > > place.
> > >
> > > Les...
> > >
> > >
> > >
> > >
> > >
> > > "Wijnen, Bert (Bert)" <bwijnen@lucent.com> on 06/05/2003 18:43:42
> > >
> > > Sent by:  "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
> > >
> > >
> > > To:   Les Bell/GB/3Com, Andrew Smith <ah_smith@acm.org>
> > > cc:   "'Wijnen, Bert , "'Bridge-Mib , mibs@ops.ietf.org
> > > Subject:  RE: VLAn ID
> > >
> > >
> > >
> > >
> > > Les, Did you get any feedback after that March 9th meeting?
> > > If not, Can you poll Mick Seaman?
> > >
> > > Thanks,
> > > Bert
> > >
> > > > -----Original Message-----
> > > > From: Les Bell [mailto:Les_Bell@eur.3com.com]
> > > > Sent: vrijdag 28 februari 2003 17:27
> > > > To: Andrew Smith
> > > > Cc: 'Wijnen, Bert (Bert)'; 'Bridge-Mib (E-mail)'; 
> mibs@ops.ietf.org
> > > > Subject: RE: VLAn ID
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > I have asked for the opinion of the IEEE 802.1 Task Force
> > > > Chair, Mick Seaman, on
> > > > this proposal.  He believes that the use of 4095 as a
> > > > wildcard VLAN-ID would be
> > > > okay, but he wants to discuss it formally at the IEEE 802
> > > > meeting in Dallas
> > > > (week commencing March 9).  I will be attending this meeting.
> > > >
> > > > Les...
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > "Andrew Smith" <ah_smith@acm.org> on 27/02/2003 17:53:56
> > > >
> > > > Sent by:  "Andrew Smith" <ah_smith@acm.org>
> > > >
> > > >
> > > > To:   "'Wijnen, Bert \
> > > > cc:   "'Bridge-Mib \, mibs@ops.ietf.org (Les Bell/GB/3Com)
> > > > Subject:  RE: VLAn ID
> > > >
> > > >
> > > >
> > > >
> > > > Bert,
> > > >
> > > > The whole point of defining these TCs in a separate document
> > > > is to serve
> > > > "possible future (yet-undefined) needs" - why else would we
> > > bother to
> > > > break them out in a separate document or module?
> > > >
> > > > The need to use VlanIdOrAny as an index in the future seems
> > > likely to
> > > > me. It is especially likely if you believe that we're
> > > trying to set a
> > > > precedent here for how to represent "some sort of 
> packet field or
> > > > don't-care". Personally, I think it's a bit clunky to
> > > > overload the value
> > > > like this - a separate flag object is more elegant, 
> but, if we're
> > > > comfortable with the overloading, I'd go with Randy and say
> > > (as I did
> > > > before - maybe you missed my message?) that the syntax here
> > > should be
> > > > unsigned, not signed (I understand the practical reasons for the
> > > > non-negative-index restriction in SNMP but it is a 
> limitation on the
> > > > SMIv2 language). I don't think there's a need to consult
> > > with IEEE 802
> > > > on this - I think most of the people with relevant opinions
> > > > on this are
> > > > already on this thread - but that's the bridge-mib WG chair's
> > > > call if he
> > > > wants to ask himself for help.
> > > >
> > > > My opinions (I know you're looking for others though ...).
> > > >
> > > > Andrew
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: owner-mibs@ops.ietf.org
> > > [mailto:owner-mibs@ops.ietf.org] On Behalf
> > > Of Wijnen, Bert (Bert)
> > > Sent: Thursday, February 27, 2003 8:36 AM
> > > To: Randy Presuhn (E-mail)
> > > Cc: Bridge-Mib (E-mail); mibs@ops.ietf.org
> > > Subject: VLAn ID
> > >
> > >
> > > Randy, you wrote:
> > > >To:   bridge-mib@ietf.org
> > > >cc:   mibs@ops.ietf.org (Les Bell/GB/3Com)
> > > >Subject:  Re: [Bridge-mib] VLAN-ID
> > > >
> > > >Hi -
> > > >
> > > >I think it would be better if the "any" value in the 
> *OrAny TC were
> > > >a non-negative value so that the type could be used to define an
> > > >index.  There may not be a need today, but thinking ahead to
> > > >representing policy-like things wouldn't hurt.
> > > >
> > >
> > > As far as I can tell, you seem to be the only one sofar who
> > > has spoken up on the idea of not having a negative value
> > > for the "any" for the VlanIdOrAny TC that I proposed.
> > >
> > > You do not claim an immediate need, but a possible future
> > > (yet-undefined) need.
> > >
> > > S
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> 
> Regards,
> Tony
> 
_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn



From mailnull@www1.ietf.org  Sun Jun  8 16:36:31 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29857
	for <ipcdn-archive@odin.ietf.org>; Sun, 8 Jun 2003 16:36:29 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h58KZt521988
	for ipcdn-archive@odin.ietf.org; Sun, 8 Jun 2003 16:35:55 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h58KZjB21980;
	Sun, 8 Jun 2003 16:35:45 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h570kMB12955
	for <ipcdn@optimus.ietf.org>; Fri, 6 Jun 2003 20:46:22 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19742
	for <ipcdn@ietf.org>; Fri, 6 Jun 2003 20:46:18 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ORol-00009j-00
	for ipcdn@ietf.org; Fri, 06 Jun 2003 20:44:23 -0400
Received: from sj-core-1.cisco.com ([171.71.177.237])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ORol-00009a-00
	for ipcdn@ietf.org; Fri, 06 Jun 2003 20:44:23 -0400
Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h570jgmu007020;
	Fri, 6 Jun 2003 17:45:43 -0700 (PDT)
Received: from milu-w2k.cisco.com (dhcp-171-71-51-93.cisco.com [171.71.51.93])
	by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR)
	with ESMTP id AIC51706;
	Fri, 6 Jun 2003 17:45:41 -0700 (PDT)
Message-Id: <4.3.2.7.2.20030606164127.04ae58c0@mira-sjc5-1.cisco.com>
X-Sender: milu@mira-sjc5-1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 06 Jun 2003 17:45:18 -0700
To: Patrick Michael-LZZ007 <Michael.Patrick@motorola.com>
From: Minnie Lu <milu@cisco.com>
Cc: "'Minnie Lu'" <milu@cisco.com>,
        Murwin William-LWM008 <W.Murwin@motorola.com>,
        "Docsis-Oss (E-mail) (E-mail)" <docsis-oss@cablelabs.com>,
        "IPCDN (E-mail) (E-mail)" <ipcdn@ietf.org>
In-Reply-To: <19CD0E423FC1D611893500508B6F0B9CAB7378@ma07exm01.dma.isg.m
 ot.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [ipcdn] RE: Descriptions for docsQosSer
Sender: ipcdn-admin@ietf.org
Errors-To: ipcdn-admin@ietf.org
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=subscribe>

Hi, Patrick,

Thanks for your reply.  Please see my response inline.
Thanks!
Minnie

At 04:18 PM 6/6/2003 -0400, Patrick Michael-LZZ007 wrote:
>Minnie,
>
>I don't suppose you'd let me take a liberal interpretation of the word 
>"classified" for the CMTS upstream flows to mean the CM did the 
>classification :-) ?

[milu]: No.:-)


>The reason for adding the word "classified" was to avoid having to adjust 
>the count if the packet couldn't actually be transmitted due to other 
>reasons (like being too long for a UGS grant, for instance).
>It certainly was not our intention for the CMTS to stop counting 
>-received- service flow packets !!
>
>I suppose we could clarify that "classified" applies to outgoing flows, 
>and the incoming flows (to the CMTS) include those packets which were 
>received.

[milu]: Please do.  CM only MUST "classify" the upstream. CMTS only  MUST 
"classify" the downtream as RFI spec.  Both are outgoing flows.  The 
service flows  used for incoming traffic should have the incoming 
statistics, too.


>This opens a can of worms concerning errors in the receive process. Does 
>anyone feel docsQosServiceFlowPackets has to explicitly specify whether a 
>CMTS counts upstream packets received with errors like checksum errors? 
>[IMO it shouldn't]   Or should it count grants given to a particular 
>service flow even if the CM didn't send a packet in that grant? [IMO, it 
>shouldn't]
>Both of these cases involve error troubleshooting that is, IMO, beyond the 
>scope of the docsQosMib.

[milu]: I totally agree with you to count the packet pdu frames received 
actually and exclude errored frames for the incoming traffic.
By the way, I think the word "classified" also has much-discussed 
complexity compared to the word "transmit" (or  "sent") and the word 
'classified' is probably not good for incoming traffic.

For example:
docsQosServiceFlowPkts

The following 3 paragraph to me is the same thing -- packets sent on 
service flow X are counted only on the service flow X's counters.

                 "Particularly for UGS flows, packets sent on the
                     primary service flow in violation of the UGS grant
                     size should be counted only on the primary service
                     flow's counters."

                     [milu]: I interpret it as packets "sent" on the 
primary service flow are counted only on the primary service flow's 
counters.

                     "Unclassified upstream user data packets (i.e. non
                     MAC-management) forwarded to the default upstream
                     service flow should be incremented for this object."

                      [milu]: I interpret it as "outgoing unclassified 
packets sent to default service flow should be counted only on the default 
service flow's counters." though it seems only applicable to CM in the 
original description.

                     This object does include packets counted by
                     docsQosServiceFlowPolicedDelayPkts, but does not include
                     packets counted by docsQosServiceFlowPolicedDropPkts.

                      [milu]: I interpret it as "delayed packets should be 
counted when the packets are sent actually." and "drop packets are not 
sent, so they are not counted here." "excessive delayed packets which are 
dropped eventually for any reason are not counted here because they are not 
sent."

  These are my personal interpretation and I don't meant the object 
description should use them. I might simplify things too much and miss some 
thing. Please let me know.

   Thanks a lot !
   Minnie

>-mike
>
>
>
>-----Original Message-----
>From: Minnie Lu [mailto:milu@cisco.com]
>Sent: Friday, June 06, 2003 2:12 PM
>To: Patrick Michael-LZZ007
>Cc: 'Minnie Lu'; Murwin William-LWM008; Docsis-Oss (E-mail) (E-mail); 
>IPCDN (E-mail) (E-mail)
>Subject: RE: Descriptions for docsQosSer
>
>
>Hi, Patrick,
>
>   Thanks for your reply.  Then please help me to understand why "sole
>exception" only apply to CM ?
>
>RFIv1.1-I09-020830, Section 8.1.6, "The CMTS MUST classify downstream
>traffic to Active Downstream Service Flows.". Does it mean that with the
>word "classified", for CMTS which does not classify the upstream traffic,
>those counters with "classified" word will also allow to report 0 for CMTS ?
>
>As I know, some customers could use the service flow counters for usage
>based billing.  SAMIS ECN OSS-N-02197 reports the service flows counters
>for downtreams and upstreams.  Then how could these service flows counters
>be used for usage billing from CMTS's point of view  ?
>
>Another concern is the backward capability. The
>draft-ietf-ipcdn-qos-mib-04.txt which is now used in the field for most of
>vendors' CMTS does not have the word 'classified'. If I remembered right,
>there will be NO NEW ECR for OSSIv1.1 spec. That is, the DOCS-QOS-MIB
>version is still draft-ietf-ipcdn-qos-mib-04.txt in OSSIv1.1 spec..
>
>draft-ietf-ipcdn-qos-mib-04.txt :
>docsQosServiceFlowPkts
>   "The number of packet counted on this service flow." 
> docsQosServiceFlowOctets
>    "The number of octets counted on this service flow
>                      after payload header suppression."
>
>Thanks a lot for your help again !
>Minnie
>
>At 11:00 AM 6/6/2003 -0400, Patrick Michael-LZZ007 wrote:
> >Minnie,
> >
> >I used the word "classified" deliberately because the DOCSIS 1.1
> >architecture defines the set of packets onto a flow based on a classifer:
> >"The basic model is that the Classifiers associate packets into exactly
> >one Service Flow" (RFIv1.1-IO5 section 8.1.6).  I certainly do NOT want to
> >use the word "transmitted" or "received", both of which introduce the
> >much-discussed complexity regarding whether or not a packet is transmitted.
> >
> >The description explictly handles the sole exception, where CMs are not
> >required to classify received packets.
> >
> >Are you aware of any instance where an implementor or tester
> >misinterpreted the description wording?
> >
> >-mike
> >
> >
> >-----Original Message-----
> >From: Minnie Lu [mailto:milu@cisco.com]
> >Sent: Thursday, June 05, 2003 7:10 PM
> >To: Murwin William-LWM008
> >Cc: Docsis-Oss (E-mail) (E-mail); IPCDN (E-mail) (E-mail); Murwin
> >William-LWM008; Patrick Michael-LZZ007
> >Subject: Re: Descriptions for docsQosSer
> >
> >
> >Hi,
> >
> >Probably I miss something.  I don't know why the word "classified" was
> >added into these counters.  These counters might be used for usage
> >billing purpose.  With the word "classified", CMTS will only MUST
> >report downtream service flows traffic statistics because CMTS only
> >MUST classify downtream traffic to active downstream service flows.
> >Any reason could these counters not be used for the traffic sent or
> >received via the service flow ?
> >
> >Thanks !
> >Minnie
> >
> >At 08:16 PM 6/4/2003 -0400, Murwin William-LWM008 wrote:
> > >When draft-ietf-ipcdn-qos-mib-08.txt was submitted to the mailling
> > >list there had been a disscusion about the descriptions for the
> > >objects: docsQosServiceFlowPkts docsQosServiceFlowOctets
> > >docsQosServiceFlowPolicedDropPkts
> > >docsQosServiceFlowPolicedDelayPkts
> > >
> > >Please review the current descriptions from
> > >draft-ietf-ipcdn-qos-mib-08.txt  :
> > >
> > >docsQosServiceFlowPkts OBJECT-TYPE
> > >     SYNTAX          Counter64
> > >     MAX-ACCESS      read-only
> > >     STATUS          current
> > >     DESCRIPTION    "The number of Packet Data PDUs classified to this
> > >                     service flow and forwarded beyond a service flow
> > >                     maximum rate policing function.
> > >                     This object does not count MAC-specific
> > >                     management messages.
> > >                     CMs not classifying downstream packets may report
> > >                     this object's value as 0.
> > >
> > >                     Particularly for UGS flows, packets sent on the
> > >                     primary service flow in violation of the UGS grant
> > >                     size should be counted only on the primary service
> > >                     flow's counters.
> > >
> > >                     Unclassified upstream user data packets (i.e. non
> > >                     MAC-management) forwarded to the default upstream
> > >                     service flow should be incremented for this
> > > object.
> > >
> > >                     This object does include packets counted by
> > >                     docsQosServiceFlowPolicedDelayPkts, but does not
> > include
> > >                     packets counted by
> > > docsQosServiceFlowPolicedDropPkts.
> > >
> > >                     This counter's last discontinuity is the
> > >                     ifCounterDiscontinuityTime for same ifIndex that
> > >                     indexes this object."
> > >     ::= { docsQosServiceFlowStatsEntry 1 }
> > >
> > >docsQosServiceFlowOctets OBJECT-TYPE
> > >     SYNTAX          Counter64
> > >     MAX-ACCESS      read-only
> > >     STATUS          current
> > >     DESCRIPTION    "The number of octets from the byte after the MAC
> > >                     header HCS to the end of the CRC for all packets
> > counted
> > >                     in the docsQosServiceFlowPkts object for this row.
> > >                     Note that this counts the octets after payload header
> > >                     suppression has been applied. CMs not classifying 
> to a
> > >                     downstream service flow may report this object's
> > >                     value as 0 for that flow.
> > >
> > >                     This counter's last discontinuity is the
> > >                     ifCounterDiscontinuityTime for same ifIndex that
> > >                     indexes this object."
> > >     ::= { docsQosServiceFlowStatsEntry 2 }
> > >
> > >docsQosServiceFlowPolicedDropPkts OBJECT-TYPE
> > >     SYNTAX          Counter32
> > >     MAX-ACCESS      read-only
> > >     STATUS          current
> > >     DESCRIPTION    "The number of Packet Data PDUs classified to this
> > >                     service flow dropped due to:
> > >                        (1) implementation-dependent excessive delay while
> > >                            enforcing the Maximum Sustained Traffic 
> Rate; or
> > >                        (2) UGS packets dropped due to exceeding the
> > >                            Unsolicited Grant Size with a
> > >                            Request/Transmission policy that requires such
> > >                            packets to be dropped.
> > >                     Classified packets dropped due to other reasons 
> must be
> > >                     counted in ifOutDiscards for interface of this
> > >                     service flow.
> > >
> > >                     This counter's last discontinuity is the
> > >                     ifCounterDiscontinuityTime for same ifIndex that
> > >                     indexes this object."
> > >     ::= { docsQosServiceFlowStatsEntry 6 }
> > >
> > >docsQosServiceFlowPolicedDelayPkts OBJECT-TYPE
> > >     SYNTAX          Counter32
> > >     MAX-ACCESS      read-only
> > >     STATUS          current
> > >     DESCRIPTION    "This object counts only packets delayed in order to
> > >                     maintain the Maximum Sustained Traffic Rate.
> > >This
> > object
> > >                     will always report a value of 0 for UGS flows
> > because the
> > >                     Maximum Sustained Traffic Rate does not apply.
> > >
> > >                     This counter's last discontinuity is the
> > >                     ifCounterDiscontinuityTime for same ifIndex that
> > >                     indexes this object."
> > >     ::= { docsQosServiceFlowStatsEntry 7 }
> > >
> > >
> > >We do not want to have the same discussion about the description of
> > >these objects when we send our for comments version 9 of the
> > >DOCS-QOS-MIB. If there are any more comments please send then as soon
> > >as possible. Thank you again for reviewing this.
> > >
> > >Sincerely,
> > >Mike Patrick & Will Murwin

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



From mailnull@www1.ietf.org  Mon Jun  9 12:53:41 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12205
	for <ipcdn-archive@odin.ietf.org>; Mon, 9 Jun 2003 12:53:41 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h59GrGL17027
	for ipcdn-archive@odin.ietf.org; Mon, 9 Jun 2003 12:53:16 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59GrFB17016;
	Mon, 9 Jun 2003 12:53:15 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59GpEB16923
	for <ipcdn@optimus.ietf.org>; Mon, 9 Jun 2003 12:51:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12026
	for <ipcdn@ietf.org>; Mon, 9 Jun 2003 12:51:09 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PPpW-00058V-00
	for ipcdn@ietf.org; Mon, 09 Jun 2003 12:49:10 -0400
Received: from [66.63.144.170] (helo=mail.correlant.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PPpV-00058K-00
	for ipcdn@ietf.org; Mon, 09 Jun 2003 12:49:09 -0400
Received: from kfriedman (67.82.218.209.transedge.com [209.218.82.67])
	by mail.correlant.com (Postfix) with SMTP
	id D17BCBC11D; Mon,  9 Jun 2003 09:51:06 -0700 (PDT)
From: "Kirk Friedman" <kfriedman@correlant.com>
To: <Wilson.Sawyer@arrisi.com>, <ipcdn@ietf.org>
Cc: <bwijnen@lucent.com>
Subject: RE: [ipcdn] draft submitted: subscriber management MIB -11
Date: Mon, 9 Jun 2003 09:50:37 -0700
Message-ID: <001001c32ea7$417e05a0$4352dad1@correlant.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0)
In-Reply-To: <OFEA583539.5346742F-ON85256D35.0041DAB4@arrisi.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: ipcdn-admin@ietf.org
Errors-To: ipcdn-admin@ietf.org
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi Wilson,

     Sorry this took so long to put together.  I have real reservations
about this change.  While it does indeed remove some MIB redundancy and
allow for some future capabilities, it also complicates matters quite a bit
during implementation and for understanding how the QoS and Subscriber
Management MIBs work together on CMTS and CMs.

1) There is already redundancy between the DOCSIS 1.1 QoS MIB (currently
draft-ietf-ipcdn-qos-mib-08.txt) and the subscriber MIB in the packet
matching criteria.  In some sense that simplifies both implementation and
understanding how the two MIBs operate together.

2) It is confusing that classifiers for a DOCSIS system are no longer
uniquely defined.  There are DOCSIS packet classifiers for service flows and
now classifiers associated with RFC3289 and the Subscriber Mgmt MIB.

3) The diffServDataPathEntry is indexed by ifIndex (which is fine) and
ifDirection.  It is somewhat based on the premise that an interface is
bi-directional.  The RFI interfaces are uni-directional.  So there needs to
be a description that indicates which direction applies for which interface
type for which device (CMTS/CM).  See last item.

4) In order to follow the compliancies of RFC3289, groups that are not
called out in the subscriber MIB are now mandatory.  The
diffServMIBTBParamGroup must be implemented because "This group is mandatory
for devices that implement token-bucket metering functions."  The
diffServMIBMeterGroup is "... is mandatory for devices that implement
metering functions."  Both the CMTS and CM do this.

5) The requirements to include row pointers to diffServQEntry is also
confusing, even if zeroDotZero is applied in most cases.  Again, there is
alot of overlap with QoS MIB.

6) Two classifiers must be used if it is desired to match only TCP/UDP
packets.  This was one of the shortcuts in the previous version of the
Subscriber Mgmt MIB since this is the majority of the traffic on the
Internet.

7) One way out of this confusion would be to specify all the various values
for the objects of this MIB for CM and CMTS.  This would be like the
relationship between the ifTable and RFC2670 called Appendix B of the DOCSIS
OSSI specification.  However, my understanding is that for DOCSIS 1.1 this
specification is going to be wrapped up soon.

     RFC3289 is used to provide a solution for both filtering and QoS.  But
requiring part of its implementation seems to me to open up a whole new can
of worms about implementation and precedence with the DOCSIS 1.1 QoS MIB.

Thanks,

Kirk Friedman
Correlant Communications
15110 Avenue Of Science
San Diego, CA., 92128




-----Original Message-----
From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of
Wilson.Sawyer@arrisi.com
Sent: Thursday, May 29, 2003 5:22 AM
To: ipcdn@ietf.org
Cc: bwijnen@lucent.com
Subject: [ipcdn] draft submitted: subscriber management MIB -11


I have submitted a greatly-revised version of the subscriber management mib
(draft-ietf-ipcdn-subscriber-mib-11.txt), making use of the Diffserv MIB
(RFC3289) as outlined in my April 28 email. The good news is that the
document is now shorter, since much of filtering is now deferred to
existing facilities in RFC3289. This will be a significant implementation
change for CMTS vendors and operators.

The reason for the change is that the overlap with RFC3289 was so great
that I did not believe that the document would pass the broader review
needed for RFC approval. We gain by re-using the work that has already gone
into 3289. It also gives us the ability, although not mandated, to
integrate with other facilities within 3289.

I urge CMTS vendors and operators, in particular, to review this carefully
and make suggestions. As always, this document is the product of the
working group and only proceeds with working group consensus.

Respectfully submitted,
Wilson Sawyer
ARRIS


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

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



From mailnull@www1.ietf.org  Mon Jun  9 14:18:37 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15172
	for <ipcdn-archive@odin.ietf.org>; Mon, 9 Jun 2003 14:18:37 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h59IIC424397
	for ipcdn-archive@odin.ietf.org; Mon, 9 Jun 2003 14:18:12 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59II9B24382;
	Mon, 9 Jun 2003 14:18:09 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59IHDB24292
	for <ipcdn@optimus.ietf.org>; Mon, 9 Jun 2003 14:17:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15128
	for <ipcdn@ietf.org>; Mon, 9 Jun 2003 14:17:07 -0400 (EDT)
From: Wilson.Sawyer@arrisi.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PRAh-0005wR-00
	for ipcdn@ietf.org; Mon, 09 Jun 2003 14:15:07 -0400
Received: from pluto.arrisi.com ([63.82.122.6])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PRAg-0005wO-00
	for ipcdn@ietf.org; Mon, 09 Jun 2003 14:15:06 -0400
Received: from titan ([10.24.249.1])
          by pluto.arrisi.com (Lotus Domino Release 5.0.12)
          with ESMTP id 2003060914221536:98150 ;
          Mon, 9 Jun 2003 14:22:15 -0400 
Subject: RE: [ipcdn] draft submitted: subscriber management MIB -11
To: "Kirk Friedman" <kfriedman@correlant.com>
Cc: bwijnen@lucent.com, ipcdn@ietf.org
X-Mailer: Lotus Notes Release 5.0.9  November 16, 2001
Message-ID: <OFA2BF9675.958994DA-ON85256D40.005DCD6E@arrisi.com>
Date: Mon, 9 Jun 2003 14:17:08 -0400
MIME-Version: 1.0
X-MIMETrack: Serialize by Router on Titan/Arris(Release 5.0.12  |February 13, 2003) at
 06/09/2003 02:17:06 PM,
	Itemize by SMTP Server on Pluto/Antec(Release 5.0.12  |February 13, 2003) at
 06/09/2003 02:22:15 PM,
	Serialize by Router on Pluto/Antec(Release 5.0.12  |February 13, 2003) at
 06/09/2003 02:22:17 PM,
	Serialize complete at 06/09/2003 02:22:17 PM
Content-type: text/plain; charset=us-ascii
Sender: ipcdn-admin@ietf.org
Errors-To: ipcdn-admin@ietf.org
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=subscribe>


Kirk - thanks for your comments. My mailer doesn't do a good job of
inlining responses, so I'll refer to your numbering:

1. Agreed on the redundancy on packet matching, although the two mechanisms
and their matching criteria differ. How does this affect the decision to
use RFC3289, though?

2. Yes, we have Docsis classifiers, and now we have
RFC3289-filter-classifiers-as-used-for-subscriber-management. But the 3289
classifiers are doing what the old submgt Filter table was doing. So is the
confusion just in the word "classifier", or am I missing something else?

3. The ifIndex should be the Docsis MAC interface, which is a bidirectional
interface. Does this need to be clarified in the i-d?

4. I don't think there's any mandate that we move any functionality
unrelated to subscriber management under the 3289 umbrella. So yes, we have
token buckets (for the QoS MIB), but they do not appear in the context of
RFC3289.

5. Thee is no need to support diffServQEntry at all. zeroDotZero, Count
Actions, and Drop Actions are all that is needed. (see below for your
broader comment about the QoS MIB).

6. In recent versions of the subscriber management MIB, two classifiers
would have been needed to match the same port numbers in TCP and UDP, so no
savings there. Here's the relevant text from the -10 draft:

   docsSubMgtPktFilterUlp OBJECT-TYPE
       SYNTAX      Integer32 (0..256)
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "Upper level protocol to match.  If this value is 256,
       matches ALL ULP values.  Otherwise, this matches the specific
       protocol value.  Note that if the packet ULP is either 6 (tcp) or
       17 (udp), then docsSubMgtPktTcpUdpFilterTable must also be
       consulted (if its entry exists) to see if this entry matches.
       If this value is neither tcp(6) nor udp(17), then that
       table is not consulted."

7. There are no values for the CM - this is a CMTS-only MIB. We *do* need a
section of the OSSI spec which calls out the minimal requirements for
implementation of RFC3289 on CMTSs. Do we need anything beyond that? I
don't think it lines up quite as cleanly as, for example, ifTable, because
the expressive power of RFC3289 lies in the flexibility of its structure.

(re your unnumbered summary):

On the most literal level, there is no reason why this change should cause
any confusion with the QoS MIB. Subscriber Management has always been
independent of the QoS MIB, and the choice to adopt RFC3289 representation
for packet-filtering  criteria doesn't change that. The QoS MIB will
continue to use its own criteria and will continue to be applied
independently of the representation of subscriber management filtering.

On a broader broader MIB-representational level,  I'd agree that there may
be work ahead to coordinate with the QoS MIB.  The QoS MIB is also
evolving, and may one day also choose to adopt conventions from RFC3289.
If so, the 3289 framework will need to convey the relationship between the
two processes. I believe that it has the expressive power to do so.  But,
for now, I'd be very reluctant to push for that level of unity with
something as necessarily complex as the QoS MIB. I'd rather make progress
independently for now.

As for implementation, keep in mind that even if QoS does go this way,
there is no requirement that the full arbitrary expressiveness of 3289 be
implemented - classifying the same packet through 3 meters, two merge
ramps, a toll booth and two truck stops. We can use 3289 as a tool to
express the problems we have - not to impose arbitrarily difficult queuing
regimes.

Regards,
Wilson Sawyer



                                                                                                          
                      "Kirk Friedman"                                                                     
                      <kfriedman@correl        To:       <Wilson.Sawyer@arrisi.com>, <ipcdn@ietf.org>     
                      ant.com>                 cc:       <bwijnen@lucent.com>                             
                                               Subject:  RE: [ipcdn] draft submitted: subscriber          
                      06/09/03 12:50 PM         management MIB -11                                        
                                                                                                          
                                                                                                          




Hi Wilson,

     Sorry this took so long to put together.  I have real reservations
about this change.  While it does indeed remove some MIB redundancy and
allow for some future capabilities, it also complicates matters quite a bit
during implementation and for understanding how the QoS and Subscriber
Management MIBs work together on CMTS and CMs.

1) There is already redundancy between the DOCSIS 1.1 QoS MIB (currently
draft-ietf-ipcdn-qos-mib-08.txt) and the subscriber MIB in the packet
matching criteria.  In some sense that simplifies both implementation and
understanding how the two MIBs operate together.

2) It is confusing that classifiers for a DOCSIS system are no longer
uniquely defined.  There are DOCSIS packet classifiers for service flows
and
now classifiers associated with RFC3289 and the Subscriber Mgmt MIB.

3) The diffServDataPathEntry is indexed by ifIndex (which is fine) and
ifDirection.  It is somewhat based on the premise that an interface is
bi-directional.  The RFI interfaces are uni-directional.  So there needs to
be a description that indicates which direction applies for which interface
type for which device (CMTS/CM).  See last item.

4) In order to follow the compliancies of RFC3289, groups that are not
called out in the subscriber MIB are now mandatory.  The
diffServMIBTBParamGroup must be implemented because "This group is
mandatory
for devices that implement token-bucket metering functions."  The
diffServMIBMeterGroup is "... is mandatory for devices that implement
metering functions."  Both the CMTS and CM do this.

5) The requirements to include row pointers to diffServQEntry is also
confusing, even if zeroDotZero is applied in most cases.  Again, there is
alot of overlap with QoS MIB.

6) Two classifiers must be used if it is desired to match only TCP/UDP
packets.  This was one of the shortcuts in the previous version of the
Subscriber Mgmt MIB since this is the majority of the traffic on the
Internet.

7) One way out of this confusion would be to specify all the various values
for the objects of this MIB for CM and CMTS.  This would be like the
relationship between the ifTable and RFC2670 called Appendix B of the
DOCSIS
OSSI specification.  However, my understanding is that for DOCSIS 1.1 this
specification is going to be wrapped up soon.

     RFC3289 is used to provide a solution for both filtering and QoS.  But
requiring part of its implementation seems to me to open up a whole new can
of worms about implementation and precedence with the DOCSIS 1.1 QoS MIB.

Thanks,

Kirk Friedman
Correlant Communications
15110 Avenue Of Science
San Diego, CA., 92128




-----Original Message-----
From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of
Wilson.Sawyer@arrisi.com
Sent: Thursday, May 29, 2003 5:22 AM
To: ipcdn@ietf.org
Cc: bwijnen@lucent.com
Subject: [ipcdn] draft submitted: subscriber management MIB -11


I have submitted a greatly-revised version of the subscriber management mib
(draft-ietf-ipcdn-subscriber-mib-11.txt), making use of the Diffserv MIB
(RFC3289) as outlined in my April 28 email. The good news is that the
document is now shorter, since much of filtering is now deferred to
existing facilities in RFC3289. This will be a significant implementation
change for CMTS vendors and operators.

The reason for the change is that the overlap with RFC3289 was so great
that I did not believe that the document would pass the broader review
needed for RFC approval. We gain by re-using the work that has already gone
into 3289. It also gives us the ability, although not mandated, to
integrate with other facilities within 3289.

I urge CMTS vendors and operators, in particular, to review this carefully
and make suggestions. As always, this document is the product of the
working group and only proceeds with working group consensus.

Respectfully submitted,
Wilson Sawyer
ARRIS


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






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



From mailnull@www1.ietf.org  Wed Jun 11 12:15:25 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15829
	for <ipcdn-archive@odin.ietf.org>; Wed, 11 Jun 2003 12:15:25 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5BGEwn13066
	for ipcdn-archive@odin.ietf.org; Wed, 11 Jun 2003 12:14:58 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BGEjm13037;
	Wed, 11 Jun 2003 12:14:45 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BG0mm11046
	for <ipcdn@optimus.ietf.org>; Wed, 11 Jun 2003 12:00:48 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15252
	for <ipcdn@ietf.org>; Wed, 11 Jun 2003 12:00:45 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q7zm-0001Pm-00
	for ipcdn@ietf.org; Wed, 11 Jun 2003 11:58:42 -0400
Received: from [66.63.144.170] (helo=mail.correlant.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q7zg-0001PZ-00
	for ipcdn@ietf.org; Wed, 11 Jun 2003 11:58:39 -0400
Received: from kfriedman (67.82.218.209.transedge.com [209.218.82.67])
	by mail.correlant.com (Postfix) with SMTP
	id 968CEBC100; Wed, 11 Jun 2003 09:00:09 -0700 (PDT)
From: "Kirk Friedman" <kfriedman@correlant.com>
To: <Wilson.Sawyer@arrisi.com>
Cc: <bwijnen@lucent.com>, <ipcdn@ietf.org>
Subject: RE: [ipcdn] draft submitted: subscriber management MIB -11
Date: Wed, 11 Jun 2003 08:59:55 -0700
Message-ID: <000501c33032$812e5060$4352dad1@correlant.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <OFA2BF9675.958994DA-ON85256D40.005DCD6E@arrisi.com>
Content-Transfer-Encoding: 7bit
Sender: ipcdn-admin@ietf.org
Errors-To: ipcdn-admin@ietf.org
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi Wilson,

Thanks for the prompt reply.  Walking through your responses

1. I agree its not a major issue.  More of a implementation simplification.

2. RFC3289 does not refer to
filter-classifiers-used-for-subscriber-managemment.  Considering 3289 by
itself is using classifiers for filters and for QoS management.  There is
definitely cause for confusion between this and the QoS MIB without
careful explanation.

3. The ifIndex makes sense if only applied to the Docsis MAC interface.
This should be clarified.

4. The question is how RFC3289 is interpreted for use in a CMTS and what
constitutes compliance.  If this MIB is going to be used in DOCSIS 1.1
systems then an ECR should immediately be drafted the OSSI Spec "Detailed
MIB Requirements" so there is no confusion about what is and is not required
to be implemented.  Otherwise the confusion will snowball.

5. Agree, see 4.

6. Agreed.

7. Agreed since the ifIndex is only applicable to the MAC interface.

To re-iterate comment 4.  If I take a look at RFC3289 without any other
documentation, then there are MIB entries other than the classifiers that
could be said to apply to the CMTS.  Section 3 "Management Information Bases
(MIBS)" should also be ECRd to change the requirements for the subscriber
mgmt mib and add a section for RFC 3289.  If not, there will be a large
disconnect between 1.1 systems and 2.0 systems that will make MSO management
that much more difficult.

Thanks again,

Kirk Friedman

-----Original Message-----
From: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com]
Sent: Monday, June 09, 2003 11:17 AM
To: Kirk Friedman
Cc: bwijnen@lucent.com; ipcdn@ietf.org
Subject: RE: [ipcdn] draft submitted: subscriber management MIB -11



Kirk - thanks for your comments. My mailer doesn't do a good job of
inlining responses, so I'll refer to your numbering:

1. Agreed on the redundancy on packet matching, although the two mechanisms
and their matching criteria differ. How does this affect the decision to
use RFC3289, though?

2. Yes, we have Docsis classifiers, and now we have
RFC3289-filter-classifiers-as-used-for-subscriber-management. But the 3289
classifiers are doing what the old submgt Filter table was doing. So is the
confusion just in the word "classifier", or am I missing something else?

3. The ifIndex should be the Docsis MAC interface, which is a bidirectional
interface. Does this need to be clarified in the i-d?

4. I don't think there's any mandate that we move any functionality
unrelated to subscriber management under the 3289 umbrella. So yes, we have
token buckets (for the QoS MIB), but they do not appear in the context of
RFC3289.

5. Thee is no need to support diffServQEntry at all. zeroDotZero, Count
Actions, and Drop Actions are all that is needed. (see below for your
broader comment about the QoS MIB).

6. In recent versions of the subscriber management MIB, two classifiers
would have been needed to match the same port numbers in TCP and UDP, so no
savings there. Here's the relevant text from the -10 draft:

   docsSubMgtPktFilterUlp OBJECT-TYPE
       SYNTAX      Integer32 (0..256)
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "Upper level protocol to match.  If this value is 256,
       matches ALL ULP values.  Otherwise, this matches the specific
       protocol value.  Note that if the packet ULP is either 6 (tcp) or
       17 (udp), then docsSubMgtPktTcpUdpFilterTable must also be
       consulted (if its entry exists) to see if this entry matches.
       If this value is neither tcp(6) nor udp(17), then that
       table is not consulted."

7. There are no values for the CM - this is a CMTS-only MIB. We *do* need a
section of the OSSI spec which calls out the minimal requirements for
implementation of RFC3289 on CMTSs. Do we need anything beyond that? I
don't think it lines up quite as cleanly as, for example, ifTable, because
the expressive power of RFC3289 lies in the flexibility of its structure.

(re your unnumbered summary):

On the most literal level, there is no reason why this change should cause
any confusion with the QoS MIB. Subscriber Management has always been
independent of the QoS MIB, and the choice to adopt RFC3289 representation
for packet-filtering  criteria doesn't change that. The QoS MIB will
continue to use its own criteria and will continue to be applied
independently of the representation of subscriber management filtering.

On a broader broader MIB-representational level,  I'd agree that there may
be work ahead to coordinate with the QoS MIB.  The QoS MIB is also
evolving, and may one day also choose to adopt conventions from RFC3289.
If so, the 3289 framework will need to convey the relationship between the
two processes. I believe that it has the expressive power to do so.  But,
for now, I'd be very reluctant to push for that level of unity with
something as necessarily complex as the QoS MIB. I'd rather make progress
independently for now.

As for implementation, keep in mind that even if QoS does go this way,
there is no requirement that the full arbitrary expressiveness of 3289 be
implemented - classifying the same packet through 3 meters, two merge
ramps, a toll booth and two truck stops. We can use 3289 as a tool to
express the problems we have - not to impose arbitrarily difficult queuing
regimes.

Regards,
Wilson Sawyer




                      "Kirk Friedman"
                      <kfriedman@correl        To:
<Wilson.Sawyer@arrisi.com>, <ipcdn@ietf.org>
                      ant.com>                 cc:
<bwijnen@lucent.com>
                                               Subject:  RE: [ipcdn] draft
submitted: subscriber
                      06/09/03 12:50 PM         management MIB -11






Hi Wilson,

     Sorry this took so long to put together.  I have real reservations
about this change.  While it does indeed remove some MIB redundancy and
allow for some future capabilities, it also complicates matters quite a bit
during implementation and for understanding how the QoS and Subscriber
Management MIBs work together on CMTS and CMs.

1) There is already redundancy between the DOCSIS 1.1 QoS MIB (currently
draft-ietf-ipcdn-qos-mib-08.txt) and the subscriber MIB in the packet
matching criteria.  In some sense that simplifies both implementation and
understanding how the two MIBs operate together.

2) It is confusing that classifiers for a DOCSIS system are no longer
uniquely defined.  There are DOCSIS packet classifiers for service flows
and
now classifiers associated with RFC3289 and the Subscriber Mgmt MIB.

3) The diffServDataPathEntry is indexed by ifIndex (which is fine) and
ifDirection.  It is somewhat based on the premise that an interface is
bi-directional.  The RFI interfaces are uni-directional.  So there needs to
be a description that indicates which direction applies for which interface
type for which device (CMTS/CM).  See last item.

4) In order to follow the compliancies of RFC3289, groups that are not
called out in the subscriber MIB are now mandatory.  The
diffServMIBTBParamGroup must be implemented because "This group is
mandatory
for devices that implement token-bucket metering functions."  The
diffServMIBMeterGroup is "... is mandatory for devices that implement
metering functions."  Both the CMTS and CM do this.

5) The requirements to include row pointers to diffServQEntry is also
confusing, even if zeroDotZero is applied in most cases.  Again, there is
alot of overlap with QoS MIB.

6) Two classifiers must be used if it is desired to match only TCP/UDP
packets.  This was one of the shortcuts in the previous version of the
Subscriber Mgmt MIB since this is the majority of the traffic on the
Internet.

7) One way out of this confusion would be to specify all the various values
for the objects of this MIB for CM and CMTS.  This would be like the
relationship between the ifTable and RFC2670 called Appendix B of the
DOCSIS
OSSI specification.  However, my understanding is that for DOCSIS 1.1 this
specification is going to be wrapped up soon.

     RFC3289 is used to provide a solution for both filtering and QoS.  But
requiring part of its implementation seems to me to open up a whole new can
of worms about implementation and precedence with the DOCSIS 1.1 QoS MIB.

Thanks,

Kirk Friedman
Correlant Communications
15110 Avenue Of Science
San Diego, CA., 92128




-----Original Message-----
From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of
Wilson.Sawyer@arrisi.com
Sent: Thursday, May 29, 2003 5:22 AM
To: ipcdn@ietf.org
Cc: bwijnen@lucent.com
Subject: [ipcdn] draft submitted: subscriber management MIB -11


I have submitted a greatly-revised version of the subscriber management mib
(draft-ietf-ipcdn-subscriber-mib-11.txt), making use of the Diffserv MIB
(RFC3289) as outlined in my April 28 email. The good news is that the
document is now shorter, since much of filtering is now deferred to
existing facilities in RFC3289. This will be a significant implementation
change for CMTS vendors and operators.

The reason for the change is that the overlap with RFC3289 was so great
that I did not believe that the document would pass the broader review
needed for RFC approval. We gain by re-using the work that has already gone
into 3289. It also gives us the ability, although not mandated, to
integrate with other facilities within 3289.

I urge CMTS vendors and operators, in particular, to review this carefully
and make suggestions. As always, this document is the product of the
working group and only proceeds with working group consensus.

Respectfully submitted,
Wilson Sawyer
ARRIS


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






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



From mailnull@www1.ietf.org  Wed Jun 11 12:46:52 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16833
	for <ipcdn-archive@odin.ietf.org>; Wed, 11 Jun 2003 12:46:52 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5BGkQ615733
	for ipcdn-archive@odin.ietf.org; Wed, 11 Jun 2003 12:46:26 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BGkIm15725;
	Wed, 11 Jun 2003 12:46:18 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BGiWm15569
	for <ipcdn@optimus.ietf.org>; Wed, 11 Jun 2003 12:44:32 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16735
	for <ipcdn@ietf.org>; Wed, 11 Jun 2003 12:44:28 -0400 (EDT)
From: Wilson.Sawyer@arrisi.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q8g5-0001hr-00
	for ipcdn@ietf.org; Wed, 11 Jun 2003 12:42:25 -0400
Received: from pluto.arrisi.com ([63.82.122.6])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q8g3-0001ho-00
	for ipcdn@ietf.org; Wed, 11 Jun 2003 12:42:24 -0400
Received: from titan ([10.24.249.1])
          by pluto.arrisi.com (Lotus Domino Release 5.0.12)
          with ESMTP id 2003061112493581:109794 ;
          Wed, 11 Jun 2003 12:49:35 -0400 
Subject: RE: [ipcdn] draft submitted: subscriber management MIB -11
To: "Kirk Friedman" <kfriedman@correlant.com>
Cc: bwijnen@lucent.com, ipcdn@ietf.org
X-Mailer: Lotus Notes Release 5.0.9  November 16, 2001
Message-ID: <OF33676E1F.CD97922E-ON85256D42.005B2D80@arrisi.com>
Date: Wed, 11 Jun 2003 12:44:23 -0400
MIME-Version: 1.0
X-MIMETrack: Serialize by Router on Titan/Arris(Release 5.0.12  |February 13, 2003) at
 06/11/2003 12:44:24 PM,
	Itemize by SMTP Server on Pluto/Antec(Release 5.0.12  |February 13, 2003) at
 06/11/2003 12:49:36 PM,
	Serialize by Router on Pluto/Antec(Release 5.0.12  |February 13, 2003) at
 06/11/2003 12:49:40 PM,
	Serialize complete at 06/11/2003 12:49:40 PM
Content-type: text/plain; charset=us-ascii
Sender: ipcdn-admin@ietf.org
Errors-To: ipcdn-admin@ietf.org
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=subscribe>


Kirk - Agreed that the Docsis OSSI Spec needs new language to spec out CMTS
compliance w.r.t.  RFC3289. For the most part, I think that language more
properly belongs in the OSSI spec than in the internet draft.  But I'm open
to suggestions.

Keep in mind that there's a necessary lag in the publication of the OSSI
Spec: It can't mandate compliance with the subscriber management
internet-draft until the MIB is assigned a root - and that won't happen
until publication as an RFC.

Regards,
Wilson



                                                                                                                                             
                      "Kirk Friedman"                                                                                                        
                      <kfriedman@correl        To:       <Wilson.Sawyer@arrisi.com>                                                          
                      ant.com>                 cc:       <bwijnen@lucent.com>, <ipcdn@ietf.org>                                              
                                               Subject:  RE: [ipcdn] draft submitted: subscriber management MIB -11                          
                      06/11/03 11:59 AM                                                                                                      
                                                                                                                                             
                                                                                                                                             




Hi Wilson,

Thanks for the prompt reply.  Walking through your responses

1. I agree its not a major issue.  More of a implementation simplification.

2. RFC3289 does not refer to
filter-classifiers-used-for-subscriber-managemment.  Considering 3289 by
itself is using classifiers for filters and for QoS management.  There is
definitely cause for confusion between this and the QoS MIB without
careful explanation.

3. The ifIndex makes sense if only applied to the Docsis MAC interface.
This should be clarified.

4. The question is how RFC3289 is interpreted for use in a CMTS and what
constitutes compliance.  If this MIB is going to be used in DOCSIS 1.1
systems then an ECR should immediately be drafted the OSSI Spec "Detailed
MIB Requirements" so there is no confusion about what is and is not
required
to be implemented.  Otherwise the confusion will snowball.

5. Agree, see 4.

6. Agreed.

7. Agreed since the ifIndex is only applicable to the MAC interface.

To re-iterate comment 4.  If I take a look at RFC3289 without any other
documentation, then there are MIB entries other than the classifiers that
could be said to apply to the CMTS.  Section 3 "Management Information
Bases
(MIBS)" should also be ECRd to change the requirements for the subscriber
mgmt mib and add a section for RFC 3289.  If not, there will be a large
disconnect between 1.1 systems and 2.0 systems that will make MSO
management
that much more difficult.

Thanks again,

Kirk Friedman

-----Original Message-----
From: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com]
Sent: Monday, June 09, 2003 11:17 AM
To: Kirk Friedman
Cc: bwijnen@lucent.com; ipcdn@ietf.org
Subject: RE: [ipcdn] draft submitted: subscriber management MIB -11



Kirk - thanks for your comments. My mailer doesn't do a good job of
inlining responses, so I'll refer to your numbering:

1. Agreed on the redundancy on packet matching, although the two mechanisms
and their matching criteria differ. How does this affect the decision to
use RFC3289, though?

2. Yes, we have Docsis classifiers, and now we have
RFC3289-filter-classifiers-as-used-for-subscriber-management. But the 3289
classifiers are doing what the old submgt Filter table was doing. So is the
confusion just in the word "classifier", or am I missing something else?

3. The ifIndex should be the Docsis MAC interface, which is a bidirectional
interface. Does this need to be clarified in the i-d?

4. I don't think there's any mandate that we move any functionality
unrelated to subscriber management under the 3289 umbrella. So yes, we have
token buckets (for the QoS MIB), but they do not appear in the context of
RFC3289.

5. Thee is no need to support diffServQEntry at all. zeroDotZero, Count
Actions, and Drop Actions are all that is needed. (see below for your
broader comment about the QoS MIB).

6. In recent versions of the subscriber management MIB, two classifiers
would have been needed to match the same port numbers in TCP and UDP, so no
savings there. Here's the relevant text from the -10 draft:

   docsSubMgtPktFilterUlp OBJECT-TYPE
       SYNTAX      Integer32 (0..256)
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "Upper level protocol to match.  If this value is 256,
       matches ALL ULP values.  Otherwise, this matches the specific
       protocol value.  Note that if the packet ULP is either 6 (tcp) or
       17 (udp), then docsSubMgtPktTcpUdpFilterTable must also be
       consulted (if its entry exists) to see if this entry matches.
       If this value is neither tcp(6) nor udp(17), then that
       table is not consulted."

7. There are no values for the CM - this is a CMTS-only MIB. We *do* need a
section of the OSSI spec which calls out the minimal requirements for
implementation of RFC3289 on CMTSs. Do we need anything beyond that? I
don't think it lines up quite as cleanly as, for example, ifTable, because
the expressive power of RFC3289 lies in the flexibility of its structure.

(re your unnumbered summary):

On the most literal level, there is no reason why this change should cause
any confusion with the QoS MIB. Subscriber Management has always been
independent of the QoS MIB, and the choice to adopt RFC3289 representation
for packet-filtering  criteria doesn't change that. The QoS MIB will
continue to use its own criteria and will continue to be applied
independently of the representation of subscriber management filtering.

On a broader broader MIB-representational level,  I'd agree that there may
be work ahead to coordinate with the QoS MIB.  The QoS MIB is also
evolving, and may one day also choose to adopt conventions from RFC3289.
If so, the 3289 framework will need to convey the relationship between the
two processes. I believe that it has the expressive power to do so.  But,
for now, I'd be very reluctant to push for that level of unity with
something as necessarily complex as the QoS MIB. I'd rather make progress
independently for now.

As for implementation, keep in mind that even if QoS does go this way,
there is no requirement that the full arbitrary expressiveness of 3289 be
implemented - classifying the same packet through 3 meters, two merge
ramps, a toll booth and two truck stops. We can use 3289 as a tool to
express the problems we have - not to impose arbitrarily difficult queuing
regimes.

Regards,
Wilson Sawyer




                      "Kirk Friedman"
                      <kfriedman@correl        To:
<Wilson.Sawyer@arrisi.com>, <ipcdn@ietf.org>
                      ant.com>                 cc:
<bwijnen@lucent.com>
                                               Subject:  RE: [ipcdn] draft
submitted: subscriber
                      06/09/03 12:50 PM         management MIB -11






Hi Wilson,

     Sorry this took so long to put together.  I have real reservations
about this change.  While it does indeed remove some MIB redundancy and
allow for some future capabilities, it also complicates matters quite a bit
during implementation and for understanding how the QoS and Subscriber
Management MIBs work together on CMTS and CMs.

1) There is already redundancy between the DOCSIS 1.1 QoS MIB (currently
draft-ietf-ipcdn-qos-mib-08.txt) and the subscriber MIB in the packet
matching criteria.  In some sense that simplifies both implementation and
understanding how the two MIBs operate together.

2) It is confusing that classifiers for a DOCSIS system are no longer
uniquely defined.  There are DOCSIS packet classifiers for service flows
and
now classifiers associated with RFC3289 and the Subscriber Mgmt MIB.

3) The diffServDataPathEntry is indexed by ifIndex (which is fine) and
ifDirection.  It is somewhat based on the premise that an interface is
bi-directional.  The RFI interfaces are uni-directional.  So there needs to
be a description that indicates which direction applies for which interface
type for which device (CMTS/CM).  See last item.

4) In order to follow the compliancies of RFC3289, groups that are not
called out in the subscriber MIB are now mandatory.  The
diffServMIBTBParamGroup must be implemented because "This group is
mandatory
for devices that implement token-bucket metering functions."  The
diffServMIBMeterGroup is "... is mandatory for devices that implement
metering functions."  Both the CMTS and CM do this.

5) The requirements to include row pointers to diffServQEntry is also
confusing, even if zeroDotZero is applied in most cases.  Again, there is
alot of overlap with QoS MIB.

6) Two classifiers must be used if it is desired to match only TCP/UDP
packets.  This was one of the shortcuts in the previous version of the
Subscriber Mgmt MIB since this is the majority of the traffic on the
Internet.

7) One way out of this confusion would be to specify all the various values
for the objects of this MIB for CM and CMTS.  This would be like the
relationship between the ifTable and RFC2670 called Appendix B of the
DOCSIS
OSSI specification.  However, my understanding is that for DOCSIS 1.1 this
specification is going to be wrapped up soon.

     RFC3289 is used to provide a solution for both filtering and QoS.  But
requiring part of its implementation seems to me to open up a whole new can
of worms about implementation and precedence with the DOCSIS 1.1 QoS MIB.

Thanks,

Kirk Friedman
Correlant Communications
15110 Avenue Of Science
San Diego, CA., 92128




-----Original Message-----
From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of
Wilson.Sawyer@arrisi.com
Sent: Thursday, May 29, 2003 5:22 AM
To: ipcdn@ietf.org
Cc: bwijnen@lucent.com
Subject: [ipcdn] draft submitted: subscriber management MIB -11


I have submitted a greatly-revised version of the subscriber management mib
(draft-ietf-ipcdn-subscriber-mib-11.txt), making use of the Diffserv MIB
(RFC3289) as outlined in my April 28 email. The good news is that the
document is now shorter, since much of filtering is now deferred to
existing facilities in RFC3289. This will be a significant implementation
change for CMTS vendors and operators.

The reason for the change is that the overlap with RFC3289 was so great
that I did not believe that the document would pass the broader review
needed for RFC approval. We gain by re-using the work that has already gone
into 3289. It also gives us the ability, although not mandated, to
integrate with other facilities within 3289.

I urge CMTS vendors and operators, in particular, to review this carefully
and make suggestions. As always, this document is the product of the
working group and only proceeds with working group consensus.

Respectfully submitted,
Wilson Sawyer
ARRIS


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











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



From mailnull@www1.ietf.org  Thu Jun 12 10:18:47 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13195
	for <ipcdn-archive@odin.ietf.org>; Thu, 12 Jun 2003 10:18:47 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5CEIK025829
	for ipcdn-archive@odin.ietf.org; Thu, 12 Jun 2003 10:18:20 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CDvEm23293;
	Thu, 12 Jun 2003 09:57:14 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CDrhm22966
	for <ipcdn@optimus.ietf.org>; Thu, 12 Jun 2003 09:53:43 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10379
	for <ipcdn@ietf.org>; Thu, 12 Jun 2003 09:53:40 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QSUI-0002Wh-00
	for ipcdn@ietf.org; Thu, 12 Jun 2003 09:51:34 -0400
Received: from coral.tci.com ([198.178.8.81] helo=saipal.tci.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QSUH-0002W3-00
	for ipcdn@ietf.org; Thu, 12 Jun 2003 09:51:33 -0400
Received: from entexchimc04.broadband.att.com (localhost [127.0.0.1])
	by saipal.tci.com (8.12.9/8.12.9) with ESMTP id h5CDr6ND002397;
	Thu, 12 Jun 2003 07:53:07 -0600 (MDT)
Received: by entexchimc04.broadband.att.com with Internet Mail Service (5.5.2653.19)
	id <MM0Z40HQ>; Thu, 12 Jun 2003 07:53:06 -0600
Message-ID: <6732623D2548D61193C90002A5C88DCC05663B7C@entmaexch02.broadband.att.com>
From: "Woundy, Richard" <Richard_Woundy@cable.comcast.com>
To: "IPCDN WG (E-mail)" <ipcdn@ietf.org>
Cc: "Jean-Francois Mule (E-mail)" <jf.mule@cablelabs.com>,
        "Woundy, Richard" <Richard_Woundy@cable.comcast.com>
Date: Thu, 12 Jun 2003 07:53:04 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [ipcdn] FW: To the attention of all WG Chairs
Sender: ipcdn-admin@ietf.org
Errors-To: ipcdn-admin@ietf.org
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=subscribe>

Folks,

I need to submit the list of the names of all IPCDN version -00.txt drafts
by Monday, June 16th, for processing prior to the Vienna IETF meeting.

I believe this applies in particular to the CableHome MIB internet-drafts,
which are currently named draft-jones-cable-<x>.txt, but ought to be renamed
draft-ietf-ipcdn-<y>-00.txt.

-- Rich

-----Original Message-----
From: Internet-Drafts Administrator [mailto:internet-drafts@ietf.org]
Sent: Monday, May 19, 2003 6:13 AM
Subject: To the attention of all WG Chairs


 
  In order to process the many version 00 I-Ds that are received 
before an IETF meeting in a timely manner, we ask that you send a LIST OF
THE NAMES of the drafts you expect to have submitted and have approved for
publication as WG documents to internet-drafts@ietf.org  no later than five
(5) business days prior to the cutoff date for the meeting.

   Please include the word "Permission" in the Subject field.

   This procedure will expedite the posting of version 00 I-Ds, allowing
more time for review by the public.

   Thank you you for your cooperation in this matter.

   The IETF Secretariat

   FYI: All significant dates  can be found at 
        http://www.ietf.org/meetings/cutoff_dates_57.html
_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn



From mailnull@www1.ietf.org  Thu Jun 12 12:29:06 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17647
	for <ipcdn-archive@odin.ietf.org>; Thu, 12 Jun 2003 12:29:05 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5CGSdV04145
	for ipcdn-archive@odin.ietf.org; Thu, 12 Jun 2003 12:28:39 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CGSUm04095;
	Thu, 12 Jun 2003 12:28:30 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CFwEm01508
	for <ipcdn@optimus.ietf.org>; Thu, 12 Jun 2003 11:58:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16620
	for <ipcdn@ietf.org>; Thu, 12 Jun 2003 11:58:11 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QUQo-0003gx-00
	for ipcdn@ietf.org; Thu, 12 Jun 2003 11:56:06 -0400
Received: from mail.yas.com ([192.233.212.3] helo=baltic.yas.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QUQn-0003gr-00
	for ipcdn@ietf.org; Thu, 12 Jun 2003 11:56:05 -0400
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [ipcdn] FW: To the attention of all WG Chairs
Date: Thu, 12 Jun 2003 11:57:38 -0400
Message-ID: <B12F68227AEEDD428B5FD7AC9EFBC25703E178@baltic.yas.com>
Thread-Topic: [ipcdn] FW: To the attention of all WG Chairs
thread-index: AcMw636OiWb5mGdKTIu0XiX+BDeLbAADzG+A
From: "Doug Jones" <doug@yas.com>
To: "Rich Woundy" <Richard_Woundy@cable.comcast.com>,
        "IPCDN WG (E-mail)" <ipcdn@ietf.org>
Cc: "Jean-Francois Mule (E-mail)" <jf.mule@cablelabs.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5CFwEm01510
Sender: ipcdn-admin@ietf.org
Errors-To: ipcdn-admin@ietf.org
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit

hi rich,

the new names of the CableHome I-Ds will be:

draft-ietf-ipcdn-cable-gateway-device-mib-00
draft-ietf-ipcdn-cable-gateway-config-mib-00
draft-ietf-ipcdn-cable-gateway-addressing-mib-00
draft-ietf-ipcdn-cable-gateway-qos-mib-00
draft-ietf-ipcdn-cable-gateway-security-mib-00
draft-ietf-ipcdn-cable-gateway-tools-mib-00


and they are due to the ietf by monday, 6/23 at 7 am MT.   we're on it.


dj


-----Original Message-----
From: Rich Woundy 
Sent: Thursday, June 12, 2003 7:53 AM
To: IPCDN WG (E-mail)
Cc: Jean-Francois Mule (E-mail); Rich Woundy
Subject: [ipcdn] FW: To the attention of all WG Chairs


Folks,

I need to submit the list of the names of all IPCDN version -00.txt drafts
by Monday, June 16th, for processing prior to the Vienna IETF meeting.

I believe this applies in particular to the CableHome MIB internet-drafts,
which are currently named draft-jones-cable-<x>.txt, but ought to be renamed
draft-ietf-ipcdn-<y>-00.txt.

-- Rich

-----Original Message-----
From: Internet-Drafts Administrator [mailto:internet-drafts@ietf.org]
Sent: Monday, May 19, 2003 6:13 AM
Subject: To the attention of all WG Chairs


 
  In order to process the many version 00 I-Ds that are received 
before an IETF meeting in a timely manner, we ask that you send a LIST OF
THE NAMES of the drafts you expect to have submitted and have approved for
publication as WG documents to internet-drafts@ietf.org  no later than five
(5) business days prior to the cutoff date for the meeting.

   Please include the word "Permission" in the Subject field.

   This procedure will expedite the posting of version 00 I-Ds, allowing
more time for review by the public.

   Thank you you for your cooperation in this matter.

   The IETF Secretariat

   FYI: All significant dates  can be found at 
        http://www.ietf.org/meetings/cutoff_dates_57.html
_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn
_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn



From mailnull@www1.ietf.org  Fri Jun 13 12:55:16 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11932
	for <ipcdn-archive@odin.ietf.org>; Fri, 13 Jun 2003 12:55:16 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5DGsnR30563
	for ipcdn-archive@odin.ietf.org; Fri, 13 Jun 2003 12:54:49 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DFX1a20960;
	Fri, 13 Jun 2003 11:33:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DFWSm20911
	for <ipcdn@optimus.ietf.org>; Fri, 13 Jun 2003 11:32:28 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09903
	for <ipcdn@ietf.org>; Fri, 13 Jun 2003 11:32:26 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QqVO-0006Dd-00
	for ipcdn@ietf.org; Fri, 13 Jun 2003 11:30:18 -0400
Received: from coral.tci.com ([198.178.8.81] helo=saipal.tci.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QqVN-0006Cu-00
	for ipcdn@ietf.org; Fri, 13 Jun 2003 11:30:17 -0400
Received: from entexchimc04.broadband.att.com (localhost [127.0.0.1])
	by saipal.tci.com (8.12.9/8.12.9) with ESMTP id h5DFVtND028963
	for <ipcdn@ietf.org>; Fri, 13 Jun 2003 09:31:55 -0600 (MDT)
Received: by entexchimc04.broadband.att.com with Internet Mail Service (5.5.2653.19)
	id <MM0ZWLLN>; Fri, 13 Jun 2003 09:31:54 -0600
Message-ID: <6732623D2548D61193C90002A5C88DCC05663B9B@entmaexch02.broadband.att.com>
From: "Woundy, Richard" <Richard_Woundy@cable.comcast.com>
To: "IPCDN WG (E-mail)" <ipcdn@ietf.org>
Date: Fri, 13 Jun 2003 09:31:52 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [ipcdn] FW: Autoreply from Internet Draft Submission Manager
Sender: ipcdn-admin@ietf.org
Errors-To: ipcdn-admin@ietf.org
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=subscribe>

IPCDN authors,

Please make sure that your draft submissions conform to
http://www.ietf.org/ID-nits.html, or the IETF may/will bounce your
submission. See below.

>This message is being sent to acknowledge receipt of your Internet-Draft 
>submission or message to internet-drafts@ietf.org. 
>If you submitted an Internet-Draft, then it will be posted 
>on the Internet-Drafts page of the IETF Web site, and an I-D
>Action message will be sent to the IETF Announcement List.
>
>Please note that all Internet-Drafts offered for publication
>as RFCs must conform to the requirements specified in ID Nits
>(http://www.ietf.org/ID-nits.html) or they will be returned 
>to the author(s) for revision.  Therefore, the IETF Secretariat
>strongly recommends that you address all of the issues raised 
>in this document before submitting a request to publish your
>Internet-Draft to the IESG.
>
>The IETF Secretariat

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



From mailnull@www1.ietf.org  Fri Jun 13 12:58:27 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12421
	for <ipcdn-archive@odin.ietf.org>; Fri, 13 Jun 2003 12:58:27 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5DGw0Z01969
	for ipcdn-archive@odin.ietf.org; Fri, 13 Jun 2003 12:58:00 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DFR1a20556;
	Fri, 13 Jun 2003 11:27:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DFQbm20540
	for <ipcdn@optimus.ietf.org>; Fri, 13 Jun 2003 11:26:37 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09670
	for <ipcdn@ietf.org>; Fri, 13 Jun 2003 11:26:35 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QqPj-0006B7-00
	for ipcdn@ietf.org; Fri, 13 Jun 2003 11:24:27 -0400
Received: from coral.tci.com ([198.178.8.81] helo=dapsang.tci.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QqPi-0006An-00
	for ipcdn@ietf.org; Fri, 13 Jun 2003 11:24:27 -0400
Received: from entexchimc03.broadband.att.com ([127.0.0.1])
	by dapsang.tci.com (8.12.9/8.12.9) with ESMTP id h5DFPleJ002665;
	Fri, 13 Jun 2003 09:25:48 -0600 (MDT)
Received: by entexchimc03.broadband.att.com with Internet Mail Service (5.5.2653.19)
	id <MM0ZBRRV>; Fri, 13 Jun 2003 09:25:46 -0600
Message-ID: <6732623D2548D61193C90002A5C88DCC05663B9A@entmaexch02.broadband.att.com>
From: "Woundy, Richard" <Richard_Woundy@cable.comcast.com>
To: "'Doug Jones'" <doug@yas.com>
Cc: "Jean-Francois Mule (E-mail)" <jf.mule@cablelabs.com>,
        "IPCDN WG (E-mail)" <ipcdn@ietf.org>
Subject: RE: [ipcdn] FW: To the attention of all WG Chairs
Date: Fri, 13 Jun 2003 09:25:43 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: ipcdn-admin@ietf.org
Errors-To: ipcdn-admin@ietf.org
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=subscribe>

Great! I've notified the proper folks on this...

-- Rich

-----Original Message-----
From: Doug Jones [mailto:doug@yas.com]
Sent: Thursday, June 12, 2003 11:58 AM
To: Woundy, Richard; IPCDN WG (E-mail)
Cc: Jean-Francois Mule (E-mail)
Subject: RE: [ipcdn] FW: To the attention of all WG Chairs


hi rich,

the new names of the CableHome I-Ds will be:

draft-ietf-ipcdn-cable-gateway-device-mib-00
draft-ietf-ipcdn-cable-gateway-config-mib-00
draft-ietf-ipcdn-cable-gateway-addressing-mib-00
draft-ietf-ipcdn-cable-gateway-qos-mib-00
draft-ietf-ipcdn-cable-gateway-security-mib-00
draft-ietf-ipcdn-cable-gateway-tools-mib-00


and they are due to the ietf by monday, 6/23 at 7 am MT.   we're on it.


dj


-----Original Message-----
From: Rich Woundy 
Sent: Thursday, June 12, 2003 7:53 AM
To: IPCDN WG (E-mail)
Cc: Jean-Francois Mule (E-mail); Rich Woundy
Subject: [ipcdn] FW: To the attention of all WG Chairs


Folks,

I need to submit the list of the names of all IPCDN version -00.txt drafts
by Monday, June 16th, for processing prior to the Vienna IETF meeting.

I believe this applies in particular to the CableHome MIB internet-drafts,
which are currently named draft-jones-cable-<x>.txt, but ought to be renamed
draft-ietf-ipcdn-<y>-00.txt.

-- Rich

-----Original Message-----
From: Internet-Drafts Administrator [mailto:internet-drafts@ietf.org]
Sent: Monday, May 19, 2003 6:13 AM
Subject: To the attention of all WG Chairs


 
  In order to process the many version 00 I-Ds that are received 
before an IETF meeting in a timely manner, we ask that you send a LIST OF
THE NAMES of the drafts you expect to have submitted and have approved for
publication as WG documents to internet-drafts@ietf.org  no later than five
(5) business days prior to the cutoff date for the meeting.

   Please include the word "Permission" in the Subject field.

   This procedure will expedite the posting of version 00 I-Ds, allowing
more time for review by the public.

   Thank you you for your cooperation in this matter.

   The IETF Secretariat

   FYI: All significant dates  can be found at 
        http://www.ietf.org/meetings/cutoff_dates_57.html
_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn
_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn



From mailnull@www1.ietf.org  Tue Jun 17 15:03:50 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03425
	for <ipcdn-archive@odin.ietf.org>; Tue, 17 Jun 2003 15:03:49 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5HJ3MX27377
	for ipcdn-archive@odin.ietf.org; Tue, 17 Jun 2003 15:03:22 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HG40a08526;
	Tue, 17 Jun 2003 12:04:00 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HG3Om08504
	for <ipcdn@optimus.ietf.org>; Tue, 17 Jun 2003 12:03:24 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24591
	for <ipcdn@ietf.org>; Tue, 17 Jun 2003 12:03:21 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SItO-0001I8-00
	for ipcdn@ietf.org; Tue, 17 Jun 2003 12:01:06 -0400
Received: from desktop.terayon.com ([63.201.251.10] helo=SCBH02.terayon.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SItM-0001Hq-00
	for ipcdn@ietf.org; Tue, 17 Jun 2003 12:01:04 -0400
Received: by scowa.terayon.com with Internet Mail Service (5.5.2656.59)
	id <NDABF1DS>; Tue, 17 Jun 2003 09:02:48 -0700
Message-ID: <E54A98375651D511816A00306E06B970C4A51A@OTNOAMEXCH01>
From: "Raftus, David" <david.raftus@Terayon.com>
To: "Rich Woundy (Work) (E-mail)" <Richard_Woundy@cable.comcast.com>,
        "'milu@cisco.com'" <milu@cisco.com>,
        "'stevem@com21.com'"
	 <stevem@com21.com>,
        "'mdolas@broadcom.com'" <mdolas@broadcom.com>,
        "'jdemarty@juniper.net'" <jdemarty@juniper.net>,
        "'e.cardona@cablelabs.com'" <e.cardona@cablelabs.com>,
        "'g.white@cablelabs.com'" <g.white@cablelabs.com>,
        "'john.gillis@adc.com'" <john.gillis@adc.com>,
        "'lucy.pollak@ti.com'"
	 <lucy.pollak@ti.com>,
        "'alexb@coresma.com'" <alexb@coresma.com>,
        "'david.white@arrisi.com'" <david.white@arrisi.com>,
        "'matt.schmitt@arrisi.com'" <matt.schmitt@arrisi.com>,
        "'kfriedman@correlant.com'" <kfriedman@correlant.com>,
        "'fred@stargus.com'" <fred@stargus.com>,
        "'joe@kar-el.cvnet.com'"
	 <joe@kar-el.cvnet.com>,
        "'W.Murwin@motorola.com'"
	 <W.Murwin@motorola.com>,
        "'ASundelin@stargus.com'"
	 <ASundelin@stargus.com>,
        "'vhou@juniper.net'" <vhou@juniper.net>
Cc: "Docsis 20 Reflector (E-mail)" <docsis-20@cablelabs.com>,
        "Docsis Oss Reflector (E-mail)" <docsis-oss@cablelabs.com>,
        "Ipcdn List (E-mail)" <ipcdn@ietf.org>,
        "Raftus, David"
	 <david.raftus@Terayon.com>
Date: Tue, 17 Jun 2003 08:36:33 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C334E6.3B2097A0"
Subject: [ipcdn] rf mib draft v6 to draft v7 suggestions
Sender: ipcdn-admin@ietf.org
Errors-To: ipcdn-admin@ietf.org
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=subscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C334E6.3B2097A0
Content-Type: text/plain;
	charset="iso-8859-1"

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

------_=_NextPart_001_01C334E6.3B2097A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 9">
<meta name=3DOriginator content=3D"Microsoft Word 9">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C334C4.C53BF0A0">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:View>Normal</w:View>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0pt;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:9.0pt;
	mso-bidi-font-size:12.0pt;
	font-family:Arial;
	mso-fareast-font-family:"Times New Roman";
	color:black;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0pt;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:9.0pt;
	mso-bidi-font-size:12.0pt;
	font-family:Arial;
	mso-fareast-font-family:"Times New Roman";
	color:black;}
span.EmailStyle15
	{mso-style-type:personal-compose;
	mso-ansi-font-size:10.0pt;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:black;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	mso-header-margin:36.0pt;
	mso-footer-margin:36.0pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
</head>

<body lang=3DEN-US style=3D'tab-interval:36.0pt'>

<div class=3DSection1>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><span
class=3DEmailStyle15><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt'>Hi =
everyone,<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><span
class=3DEmailStyle15><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><span
class=3DEmailStyle15><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt'>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. =
<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><span
class=3DEmailStyle15><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><span
class=3DEmailStyle15><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt'>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.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><span
class=3DEmailStyle15><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><span
class=3DEmailStyle15><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt'>Thanks for your =
time,<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><span
class=3DEmailStyle15><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt'>Dave<o:p></o:p></span></font></span></=
p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D1 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:8.5pt;font-family:
"Courier New"'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span></font><font
size=3D1 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:8.5pt;font-family:
"Courier =
New";color:black;mso-color-alt:windowtext'><o:p></o:p></span></font></p>=


<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D1 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:8.5pt;font-family:
"Courier New"'><br>
<br>
1) Return name to pre draft v6 DOCS-IF-MIB from draft v6 =
DOCS-IETF-RFI-MIB. <br>
<br>
Contributors - Rich Woundy IPCDN/Comcast, Minnie Lu Cisco, Steve =
Malenfant
Com21<br>
<br>
<br>
2) docsIfCmtsChannelUtUtilization formula - remove line (100 * ((raw =
bytes -
stuffed bytes) / raw bytes))<br>
since it assumes that MPEG payload consists only DOC MAC payload. As we =
<br>
know, MPEG could consist video payload and NULL packets. Suggest to =
remove <br>
this line since the first 2 lines in the formula are good enough.<br>
<br>
Contributor - Minnie Lu<span =
style=3D'mso-tab-count:1'>&nbsp;&nbsp;&nbsp; </span>Cisco<br>
<br>
<br>
3) Add discontinuity descriptions to all counters related to an =
interface.<br>
<br>
Contributor - Minnie Lu<span =
style=3D'mso-tab-count:1'>&nbsp;&nbsp;&nbsp; </span>Cisco<br>
<br>
<br>
4) docsIfCmtsInsertInterval - For the docsIfCmtsInsertInterval object, =
there is
no such thing as a <br>
&quot;broadcast station maintenance&quot; interval for new modems =
joining the
network.<span style=3D"mso-spacerun: yes">&nbsp;&nbsp; </span>Station =
should be <br>
changed to initial to make the text read - &quot;The amount of time to =
elapse
between each broadcast <br>
initial maintenance grant.<span style=3D"mso-spacerun: yes">&nbsp;
</span>Broadcast initial maintenance grants are used to allow new cable =
modems <br>
to join the network.<span style=3D"mso-spacerun: yes">&nbsp; =
</span>Zero
indicates that a vendor-specific algorithm is used instead of a fixed
time.<span style=3D"mso-spacerun: yes">&nbsp; </span><br>
Maximum amount of time permitted by the specification is 2 =
seconds.&quot;<br>
<br>
Contributor - Margo Dolas Broadcom<br>
<br>
<br>
5) docsIfCmtsModPreambleType - (Joel) In docsIfCmtsModulationTable, the
docsIfCmtsModPreambleType object has <br>
2 possible values qpsk0(1) and qpsk1(2). It seems like it's the only =
object in
this table without a <br>
meaningful default value when this parameter does not make sense. For =
instance,
for a TDMA modulation <br>
profile using QAM16, the actual preamble type is indeed not QPSK0 but =
something
else. Does it make sense <br>
to have a value of 0 in this case, like =
docsIfCmtsModScdmaInterleaverStepSize
for non-SCDMA profiles?<br>
<br>
(Eduardo) for the benefit of clarifications wouldn't be good to have a
enumeration unknown(0) for this <br>
object when not a 2.0 burst ?<br>
Also a note in the DESCRIPTION like &quot;if docsIfCmtsModChannelType =
is
tdma(1) a value unknown(0) is used for this object&quot; <br>
I would say unknown(0) rather than unknown(3) since it looks like the =
possible
current implementation may be reporting<span style=3D"mso-spacerun: =
yes">&nbsp;
</span><br>
'0' , and defendable in IETF since RFC 3291 uses '0' for =
inetAddressType<br>
<br>
Contributors - Joel Demarty Juniper, Eduardo Cardona Cablelabs<br>
<br>
<br>
6) docsIfUpstreamChannelTable clone mechanism - improve descriptive =
wording.
The spec is vague about the minimum set of parameters <br>
that the <br>
CMTS must transfer during a clone operation to be DOCSIS 2.0 compliant. =
Only
those starting with docsIfUpChannelScdma or <br>
all parameters defining an SCDMA channel, like the channel width? Then =
what
about the frequency? <br>
Definitely, this clone mechanism is sophisticated enough that it would =
deserve
a more detailed specification <br>
(and testing) and, as a consequence, an ECR.<br>
<br>
Contributor - Joel Demarty Juniper<br>
<br>
<br>
7) docsIfUpChannelPreEqEnable - add DEFVAL clause.<br>
<br>
Contributor - John Gillis ADC<br>
<br>
<br>
8) docsIfCmtsUpChnlCtrUcastGrantedMslots - In Cisco CMTS, we use IUC14
(reserved) and SID (HEX): 1FFF (max. of <br>
unicast sid number) for quite some time.<br>
Q: Should it be counted in docsIfCmtsUpChnlCtrUcastGrantedMslots ?<br>
My personal think that this objects seems to mean the <br>
meaningful<span style=3D"mso-spacerun: yes">&nbsp; </span>UNICAST SID, =
so user
could get a good idea about the how many <br>
minislots really assigned to some meaningful CM.<span =
style=3D"mso-spacerun:
yes">&nbsp; </span>So, the reserved IUCs <br>
should be excluded from this object though minislots for reserved IUCs =
are <br>
still be counted into docsIfCmtsUpChnlCtrTotalMslots.<br>
Minnie,<br>
I agree, I think IUC14 grants to SID 1FFF (assuming the CMTS =
reserves<br>
that SID to mean no CM) should not be counted in =
UcastGrantedMslots.<br>
I also think (and maybe this case is more obvious) than grants to SID =
0<br>
should not be counted in UcastGrantedMslots.<br>
This brings up a question that I've had for some time.<span
style=3D"mso-spacerun: yes">&nbsp; </span>Why does the<br>
Cisco CMTS use IUC14 and SID 1FFF????<span style=3D"mso-spacerun: =
yes">&nbsp;
</span>The use of IUC14 is prohibited by<br>
the spec, since it is labeled as &quot;Reserved&quot;, and SID 0 is =
already<br>
defined to mean &quot;no CM&quot;.<br>
-Greg<br>
<br>
Contributors - Minnie Lu Cisco, Greg White Cablelabs<br>
<br>
<br>
9) docsIfCmStatusTable - possibly add new objects for successful/failed =
ucc
transactions. <br>
Hi, Alex,<br>
I do not think that this is good idea. What will you count into<br>
docsQosDCCAcks? The relationships between DCC Req/Rsp/Ack is important =
and<br>
should not be lost because of UCC additions. I guess, the better place =
for<br>
this counters is RFI MIB docsIfCmStatusTable. It may be extended in =
future<br>
versions.<br>
Regards.<br>
Lucy<br>
Hello all,<br>
A question about counting successful and failed UCC transactions.<br>
It seems like there is no counters dedicated for UCC failed or<br>
succeeded operation as it is for DCC transactions.<br>
The question is, since UCC is a subset of DCC operation for 1.1 =
modem,<br>
should the modem count UCC transactions in DCC counters =
(docsQosDCCs,<br>
docsQosDCCFails) ?<br>
Thank you in advance.<br>
<br>
Contributors - Lucy Pollak TI, Alex Betis Coresma<br>
<br>
<br>
10) docsIfUpChannelPreEqEnable, docsIfCmStatusEqualizationData - =
clarify
descriptions.<br>
Lucy,<br>
Sorry for the delay in responding.<span style=3D"mso-spacerun: =
yes">&nbsp;
</span>I don't have an objection to your proposal, as long as the <br>
format of the object is clear.<br>
To summarize, the object docsIfCmStatusEqualizationData will only =
include the
&quot;value&quot; from figure 8-23.<span style=3D"mso-spacerun: =
yes">&nbsp;
</span><br>
In other words, the first byte reported in the MIB object will be the =
main tap
location.<span style=3D"mso-spacerun: yes">&nbsp; </span>A =
clarification <br>
should also be made to the description of docsIfUpChannelPreEqEnable to
indicate your interpretation (b). <br>
Regarding the question about reverse taps, figure 8-23 is a =
simplification of
figure 6-23 from the 1.1 RFI <br>
spec (which includes a format to encode reverse taps).<span
style=3D"mso-spacerun: yes">&nbsp; </span>It seems to make sense to me =
to use the
format <br>
shown in that figure.<span style=3D"mso-spacerun: yes">&nbsp; =
</span>Perhaps this
MIB object could be clarified to reference both figures.<br>
-Greg<br>
<br>
Greg,<br>
to summarize our objections:<br>
1. MIB requires equalization data, then type/length is irrelevant.<br>
2. There are 2 possible types 4 (Transmit Equalization Adjust) or 9 =
(Transmit
Equalization Set), which is <br>
irrelevant after convolution.<br>
3. To be consistent with DS equa data, some TLV should be added also =
into it.
What?<br>
We propose to use only value from referenced figure without type/length =
to
avoid questions in the future. If not, <br>
(2) and (3) should be clarified. I guess, that it will be also very =
helpful if
clarification (b) will be entered into MIB. <br>
Best Regards.<br>
Lucy<br>
<br>
Contributors - Lucy Pollak TI, Greg White Cablelabs<br>
<br>
<br>
11) docsIfSignalQualityEntry - clarify wording for back =
compatibility.<br>
In draft -03 the description of<span style=3D"mso-spacerun: yes">&nbsp;
</span>docsIfSignalQualityEntry was changed <br>
from : <br>
docsIfSignalQualityEntry OBJECT-TYPE <br>
<span style=3D"mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span>SYNTAX<span style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span>DocsIfSignalQualityEntry <br>
<span style=3D"mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span>MAX-ACCESS<span style=3D"mso-spacerun: yes">&nbsp; =
</span>not-accessible <br>
<span style=3D"mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span>STATUS<span style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span>current <br>
<span style=3D"mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span>DESCRIPTION <br>
<span style=3D"mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;
</span>&quot;At the CM, describes the PHY characteristics of a <br>
<span style=3D"mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;
</span>downstream channel. At the CMTS, describes the PHY <br>
signal <br>
<span style=3D"mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;
</span>quality of an upstream channel. <br>
<span style=3D"mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;
</span>An entry in this table exists for each ifEntry with an <br>
<span style=3D"mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;
</span>ifType of docsCableUpstream(129) for Cable Modem <br>
Termination <br>
<span style=3D"mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;
</span>Systems and docsCableDownstream(128) for Cable Modems.&quot; =
<br>
<span style=3D"mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span>INDEX
{ ifIndex } <br>
<span style=3D"mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span>::=3D {
docsIfSignalQualityTable 1 } <br>
to : <br>
docsIfSignalQualityEntry OBJECT-TYPE <br>
<span style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span>SYNTAX<span style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span>DocsIfSignalQualityEntry <br>
<span style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span>MAX-ACCESS<span style=3D"mso-spacerun: yes">&nbsp; =
</span>not-accessible <br>
<span style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span>STATUS<span style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span>current <br>
<span style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span>DESCRIPTION <br>
<span style=3D"mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span>&quot;At the CM, describes the PHY characteristics of a <br>
<span style=3D"mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;
</span>downstream channel. At the CMTS, describes the PHY signal <br>
<span style=3D"mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;
</span>quality of an upstream channel. <br>
<span style=3D"mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;
</span>An entry in this table exists for each ifEntry with an <br>
<span style=3D"mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;
</span>ifType of docsCableUpstreamChannel(205) for Cable Modem <br>
Termination <br>
<span style=3D"mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;
</span>Systems and docsCableDownstream(128) for Cable Modems.&quot; =
<br>
<span style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span>INDEX { ifIndex } <br>
<span style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span><span
style=3D"mso-spacerun: yes">&nbsp;</span>::=3D { =
docsIfSignalQualityTable 1 } <br>
But now RFI mib also apply to 1.1 CMTSes with no concept of ifType 205 =
<br>
but 129 <br>
<br>
Contributor - Eduardo Cardona Cablelabs<br>
<br>
<br>
12) docsIfCmtsCmStatusValue - add new defined value
registeredBPIInitializing(9),<br>
deprecate former value operational(8).<br>
<br>
Contributors - Eduardo Cardona Cablelabs, Lucy Pollak TI, Minnie Lu =
Cisco,
David White Arris,<br>
Matt Schmitt Arris, Kirk Friedman Correlant, Fred Oko Stargus, Joe =
Godas
Kar-el, Steve Malenfant Com21<br>
<br>
<br>
13) Adjust compliance statements for objects designated optional. Add =
separate
augmentation table for <br>
optional objects in docsIfCmtsUpChannelCounterTable.<br>
<br>
Contributors - Will Murwin Motorola, Rich Woundy IPCDN/Comcast, Mike =
StJohns
Mindspring, Eduardo Cardona Cablelabs<br>
<br>
<br>
14) Add section explaining counter interaction between Docsis =
1.0/1.1/2.0.<br>
The QOS MIB tried to handle<br>
DOCSIS 1.1 changes to RFC2670. Now that rfc2670 is being obsoleted, the =
rf-mib
v2 and the DOCSIS OSS Specs is the place<br>
that should clearly state how these counters and other tables interact =
in
DOCSIS 1.0, DOCSIS 1.1, and DOCSIS 2.0.<br>
I would even hope to see a section in the rf-mib v2, =
&quot;Interoperation with
the version of DOCSIS&quot; like or to replace<br>
what the DOCSIS QOS MIB has. This is the place to describe what table =
are
populated under the docsIfMib when the<br>
the modems are registering.<br>
This way this issue can be re-discussed and whatever conculsion is =
reached, can
be document in the description of those<br>
objects.<br>
<br>
Contributor - Will Murwin Motorola, Minnie Lu Cisco<br>
<br>
<br>
15) Change docsIfCmtsServiceTable to count packets for both upstream =
and
downstream flows. <br>
One of the things that has long been an issue with the RF MIB is that =
the
docsIfCmtsServiceTable only counts <br>
InOctets and InPackets (i.e. upstream packets only). If the reason for =
keeping
this table is to support DOCSIS <br>
1.0 modems would it also make sense to add downstream packet counts to =
this
table, too? Many CMTS'es already <br>
count this information and store it in a proprietary MIB. It would be =
nice to
standardize this as a requirement <br>
so that NMS such as usage monitoring systems could (a) count on it =
existing and
(b) find it in a standard location.<br>
<br>
Contributor - Andrew Sundelin Stargus<br>
<br>
<br>
16) Add 4 objects to docsIfCmtsCmStatusTable<br>
While writing DOCS-IETF-QOS-MIB version 9, I find myself still thinking =
about
Minnie suggestion of having<span style=3D"mso-spacerun: yes">&nbsp; =
</span><br>
docsIfCmtsServiceInPackets and docsIfCmtsServiceInOctets count for =
DOCSIS 1.1
and 2.0. Even though the QOS <br>
MIB has pawned off this discussion, I have had some thoughts on the =
subject.<br>
(1) If these counters where used to count the DOCSIS 1.1 and 2.0, than =
this
would the best place in all <br>
of the mibs to<br>
<span style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </span>get a quick =
summary
of the upstream data received by a particular modem, no matter the =
version.<br>
(2) At the same time, The rest of the docsIfCmtsCmServiceTable might =
not make
sense for DOCSIS 1.1 or 2.0<br>
However the more I looked around at the different counters that existed =
in all
of MIB required by DOCSIS, <br>
the more I kept looking for an overall counter on the CMTS to count =
data packet
received and transmitted <br>
for a particular CM. <br>
I would like to start a discussion on about adding 4 new object to the
docsIfCmtsCmStatusTable:<br>
docsIfCmtsCmStatusInPackets <br>
docsIfCmtsCmStatusInOctets<br>
docsIfCmtsCmStatusOutPackets<br>
docsIfCmtsCmStatusOutoctets<br>
While I understand that these counts can be gathered by via numerous =
objects on
both the CMTS and CM <br>
and then just appling simple math. However I want to query only one =
agent and
just get a quick summary <br>
without have to determine which version of DOCSIS the modem is, which =
will
determine which mibs I look etc.<br>
and objects I query.<br>
<br>
For example if I want query only one agent(i.e. the CMTS) and get the =
number of
transmitted and received <br>
data for each CM, then <br>
<span style=3D'mso-tab-count:1'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span>(1)
GET-NEXT the docsIfCmtsCmStatusRegMode to see what version of DOCSIS =
this modem
is operting <br>
<br>
<span style=3D'mso-tab-count:1'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span>if
'docsis10(1)' then <br>
<span =
style=3D'mso-tab-count:3'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; </span>(2)
WALK the entire docsIfCmtsServiceTable for ifIndex and SID that<br>
<span style=3D'mso-tab-count:1'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span><span
style=3D"mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;
</span>have docsIfCmtsServiceNewCmStatusIndex that matches the index =
for step
(1).<br>
<span style=3D'mso-tab-count:1'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span><br>
<span =
style=3D'mso-tab-count:3'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; </span>(3)
Add the all the instances of docsIfCmtsServiceInPacket for the<br>
<span style=3D'mso-tab-count:1'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span><span
style=3D"mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;
</span>ifIndex and SIDs that match from step(2) to get the total =
Received
packets from a CM.<br>
<br>
<span =
style=3D'mso-tab-count:3'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; </span>NOTE:
Not sure it is possible to get from a CMTS agent from the Standard MIBs =
the number
of <br>
<span style=3D'mso-tab-count:1'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span><span
style=3D"mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span>of packets transmitted to a single docsis 1.0 cable modem.<br>
<br>
<span style=3D'mso-tab-count:1'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span>else
if 'docsis11(2)' or 'docsis20()' then<br>
<span =
style=3D'mso-tab-count:3'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; </span>(2)
WALK the docsQosCmtsMacToSrvFlowTable all for the instances of that =
contain the<br>
<span style=3D'mso-tab-count:1'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span><span
style=3D"mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;
</span>same mac address.<br>
<span =
style=3D'mso-tab-count:2'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span
style=3D'mso-tab-count:1'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span>(3) Then
GET the docQosServiceFlowPkts using the ifIndex and<br>
<span style=3D"mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span>service flow id from step(2). Add this to the total of received =
or
transmitted for this CM.<br>
<span =
style=3D'mso-tab-count:3'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; </span><span
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </span>To determine the =
direction
of the flow use the same index and query the =
docsQosServiceFlowDirection.<br>
This seems very complicated for something so simple. This is just a =
suggestion
of simple way the RF MIB v2 can correct the <br>
mistakes of the past.<span style=3D"mso-spacerun: yes">&nbsp; =
</span><br>
<br>
Contributors - Will Murwin Motorola, Minnie Lu Cisco<br>
<br>
<br>
17) docsIfCmtsCmStatusTimingOffset - possibly change decription of =
existing
object or<br>
add new object to reconcile unit differences between 1.1/2.0. Still =
under
discussion.<br>
<br>
Contributors - Victor Hou Juniper, Rich Woundy IPCDN/Comcast, Kirk =
Friedman
Correlant.<br>
<br>
<br>
<br style=3D'mso-special-character:line-break'>
<![if !supportLineBreakNewLine]><br =
style=3D'mso-special-character:line-break'>
<![endif]></span></font><font size=3D1 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:8.5pt;font-family:"Courier =
New";color:black;mso-color-alt:
windowtext'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<p class=3DMsoNormal><!--[if supportFields]><span =
style=3D'mso-element:field-begin'></span><span=20
style=3D"mso-spacerun: yes">&nbsp;</span>AUTOTEXTLIST \s &quot;E-mail=20
Signature&quot; <span =
style=3D'mso-element:field-separator'></span><![endif]--><font
size=3D2 color=3Dblue><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;
color:blue'>************************************<o:p></o:p></span></font=
></p>

<p class=3DMsoNormal><i style=3D'mso-bidi-font-style:normal'><font =
size=3D2
color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;
color:blue;font-style:italic'>David =
Raftus<o:p></o:p></span></font></i></p>

<p class=3DMsoNormal><i style=3D'mso-bidi-font-style:normal'><font =
size=3D2
color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;
color:blue;font-style:italic'>Terayon Canada =
Ltd<o:p></o:p></span></font></i></p>

<p class=3DMsoNormal><i style=3D'mso-bidi-font-style:normal'><font =
size=3D2
color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;
color:blue;font-style:italic'>340 Terry Fox Drive, Suite =
202<o:p></o:p></span></font></i></p>

<p class=3DMsoNormal><i style=3D'mso-bidi-font-style:normal'><font =
size=3D2
color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;
color:blue;font-style:italic'>Ottawa Canada<span style=3D"mso-spacerun:
yes">&nbsp; </span>K2K 3A2<o:p></o:p></span></font></i></p>

<p class=3DMsoNormal><i style=3D'mso-bidi-font-style:normal'><font =
size=3D2
color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;
color:blue;font-style:italic'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></i></p>

<p class=3DMsoNormal><i style=3D'mso-bidi-font-style:normal'><font =
size=3D2
color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;
color:blue;font-style:italic'>david.raftus@terayon.com<span
style=3D"mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span><o:p></o:p></span></font></i></p>

<p class=3DMsoNormal><i style=3D'mso-bidi-font-style:normal'><font =
size=3D2
color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;
color:blue;font-style:italic'>613.592.1052<span style=3D"mso-spacerun:
yes">&nbsp; </span>ext 222<o:p></o:p></span></font></i></p>

<p class=3DMsoNormal><i style=3D'mso-bidi-font-style:normal'><font =
size=3D2
color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;
color:blue;font-style:italic'>************************************<span
style=3D"mso-spacerun: yes">&nbsp; </span></span></font></i><font =
size=3D2><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt'><span =
style=3D"mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;</span><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D1 color=3Dblack face=3DArial><span =
style=3D'font-size:
9.0pt'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span><o:p></o:p></font></p>

<p class=3DMsoNormal><!--[if supportFields]><span =
style=3D'mso-element:field-end'></span><![endif]--><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

</div>

</body>

</html>

------_=_NextPart_001_01C334E6.3B2097A0--
_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn



From exim@www1.ietf.org  Tue Jun 17 15:42:25 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07222
	for <ipcdn-archive@odin.ietf.org>; Tue, 17 Jun 2003 15:42:25 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5HJfuU20039
	for ipcdn-archive@odin.ietf.org; Tue, 17 Jun 2003 15:41:56 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SM3n-000361-5N; Tue, 17 Jun 2003 15:24:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SLAp-00043v-2K
	for ipcdn@optimus.ietf.org; Tue, 17 Jun 2003 14:27:16 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01089
	for <ipcdn@ietf.org>; Tue, 17 Jun 2003 14:27:12 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SL8Z-0002tD-00
	for ipcdn@ietf.org; Tue, 17 Jun 2003 14:24:55 -0400
Received: from sj-core-5.cisco.com ([171.71.177.238])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SL8Y-0002r8-00
	for ipcdn@ietf.org; Tue, 17 Jun 2003 14:24:54 -0400
Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5HIP6Um025870;
	Tue, 17 Jun 2003 11:25:06 -0700 (PDT)
Received: from cisco.com (dhcp-171-71-187-129.cisco.com [171.71.187.129])
	by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR)
	with ESMTP id AIM19753;
	Tue, 17 Jun 2003 11:25:05 -0700 (PDT)
Message-ID: <3EEF5D01.1050406@cisco.com>
Date: Tue, 17 Jun 2003 11:25:05 -0700
From: Azlina Ahmad <azlina@cisco.com>
Reply-To: azlina@cisco.com
Organization: CIsco Systems
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Minnie Lu <milu@cisco.com>, Joe Godas <joe@kar-el.cvnet.com>
CC: "Raftus, David" <david.raftus@Terayon.com>,
        "Rich Woundy (Work) (E-mail)"
 <Richard_Woundy@cable.comcast.com>,
        stevem@com21.com, mdolas@broadcom.com, jdemarty@juniper.net,
        e.cardona@cablelabs.com, g.white@cablelabs.com, 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,
        W.Murwin@motorola.com, ASundelin@stargus.com, vhou@juniper.net,
        "Docsis 20 Reflector (E-mail)"
 <docsis-20@cablelabs.com>,
        "Docsis Oss Reflector (E-mail)"
 <docsis-oss@cablelabs.com>,
        "Ipcdn List (E-mail)" <ipcdn@ietf.org>
References: <E54A98375651D511816A00306E06B970C4A51A@OTNOAMEXCH01> <4.3.2.7.2.20030617104343.021cb958@mira-sjc5-1.cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [ipcdn] Re: rf mib draft v6 to draft v7 suggestions
Sender: ipcdn-admin@ietf.org
Errors-To: ipcdn-admin@ietf.org
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


Another way of disabling the HSD access is to disabled (down)
the ifAdminStatus of the Ethernet interface on the modem itself.
In this case, the CMTS will not know this status.

But again, this really depends on how customers 
operate/provision/disabled their users :)  If the assumption that
the modem will get reset, then below would work fine.

Thanks,
Azlina

Minnie Lu wrote:
> Hi, Joe,
> 
> Good suggestion.  Maybe in more general, no matter the BPI is enabled or 
> not, a new state for the case that CM is registrationComplete but 
> network access has being disabled by operator/system administrator.
> 
> Thanks!
> Minnie
> 
> At 01:14 PM 6/17/2003 -0400, Joe Godas wrote:
> 
>> "urn:schemas-microsoft-com:office:office" xmlns:w = 
>> "urn:schemas-microsoft-com:office:word">
>> Hi,
>> <I hope I'm not missing something obvious ;>
>>
>> Regarding Item 12 (docsIfCmtsCmStatusValue)and its relation to BPI 
>> state....I am concerned that we haven't captured the case where a 
>> modem has successfully negotiated BPI but it's network access has been 
>> disabled.
>>
>> Implementation example: on a Cisco CMTS a BPI enabled voice product 
>> would look like this:
>> ubr110.cmts.hcvlny#scm | inc pt
>> <snip>
>> MAC Address    IP Address      I/F       MAC         Prim RxPwr  
>> Timing  Num BPI
>>                                          State       Sid  (db)   
>> Offset CPE Enb
>> 0008.0e72.1e30 10.13.18.73     C3/0/U0   online(pt)  6899 0.75   
>> 1946    0   Y
>>
>> This modem is showing as online (with BPI) whether or not it's network 
>> access has been disabled due to customer not paying their bill.
>>
>> Is there a response code in the Mib that reflects this BPI negotiated 
>> (with data disabled) state or do we have to rely on querying the 
>> forwarding state of the actual CM?
>>
>> Thanks,
>> Joe Godas
>> Cablevision
>>
>>
>> ----- Original Message -----
>> From: <mailto:david.raftus@Terayon.com>Raftus, David
>> To: <mailto:Richard_Woundy@cable.comcast.com>Rich Woundy (Work) 
>> (E-mail) ; <mailto:'milu@cisco.com'>'milu@cisco.com' ; 
>> <mailto:'stevem@com21.com'>'stevem@com21.com' ; 
>> <mailto:'mdolas@broadcom.com'>'mdolas@broadcom.com' ; 
>> <mailto:'jdemarty@juniper.net'>'jdemarty@juniper.net' ; 
>> <mailto:'e.cardona@cablelabs.com'>'e.cardona@cablelabs.com' ; 
>> <mailto:'g.white@cablelabs.com'>'g.white@cablelabs.com' ; 
>> <mailto:'john.gillis@adc.com'>'john.gillis@adc.com' ; 
>> <mailto:'lucy.pollak@ti.com'>'lucy.pollak@ti.com' ; 
>> <mailto:'alexb@coresma.com'>'alexb@coresma.com' ; 
>> <mailto:'david.white@arrisi.com'>'david.white@arrisi.com' ; 
>> <mailto:'matt.schmitt@arrisi.com'>'matt.schmitt@arrisi.com' ; 
>> <mailto:'kfriedman@correlant.com'>'kfriedman@correlant.com' ; 
>> <mailto:'fred@stargus.com'>'fred@stargus.com' ; 
>> <mailto:'joe@kar-el.cvnet.com'>'joe@kar-el.cvnet.com' ; 
>> <mailto:'W.Murwin@motorola.com'>'W.Murwin@motorola.com' ; 
>> <mailto:'ASundelin@stargus.com'>'ASundelin@stargus.com' ; 
>> <mailto:'vhou@juniper.net'>'vhou@juniper.net'
>> Cc: <mailto:docsis-20@cablelabs.com>Docsis 20 Reflector (E-mail) ; 
>> <mailto:docsis-oss@cablelabs.com>Docsis Oss Reflector (E-mail) ; 
>> <mailto:ipcdn@ietf.org>Ipcdn List (E-mail) ; 
>> <mailto:david.raftus@Terayon.com>Raftus, David
>> Sent: Tuesday, June 17, 2003 11:36 AM
>> 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
>> ************************************
>>
>>
> 
> 



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



From exim@www1.ietf.org  Tue Jun 17 17:08:29 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11670
	for <ipcdn-archive@odin.ietf.org>; Tue, 17 Jun 2003 17:08:29 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5HL81s09994
	for ipcdn-archive@odin.ietf.org; Tue, 17 Jun 2003 17:08:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SNgP-0002am-1P; Tue, 17 Jun 2003 17:08:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SLIa-0004iv-Ax
	for ipcdn@optimus.ietf.org; Tue, 17 Jun 2003 14:35:16 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01830
	for <ipcdn@ietf.org>; Tue, 17 Jun 2003 14:35:13 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SLGK-000338-00
	for ipcdn@ietf.org; Tue, 17 Jun 2003 14:32:56 -0400
Received: from kar-el.eng.cv.net ([167.206.9.41] helo=kar-el.cvnet.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SLGJ-00032p-00
	for ipcdn@ietf.org; Tue, 17 Jun 2003 14:32:55 -0400
Received: from IBM (localhost [127.0.0.1])
 by kar-el.cvnet.com (iPlanet Messaging Server 5.1 (built May  7 2001))
 with SMTP id <0HGN0078A1Z2BR@kar-el.cvnet.com> for ipcdn@ietf.org; Tue,
 17 Jun 2003 14:28:16 -0400 (EDT)
Date: Tue, 17 Jun 2003 14:34:24 -0400
From: Joe Godas <joe@kar-el.cvnet.com>
To: Minnie Lu <milu@cisco.com>
Cc: "Raftus, David" <david.raftus@terayon.com>,
        "Rich Woundy (Work) (E-mail)" <Richard_Woundy@cable.comcast.com>,
        milu@cisco.com, stevem@com21.com, mdolas@broadcom.com,
        jdemarty@juniper.net, e.cardona@cablelabs.com, g.white@cablelabs.com,
        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, W.Murwin@motorola.com,
        ASundelin@stargus.com, vhou@juniper.net,
        "Docsis 20 Reflector (E-mail)" <docsis-20@cablelabs.com>,
        "Docsis Oss Reflector (E-mail)" <docsis-oss@cablelabs.com>,
        "Ipcdn List (E-mail)" <ipcdn@ietf.org>
Message-id: <00a401c334ff$1a7c1470$1a02a8c0@IBM>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <E54A98375651D511816A00306E06B970C4A51A@OTNOAMEXCH01>
 <4.3.2.7.2.20030617104343.021cb958@mira-sjc5-1.cisco.com>
Content-Transfer-Encoding: 7BIT
Subject: [ipcdn] Re: rf mib draft v6 to draft v7 suggestions
Sender: ipcdn-admin@ietf.org
Errors-To: ipcdn-admin@ietf.org
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7BIT

Minnie,
I think you are right, this way we can avoid conflicts associated to a
single table and finding a result code for the different combinations.
We've had to make the uncomfortable change of relying on the CM to tell us
it's data forwarding status due to this and would like to go back to asking
the CMTS about the status for each CM for the obvious reason that the CMTS
is/should be the only thing we trust to identify "state."

Ie (vendor specific example again): Online(d) indicates network access
disabled but querying the "unregistered" table will not show the CMs who are
BPI enabled <with network access turned off> because Online(pt) represents
BPI successful and as such overrides the Online(d) status.

ubr110.cmts.hcvlny#scm unregistered  (this table will not yield BPI enabled,
data disabled modems)

Interface Prim Online      Timing Rec     QoS CPE IP address      MAC
address
          Sid  State       Offset Power
C3/0/U0   295  online(d)    4056   -0.50  8   0   10.10.82.90
0020.40c0.1cb2

Thanks,
-Joe
----- Original Message -----
From: "Minnie Lu" <milu@cisco.com>
To: "Joe Godas" <joe@kar-el.cvnet.com>
Cc: "Raftus, David" <david.raftus@terayon.com>; "Rich Woundy (Work)
(E-mail)" <Richard_Woundy@cable.comcast.com>; <milu@cisco.com>;
<stevem@com21.com>; <mdolas@broadcom.com>; <jdemarty@juniper.net>;
<e.cardona@cablelabs.com>; <g.white@cablelabs.com>; <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>;
<W.Murwin@motorola.com>; <ASundelin@stargus.com>; <vhou@juniper.net>;
"Docsis 20 Reflector (E-mail)" <docsis-20@cablelabs.com>; "Docsis Oss
Reflector (E-mail)" <docsis-oss@cablelabs.com>; "Ipcdn List (E-mail)"
<ipcdn@ietf.org>; "Raftus, David" <david.raftus@terayon.com>
Sent: Tuesday, June 17, 2003 1:49 PM
Subject: Re: rf mib draft v6 to draft v7 suggestions


> Hi, Joe,
>
> Good suggestion.  Maybe in more general, no matter the BPI is enabled or
> not, a new state for the case that CM is registrationComplete but network
> access has being disabled by operator/system administrator.
>
> Thanks!
> Minnie
>
> At 01:14 PM 6/17/2003 -0400, Joe Godas wrote:
> >"urn:schemas-microsoft-com:office:office" xmlns:w =
> >"urn:schemas-microsoft-com:office:word">
> >Hi,
> ><I hope I'm not missing something obvious ;>
> >
> >Regarding Item 12 (docsIfCmtsCmStatusValue)and its relation to BPI
> >state....I am concerned that we haven't captured the case where a modem
> >has successfully negotiated BPI but it's network access has been
disabled.
> >
> >Implementation example: on a Cisco CMTS a BPI enabled voice product would
> >look like this:
> >ubr110.cmts.hcvlny#scm | inc pt
> ><snip>
> >MAC Address    IP Address      I/F       MAC         Prim
> >RxPwr  Timing  Num BPI
> >                                          State       Sid  (db)   Offset
> > CPE Enb
> >0008.0e72.1e30 10.13.18.73     C3/0/U0   online(pt)  6899
> >0.75   1946    0   Y
> >
> >This modem is showing as online (with BPI) whether or not it's network
> >access has been disabled due to customer not paying their bill.
> >
> >Is there a response code in the Mib that reflects this BPI negotiated
> >(with data disabled) state or do we have to rely on querying the
> >forwarding state of the actual CM?
> >
> >Thanks,
> >Joe Godas
> >Cablevision
> >
> >
> >----- Original Message -----
> >From: <mailto:david.raftus@Terayon.com>Raftus, David
> >To: <mailto:Richard_Woundy@cable.comcast.com>Rich Woundy (Work) (E-mail)
;
> ><mailto:'milu@cisco.com'>'milu@cisco.com' ;
> ><mailto:'stevem@com21.com'>'stevem@com21.com' ;
> ><mailto:'mdolas@broadcom.com'>'mdolas@broadcom.com' ;
> ><mailto:'jdemarty@juniper.net'>'jdemarty@juniper.net' ;
> ><mailto:'e.cardona@cablelabs.com'>'e.cardona@cablelabs.com' ;
> ><mailto:'g.white@cablelabs.com'>'g.white@cablelabs.com' ;
> ><mailto:'john.gillis@adc.com'>'john.gillis@adc.com' ;
> ><mailto:'lucy.pollak@ti.com'>'lucy.pollak@ti.com' ;
> ><mailto:'alexb@coresma.com'>'alexb@coresma.com' ;
> ><mailto:'david.white@arrisi.com'>'david.white@arrisi.com' ;
> ><mailto:'matt.schmitt@arrisi.com'>'matt.schmitt@arrisi.com' ;
> ><mailto:'kfriedman@correlant.com'>'kfriedman@correlant.com' ;
> ><mailto:'fred@stargus.com'>'fred@stargus.com' ;
> ><mailto:'joe@kar-el.cvnet.com'>'joe@kar-el.cvnet.com' ;
> ><mailto:'W.Murwin@motorola.com'>'W.Murwin@motorola.com' ;
> ><mailto:'ASundelin@stargus.com'>'ASundelin@stargus.com' ;
> ><mailto:'vhou@juniper.net'>'vhou@juniper.net'
> >Cc: <mailto:docsis-20@cablelabs.com>Docsis 20 Reflector (E-mail) ;
> ><mailto:docsis-oss@cablelabs.com>Docsis Oss Reflector (E-mail) ;
> ><mailto:ipcdn@ietf.org>Ipcdn List (E-mail) ;
> ><mailto:david.raftus@Terayon.com>Raftus, David
> >Sent: Tuesday, June 17, 2003 11:36 AM
> >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
> >************************************
> >
> >
>
>



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



From exim@www1.ietf.org  Tue Jun 17 17:08:30 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11674
	for <ipcdn-archive@odin.ietf.org>; Tue, 17 Jun 2003 17:08:30 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5HL81O09995
	for ipcdn-archive@odin.ietf.org; Tue, 17 Jun 2003 17:08:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SNgO-0002ae-R8; Tue, 17 Jun 2003 17:08:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SKbv-0001DS-7I
	for ipcdn@optimus.ietf.org; Tue, 17 Jun 2003 13:51:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28025
	for <ipcdn@ietf.org>; Tue, 17 Jun 2003 13:51:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SKZf-0002BR-00
	for ipcdn@ietf.org; Tue, 17 Jun 2003 13:48:51 -0400
Received: from sj-core-1.cisco.com ([171.71.177.237])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SKZe-0002B4-00
	for ipcdn@ietf.org; Tue, 17 Jun 2003 13:48:50 -0400
Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5HHnOTa005658;
	Tue, 17 Jun 2003 10:49:24 -0700 (PDT)
Received: from milu-w2k.cisco.com (dhcp-171-71-51-93.cisco.com [171.71.51.93])
	by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR)
	with ESMTP id AIM13419;
	Tue, 17 Jun 2003 10:49:23 -0700 (PDT)
Message-Id: <4.3.2.7.2.20030617104343.021cb958@mira-sjc5-1.cisco.com>
X-Sender: milu@mira-sjc5-1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 17 Jun 2003 10:49:22 -0700
To: Joe Godas <joe@kar-el.cvnet.com>
From: Minnie Lu <milu@cisco.com>
Cc: "Raftus, David" <david.raftus@Terayon.com>,
        "Rich Woundy (Work) (E-mail)" <Richard_Woundy@cable.comcast.com>,
        milu@cisco.com, stevem@com21.com, mdolas@broadcom.com,
        jdemarty@juniper.net, e.cardona@cablelabs.com, g.white@cablelabs.com,
        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, W.Murwin@motorola.com,
        ASundelin@stargus.com, vhou@juniper.net,
        "Docsis 20 Reflector (E-mail)" <docsis-20@cablelabs.com>,
        "Docsis Oss Reflector (E-mail)" <docsis-oss@cablelabs.com>,
        "Ipcdn List (E-mail)" <ipcdn@ietf.org>,
        "Raftus, David" <david.raftus@Terayon.com>
In-Reply-To: <007201c334f4$04ba7920$1a02a8c0@IBM>
References: <E54A98375651D511816A00306E06B970C4A51A@OTNOAMEXCH01>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [ipcdn] Re: rf mib draft v6 to draft v7 suggestions
Sender: ipcdn-admin@ietf.org
Errors-To: ipcdn-admin@ietf.org
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=subscribe>

Hi, Joe,

Good suggestion.  Maybe in more general, no matter the BPI is enabled or 
not, a new state for the case that CM is registrationComplete but network 
access has being disabled by operator/system administrator.

Thanks!
Minnie

At 01:14 PM 6/17/2003 -0400, Joe Godas wrote:
>"urn:schemas-microsoft-com:office:office" xmlns:w = 
>"urn:schemas-microsoft-com:office:word">
>Hi,
><I hope I'm not missing something obvious ;>
>
>Regarding Item 12 (docsIfCmtsCmStatusValue)and its relation to BPI 
>state....I am concerned that we haven't captured the case where a modem 
>has successfully negotiated BPI but it's network access has been disabled.
>
>Implementation example: on a Cisco CMTS a BPI enabled voice product would 
>look like this:
>ubr110.cmts.hcvlny#scm | inc pt
><snip>
>MAC Address    IP Address      I/F       MAC         Prim 
>RxPwr  Timing  Num BPI
>                                          State       Sid  (db)   Offset 
> CPE Enb
>0008.0e72.1e30 10.13.18.73     C3/0/U0   online(pt)  6899 
>0.75   1946    0   Y
>
>This modem is showing as online (with BPI) whether or not it's network 
>access has been disabled due to customer not paying their bill.
>
>Is there a response code in the Mib that reflects this BPI negotiated 
>(with data disabled) state or do we have to rely on querying the 
>forwarding state of the actual CM?
>
>Thanks,
>Joe Godas
>Cablevision
>
>
>----- Original Message -----
>From: <mailto:david.raftus@Terayon.com>Raftus, David
>To: <mailto:Richard_Woundy@cable.comcast.com>Rich Woundy (Work) (E-mail) ; 
><mailto:'milu@cisco.com'>'milu@cisco.com' ; 
><mailto:'stevem@com21.com'>'stevem@com21.com' ; 
><mailto:'mdolas@broadcom.com'>'mdolas@broadcom.com' ; 
><mailto:'jdemarty@juniper.net'>'jdemarty@juniper.net' ; 
><mailto:'e.cardona@cablelabs.com'>'e.cardona@cablelabs.com' ; 
><mailto:'g.white@cablelabs.com'>'g.white@cablelabs.com' ; 
><mailto:'john.gillis@adc.com'>'john.gillis@adc.com' ; 
><mailto:'lucy.pollak@ti.com'>'lucy.pollak@ti.com' ; 
><mailto:'alexb@coresma.com'>'alexb@coresma.com' ; 
><mailto:'david.white@arrisi.com'>'david.white@arrisi.com' ; 
><mailto:'matt.schmitt@arrisi.com'>'matt.schmitt@arrisi.com' ; 
><mailto:'kfriedman@correlant.com'>'kfriedman@correlant.com' ; 
><mailto:'fred@stargus.com'>'fred@stargus.com' ; 
><mailto:'joe@kar-el.cvnet.com'>'joe@kar-el.cvnet.com' ; 
><mailto:'W.Murwin@motorola.com'>'W.Murwin@motorola.com' ; 
><mailto:'ASundelin@stargus.com'>'ASundelin@stargus.com' ; 
><mailto:'vhou@juniper.net'>'vhou@juniper.net'
>Cc: <mailto:docsis-20@cablelabs.com>Docsis 20 Reflector (E-mail) ; 
><mailto:docsis-oss@cablelabs.com>Docsis Oss Reflector (E-mail) ; 
><mailto:ipcdn@ietf.org>Ipcdn List (E-mail) ; 
><mailto:david.raftus@Terayon.com>Raftus, David
>Sent: Tuesday, June 17, 2003 11:36 AM
>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
>************************************
>
>


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



From exim@www1.ietf.org  Tue Jun 17 17:57:03 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11669
	for <ipcdn-archive@odin.ietf.org>; Tue, 17 Jun 2003 17:08:29 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5HL81Z10016
	for ipcdn-archive@odin.ietf.org; Tue, 17 Jun 2003 17:08:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SNgP-0002av-9i; Tue, 17 Jun 2003 17:08:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SMas-0006bt-Tm
	for ipcdn@optimus.ietf.org; Tue, 17 Jun 2003 15:58:15 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08139
	for <ipcdn@ietf.org>; Tue, 17 Jun 2003 15:58:12 -0400 (EDT)
From: matt.schmitt@arrisi.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SMYe-0004KE-00
	for ipcdn@ietf.org; Tue, 17 Jun 2003 15:55:56 -0400
Received: from [63.86.75.188] (helo=saturn.arrisi.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SMYc-0004K4-00
	for ipcdn@ietf.org; Tue, 17 Jun 2003 15:55:54 -0400
To: Minnie Lu <milu@cisco.com>
Cc: alexb@coresma.com, ASundelin@stargus.com,
        "Raftus, David" <david.raftus@Terayon.com>, david.white@arrisi.com,
        "Docsis 20 Reflector (E-mail)" <docsis-20@cablelabs.com>,
        "Docsis Oss Reflector (E-mail)" <docsis-oss@cablelabs.com>,
        e.cardona@cablelabs.com, fred@stargus.com, g.white@cablelabs.com,
        "Ipcdn List (E-mail)" <ipcdn@ietf.org>, jdemarty@juniper.net,
        Joe Godas <joe@kar-el.cvnet.com>, john.gillis@adc.com,
        kfriedman@correlant.com, lucy.pollak@ti.com, mdolas@broadcom.com,
        milu@cisco.com,
        "Rich Woundy (Work) (E-mail)" <Richard_Woundy@cable.comcast.com>,
        stevem@com21.com, vhou@juniper.net, W.Murwin@motorola.com
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.9a  January 7, 2002
Message-ID: <OF0C1E27A0.CC93A5B8-ON87256D48.006CF9AC-87256D48.006DBD56@arrisi.com>
Date: Tue, 17 Jun 2003 13:57:56 -0600
X-MIMETrack: Serialize by Router on Saturn/Antec(Release 5.0.11  |July 24, 2002) at 06/17/2003
 01:58:12 PM,
	Serialize complete at 06/17/2003 01:58:12 PM
Content-Type: multipart/alternative; boundary="=_alternative 006DBD4F87256D48_="
Subject: [ipcdn] Re: rf mib draft v6 to draft v7 suggestions
Sender: ipcdn-admin@ietf.org
Errors-To: ipcdn-admin@ietf.org
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=subscribe>

This is a multipart message in MIME format.
--=_alternative 006DBD4F87256D48_=
Content-Type: text/plain; charset="us-ascii"

Minnie,
        I do have a slight concern with this.
        Right now, a CMTS does not need to track whether or not a modem 
has NACO enabled or disabled.  From the 1.1 RFI spec, section C.1.1.3: 
"The value of this field does not affect CMTS service flow operation and 
does not affect CMTS data forwarding operation. ... With respect to DOCSIS 
v1.1 provisioning, a CMTS should ignore the NACO value and allocate any 
service flows that have been authorized by the provisioning server."
        If the MIB were changed so that the CMTS has to indicate if NACO 
is disabled, then that's one additional thing a CMTS is going to have to 
track that it doesn't now.  It may well be a minor change, but then again 
it might not be, and that makes me hesitate.
        Additionally, NACO is enforced at the modem, not at the CMTS. 
Therefore, it might actually be more logical to check that state at the 
modem than at the CMTS.
        Just a couple of thoughts.

Matt





Minnie Lu <milu@cisco.com>
06/17/03 11:49 AM

 
        To:     Joe Godas <joe@kar-el.cvnet.com>
        cc:     "Raftus, David" <david.raftus@Terayon.com>, "Rich Woundy (Work) (E-mail)" 
<Richard_Woundy@cable.comcast.com>, milu@cisco.com, stevem@com21.com, 
mdolas@broadcom.com, jdemarty@juniper.net, e.cardona@cablelabs.com, 
g.white@cablelabs.com, 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, W.Murwin@motorola.com, 
ASundelin@stargus.com, vhou@juniper.net, "Docsis 20 Reflector (E-mail)" 
<docsis-20@cablelabs.com>, "Docsis Oss Reflector (E-mail)" 
<docsis-oss@cablelabs.com>, "Ipcdn List (E-mail)" <ipcdn@ietf.org>, 
"Raftus, David" <david.raftus@Terayon.com>
        Subject:        Re: rf mib draft v6 to draft v7 suggestions


Hi, Joe,

Good suggestion.  Maybe in more general, no matter the BPI is enabled or 
not, a new state for the case that CM is registrationComplete but network 
access has being disabled by operator/system administrator.

Thanks!
Minnie

At 01:14 PM 6/17/2003 -0400, Joe Godas wrote:
>"urn:schemas-microsoft-com:office:office" xmlns:w = 
>"urn:schemas-microsoft-com:office:word">
>Hi,
><I hope I'm not missing something obvious ;>
>
>Regarding Item 12 (docsIfCmtsCmStatusValue)and its relation to BPI 
>state....I am concerned that we haven't captured the case where a modem 
>has successfully negotiated BPI but it's network access has been 
disabled.
>
>Implementation example: on a Cisco CMTS a BPI enabled voice product would 

>look like this:
>ubr110.cmts.hcvlny#scm | inc pt
><snip>
>MAC Address    IP Address      I/F       MAC         Prim 
>RxPwr  Timing  Num BPI
>                                          State       Sid  (db)   Offset 
> CPE Enb
>0008.0e72.1e30 10.13.18.73     C3/0/U0   online(pt)  6899 
>0.75   1946    0   Y
>
>This modem is showing as online (with BPI) whether or not it's network 
>access has been disabled due to customer not paying their bill.
>
>Is there a response code in the Mib that reflects this BPI negotiated 
>(with data disabled) state or do we have to rely on querying the 
>forwarding state of the actual CM?
>
>Thanks,
>Joe Godas
>Cablevision
>
>
>----- Original Message -----
>From: <mailto:david.raftus@Terayon.com>Raftus, David
>To: <mailto:Richard_Woundy@cable.comcast.com>Rich Woundy (Work) (E-mail) ; 
><mailto:'milu@cisco.com'>'milu@cisco.com' ; 
><mailto:'stevem@com21.com'>'stevem@com21.com' ; 
><mailto:'mdolas@broadcom.com'>'mdolas@broadcom.com' ; 
><mailto:'jdemarty@juniper.net'>'jdemarty@juniper.net' ; 
><mailto:'e.cardona@cablelabs.com'>'e.cardona@cablelabs.com' ; 
><mailto:'g.white@cablelabs.com'>'g.white@cablelabs.com' ; 
><mailto:'john.gillis@adc.com'>'john.gillis@adc.com' ; 
><mailto:'lucy.pollak@ti.com'>'lucy.pollak@ti.com' ; 
><mailto:'alexb@coresma.com'>'alexb@coresma.com' ; 
><mailto:'david.white@arrisi.com'>'david.white@arrisi.com' ; 
><mailto:'matt.schmitt@arrisi.com'>'matt.schmitt@arrisi.com' ; 
><mailto:'kfriedman@correlant.com'>'kfriedman@correlant.com' ; 
><mailto:'fred@stargus.com'>'fred@stargus.com' ; 
><mailto:'joe@kar-el.cvnet.com'>'joe@kar-el.cvnet.com' ; 
><mailto:'W.Murwin@motorola.com'>'W.Murwin@motorola.com' ; 
><mailto:'ASundelin@stargus.com'>'ASundelin@stargus.com' ; 
><mailto:'vhou@juniper.net'>'vhou@juniper.net'
>Cc: <mailto:docsis-20@cablelabs.com>Docsis 20 Reflector (E-mail) ; 
><mailto:docsis-oss@cablelabs.com>Docsis Oss Reflector (E-mail) ; 
><mailto:ipcdn@ietf.org>Ipcdn List (E-mail) ; 
><mailto:david.raftus@Terayon.com>Raftus, David
>Sent: Tuesday, June 17, 2003 11:36 AM
>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
>************************************
>
>




--=_alternative 006DBD4F87256D48_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Minnie,</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; I do have a slight concern with this.</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Right now, a CMTS does not need to track whether or not a modem has NACO enabled or disabled. &nbsp;From the 1.1 RFI spec, section C.1.1.3: &quot;The value of this field does not affect CMTS service flow operation and does not affect CMTS data forwarding operation. ... With respect to DOCSIS v1.1 provisioning, a CMTS should ignore the NACO value and allocate any service flows that have been authorized by the provisioning server.&quot;</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; If the MIB were changed so that the CMTS has to indicate if NACO is disabled, then that's one additional thing a CMTS is going to have to track that it doesn't now. &nbsp;It may well be a minor change, but then again it might not be, and that makes me hesitate.</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Additionally, NACO is enforced at the modem, not at the CMTS. &nbsp;Therefore, it might actually be more logical to check that state at the modem than at the CMTS.</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Just a couple of thoughts.</font>
<br>
<br><font size=2 face="sans-serif">Matt</font>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>Minnie Lu &lt;milu@cisco.com&gt;</b></font>
<p><font size=1 face="sans-serif">06/17/03 11:49 AM</font>
<br>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;Joe Godas &lt;joe@kar-el.cvnet.com&gt;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;&quot;Raftus, David&quot; &lt;david.raftus@Terayon.com&gt;, &quot;Rich Woundy (Work) (E-mail)&quot; &lt;Richard_Woundy@cable.comcast.com&gt;, milu@cisco.com, stevem@com21.com, mdolas@broadcom.com, jdemarty@juniper.net, e.cardona@cablelabs.com, g.white@cablelabs.com, 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, W.Murwin@motorola.com, ASundelin@stargus.com, vhou@juniper.net, &quot;Docsis 20 Reflector (E-mail)&quot; &lt;docsis-20@cablelabs.com&gt;, &quot;Docsis Oss Reflector (E-mail)&quot; &lt;docsis-oss@cablelabs.com&gt;, &quot;Ipcdn List (E-mail)&quot; &lt;ipcdn@ietf.org&gt;, &quot;Raftus, David&quot; &lt;david.raftus@Terayon.com&gt;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;Re: rf mib draft v6 to draft v7 suggestions</font></table>
<br>
<br>
<br><font size=2 face="Courier New">Hi, Joe,<br>
<br>
Good suggestion. &nbsp;Maybe in more general, no matter the BPI is enabled or <br>
not, a new state for the case that CM is registrationComplete but network <br>
access has being disabled by operator/system administrator.<br>
<br>
Thanks!<br>
Minnie<br>
<br>
At 01:14 PM 6/17/2003 -0400, Joe Godas wrote:<br>
&gt;&quot;urn:schemas-microsoft-com:office:office&quot; xmlns:w = <br>
&gt;&quot;urn:schemas-microsoft-com:office:word&quot;&gt;<br>
&gt;Hi,<br>
&gt;&lt;I hope I'm not missing something obvious ;&gt;<br>
&gt;<br>
&gt;Regarding Item 12 (docsIfCmtsCmStatusValue)and its relation to BPI <br>
&gt;state....I am concerned that we haven't captured the case where a modem <br>
&gt;has successfully negotiated BPI but it's network access has been disabled.<br>
&gt;<br>
&gt;Implementation example: on a Cisco CMTS a BPI enabled voice product would <br>
&gt;look like this:<br>
&gt;ubr110.cmts.hcvlny#scm | inc pt<br>
&gt;&lt;snip&gt;<br>
&gt;MAC Address &nbsp; &nbsp;IP Address &nbsp; &nbsp; &nbsp;I/F &nbsp; &nbsp; &nbsp; MAC &nbsp; &nbsp; &nbsp; &nbsp; Prim <br>
&gt;RxPwr &nbsp;Timing &nbsp;Num BPI<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;State &nbsp; &nbsp; &nbsp; Sid &nbsp;(db) &nbsp; Offset <br>
&gt; CPE Enb<br>
&gt;0008.0e72.1e30 10.13.18.73 &nbsp; &nbsp; C3/0/U0 &nbsp; online(pt) &nbsp;6899 <br>
&gt;0.75 &nbsp; 1946 &nbsp; &nbsp;0 &nbsp; Y<br>
&gt;<br>
&gt;This modem is showing as online (with BPI) whether or not it's network <br>
&gt;access has been disabled due to customer not paying their bill.<br>
&gt;<br>
&gt;Is there a response code in the Mib that reflects this BPI negotiated <br>
&gt;(with data disabled) state or do we have to rely on querying the <br>
&gt;forwarding state of the actual CM?<br>
&gt;<br>
&gt;Thanks,<br>
&gt;Joe Godas<br>
&gt;Cablevision<br>
&gt;<br>
&gt;<br>
&gt;----- Original Message -----<br>
&gt;From: &lt;mailto:david.raftus@Terayon.com&gt;Raftus, David<br>
&gt;To: &lt;mailto:Richard_Woundy@cable.comcast.com&gt;Rich Woundy (Work) (E-mail) ; <br>
&gt;&lt;mailto:'milu@cisco.com'&gt;'milu@cisco.com' ; <br>
&gt;&lt;mailto:'stevem@com21.com'&gt;'stevem@com21.com' ; <br>
&gt;&lt;mailto:'mdolas@broadcom.com'&gt;'mdolas@broadcom.com' ; <br>
&gt;&lt;mailto:'jdemarty@juniper.net'&gt;'jdemarty@juniper.net' ; <br>
&gt;&lt;mailto:'e.cardona@cablelabs.com'&gt;'e.cardona@cablelabs.com' ; <br>
&gt;&lt;mailto:'g.white@cablelabs.com'&gt;'g.white@cablelabs.com' ; <br>
&gt;&lt;mailto:'john.gillis@adc.com'&gt;'john.gillis@adc.com' ; <br>
&gt;&lt;mailto:'lucy.pollak@ti.com'&gt;'lucy.pollak@ti.com' ; <br>
&gt;&lt;mailto:'alexb@coresma.com'&gt;'alexb@coresma.com' ; <br>
&gt;&lt;mailto:'david.white@arrisi.com'&gt;'david.white@arrisi.com' ; <br>
&gt;&lt;mailto:'matt.schmitt@arrisi.com'&gt;'matt.schmitt@arrisi.com' ; <br>
&gt;&lt;mailto:'kfriedman@correlant.com'&gt;'kfriedman@correlant.com' ; <br>
&gt;&lt;mailto:'fred@stargus.com'&gt;'fred@stargus.com' ; <br>
&gt;&lt;mailto:'joe@kar-el.cvnet.com'&gt;'joe@kar-el.cvnet.com' ; <br>
&gt;&lt;mailto:'W.Murwin@motorola.com'&gt;'W.Murwin@motorola.com' ; <br>
&gt;&lt;mailto:'ASundelin@stargus.com'&gt;'ASundelin@stargus.com' ; </font>
<br><font size=2 face="Courier New">&gt;&lt;mailto:'vhou@juniper.net'&gt;'vhou@juniper.net'<br>
&gt;Cc: &lt;mailto:docsis-20@cablelabs.com&gt;Docsis 20 Reflector (E-mail) ; <br>
&gt;&lt;mailto:docsis-oss@cablelabs.com&gt;Docsis Oss Reflector (E-mail) ; <br>
&gt;&lt;mailto:ipcdn@ietf.org&gt;Ipcdn List (E-mail) ; <br>
&gt;&lt;mailto:david.raftus@Terayon.com&gt;Raftus, David<br>
&gt;Sent: Tuesday, June 17, 2003 11:36 AM<br>
&gt;Subject: rf mib draft v6 to draft v7 suggestions<br>
&gt;<br>
&gt;Hi everyone,<br>
&gt;<br>
&gt;Since RF mib v2 draft 6 was released in March, I have received publicly or <br>
&gt;privately 17 requests for updates/changes to appear in draft v7. The <br>
&gt;people on the To: list have participated in either initiating or <br>
&gt;commenting on the suggestions.<br>
&gt;<br>
&gt;Could I ask these people to please verify their suggestions as they are <br>
&gt;listed below? This mib update from v6 to v7 is extensive - want to ensure <br>
&gt;data is accurate before undertaking. The wider communities are also <br>
&gt;welcome to comment.<br>
&gt;<br>
&gt;Thanks for your time,<br>
&gt;Dave<br>
&gt;<br>
&gt;<br>
&gt;1) Return name to pre draft v6 DOCS-IF-MIB from draft v6 DOCS-IETF-RFI-MIB.<br>
&gt;<br>
&gt;Contributors - Rich Woundy IPCDN/Comcast, Minnie Lu Cisco, Steve Malenfant <br>
&gt;Com21<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;2) docsIfCmtsChannelUtUtilization formula - remove line (100 * ((raw bytes <br>
&gt;- stuffed bytes) / raw bytes))<br>
&gt;since it assumes that MPEG payload consists only DOC MAC payload. As we<br>
&gt;know, MPEG could consist video payload and NULL packets. Suggest to remove<br>
&gt;this line since the first 2 lines in the formula are good enough.<br>
&gt;<br>
&gt;Contributor - Minnie Lu &nbsp; &nbsp;Cisco<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;3) Add discontinuity descriptions to all counters related to an interface.<br>
&gt;<br>
&gt;Contributor - Minnie Lu &nbsp; &nbsp;Cisco<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;4) docsIfCmtsInsertInterval - For the docsIfCmtsInsertInterval object, <br>
&gt;there is no such thing as a<br>
&gt;&quot;broadcast station maintenance&quot; interval for new modems joining the <br>
&gt;network. &nbsp; Station should be<br>
&gt;changed to initial to make the text read - &quot;The amount of time to elapse <br>
&gt;between each broadcast<br>
&gt;initial maintenance grant. &nbsp;Broadcast initial maintenance grants are used <br>
&gt;to allow new cable modems<br>
&gt;to join the network. &nbsp;Zero indicates that a vendor-specific algorithm is <br>
&gt;used instead of a fixed time.<br>
&gt;Maximum amount of time permitted by the specification is 2 seconds.&quot;<br>
&gt;<br>
&gt;Contributor - Margo Dolas Broadcom<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;5) docsIfCmtsModPreambleType - (Joel) In docsIfCmtsModulationTable, the <br>
&gt;docsIfCmtsModPreambleType object has<br>
&gt;2 possible values qpsk0(1) and qpsk1(2). It seems like it's the only <br>
&gt;object in this table without a<br>
&gt;meaningful default value when this parameter does not make sense. For <br>
&gt;instance, for a TDMA modulation<br>
&gt;profile using QAM16, the actual preamble type is indeed not QPSK0 but <br>
&gt;something else. Does it make sense<br>
&gt;to have a value of 0 in this case, like <br>
&gt;docsIfCmtsModScdmaInterleaverStepSize for non-SCDMA profiles?<br>
&gt;<br>
&gt;(Eduardo) for the benefit of clarifications wouldn't be good to have a <br>
&gt;enumeration unknown(0) for this<br>
&gt;object when not a 2.0 burst ?<br>
&gt;Also a note in the DESCRIPTION like &quot;if docsIfCmtsModChannelType is <br>
&gt;tdma(1) a value unknown(0) is used for this object&quot;<br>
&gt;I would say unknown(0) rather than unknown(3) since it looks like the <br>
&gt;possible current implementation may be reporting<br>
&gt;'0' , and defendable in IETF since RFC 3291 uses '0' for inetAddressType<br>
&gt;<br>
&gt;Contributors - Joel Demarty Juniper, Eduardo Cardona Cablelabs<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;6) docsIfUpstreamChannelTable clone mechanism - improve descriptive <br>
&gt;wording. The spec is vague about the minimum set of parameters<br>
&gt;that the<br>
&gt;CMTS must transfer during a clone operation to be DOCSIS 2.0 compliant. <br>
&gt;Only those starting with docsIfUpChannelScdma or<br>
&gt;all parameters defining an SCDMA channel, like the channel width? Then <br>
&gt;what about the frequency?<br>
&gt;Definitely, this clone mechanism is sophisticated enough that it would <br>
&gt;deserve a more detailed specification<br>
&gt;(and testing) and, as a consequence, an ECR.<br>
&gt;<br>
&gt;Contributor - Joel Demarty Juniper<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;7) docsIfUpChannelPreEqEnable - add DEFVAL clause.<br>
&gt;<br>
&gt;Contributor - John Gillis ADC<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;8) docsIfCmtsUpChnlCtrUcastGrantedMslots - In Cisco CMTS, we use IUC14 <br>
&gt;(reserved) and SID (HEX): 1FFF (max. of<br>
&gt;unicast sid number) for quite some time.<br>
&gt;Q: Should it be counted in docsIfCmtsUpChnlCtrUcastGrantedMslots ?<br>
&gt;My personal think that this objects seems to mean the<br>
&gt;meaningful &nbsp;UNICAST SID, so user could get a good idea about the how many<br>
&gt;minislots really assigned to some meaningful CM. &nbsp;So, the reserved IUCs<br>
&gt;should be excluded from this object though minislots for reserved IUCs are<br>
&gt;still be counted into docsIfCmtsUpChnlCtrTotalMslots.<br>
&gt;Minnie,<br>
&gt;I agree, I think IUC14 grants to SID 1FFF (assuming the CMTS reserves<br>
&gt;that SID to mean no CM) should not be counted in UcastGrantedMslots.<br>
&gt;I also think (and maybe this case is more obvious) than grants to SID 0<br>
&gt;should not be counted in UcastGrantedMslots.<br>
&gt;This brings up a question that I've had for some time. &nbsp;Why does the<br>
&gt;Cisco CMTS use IUC14 and SID 1FFF???? &nbsp;The use of IUC14 is prohibited by<br>
&gt;the spec, since it is labeled as &quot;Reserved&quot;, and SID 0 is already<br>
&gt;defined to mean &quot;no CM&quot;.<br>
&gt;-Greg<br>
&gt;<br>
&gt;Contributors - Minnie Lu Cisco, Greg White Cablelabs<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;9) docsIfCmStatusTable - possibly add new objects for successful/failed <br>
&gt;ucc transactions.<br>
&gt;Hi, Alex,<br>
&gt;I do not think that this is good idea. What will you count into<br>
&gt;docsQosDCCAcks? The relationships between DCC Req/Rsp/Ack is important and<br>
&gt;should not be lost because of UCC additions. I guess, the better place for<br>
&gt;this counters is RFI MIB docsIfCmStatusTable. It may be extended in future<br>
&gt;versions.<br>
&gt;Regards.<br>
&gt;Lucy<br>
&gt;Hello all,<br>
&gt;A question about counting successful and failed UCC transactions.<br>
&gt;It seems like there is no counters dedicated for UCC failed or<br>
&gt;succeeded operation as it is for DCC transactions.<br>
&gt;The question is, since UCC is a subset of DCC operation for 1.1 modem,<br>
&gt;should the modem count UCC transactions in DCC counters (docsQosDCCs,<br>
&gt;docsQosDCCFails) ?<br>
&gt;Thank you in advance.<br>
&gt;<br>
&gt;Contributors - Lucy Pollak TI, Alex Betis Coresma<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;10) docsIfUpChannelPreEqEnable, docsIfCmStatusEqualizationData - clarify <br>
&gt;descriptions.<br>
&gt;Lucy,<br>
&gt;Sorry for the delay in responding. &nbsp;I don't have an objection to your <br>
&gt;proposal, as long as the<br>
&gt;format of the object is clear.<br>
&gt;To summarize, the object docsIfCmStatusEqualizationData will only include <br>
&gt;the &quot;value&quot; from figure 8-23.<br>
&gt;In other words, the first byte reported in the MIB object will be the main <br>
&gt;tap location. &nbsp;A clarification<br>
&gt;should also be made to the description of docsIfUpChannelPreEqEnable to <br>
&gt;indicate your interpretation (b).<br>
&gt;Regarding the question about reverse taps, figure 8-23 is a simplification <br>
&gt;of figure 6-23 from the 1.1 RFI<br>
&gt;spec (which includes a format to encode reverse taps). &nbsp;It seems to make <br>
&gt;sense to me to use the format<br>
&gt;shown in that figure. &nbsp;Perhaps this MIB object could be clarified to <br>
&gt;reference both figures.<br>
&gt;-Greg<br>
&gt;<br>
&gt;Greg,<br>
&gt;to summarize our objections:<br>
&gt;1. MIB requires equalization data, then type/length is irrelevant.<br>
&gt;2. There are 2 possible types 4 (Transmit Equalization Adjust) or 9 <br>
&gt;(Transmit Equalization Set), which is<br>
&gt;irrelevant after convolution.<br>
&gt;3. To be consistent with DS equa data, some TLV should be added also into <br>
&gt;it. What?<br>
&gt;We propose to use only value from referenced figure without type/length to <br>
&gt;avoid questions in the future. If not,<br>
&gt;(2) and (3) should be clarified. I guess, that it will be also very <br>
&gt;helpful if clarification (b) will be entered into MIB.<br>
&gt;Best Regards.<br>
&gt;Lucy<br>
&gt;<br>
&gt;Contributors - Lucy Pollak TI, Greg White Cablelabs<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;11) docsIfSignalQualityEntry - clarify wording for back compatibility.<br>
&gt;In draft -03 the description of &nbsp;docsIfSignalQualityEntry was changed<br>
&gt;from :<br>
&gt;docsIfSignalQualityEntry OBJECT-TYPE<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;SYNTAX &nbsp; &nbsp; &nbsp;DocsIfSignalQualityEntry<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;MAX-ACCESS &nbsp;not-accessible<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;STATUS &nbsp; &nbsp; &nbsp;current<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;DESCRIPTION<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&quot;At the CM, describes the PHY characteristics of a<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; downstream channel. At the CMTS, describes the PHY<br>
&gt;signal<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; quality of an upstream channel.<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; An entry in this table exists for each ifEntry with an<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ifType of docsCableUpstream(129) for Cable Modem<br>
&gt;Termination<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Systems and docsCableDownstream(128) for Cable Modems.&quot;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INDEX { ifIndex }</font>
<br><font size=2 face="Courier New">&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;::= { docsIfSignalQualityTable 1 }<br>
&gt;to :<br>
&gt;docsIfSignalQualityEntry OBJECT-TYPE<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; SYNTAX &nbsp; &nbsp; &nbsp;DocsIfSignalQualityEntry<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; MAX-ACCESS &nbsp;not-accessible<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; STATUS &nbsp; &nbsp; &nbsp;current<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; DESCRIPTION<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &quot;At the CM, describes the PHY characteristics of a<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;downstream channel. At the CMTS, describes the PHY signal<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;quality of an upstream channel.<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;An entry in this table exists for each ifEntry with an<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;ifType of docsCableUpstreamChannel(205) for Cable Modem<br>
&gt;Termination<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Systems and docsCableDownstream(128) for Cable Modems.&quot;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; INDEX { ifIndex }<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; ::= { docsIfSignalQualityTable 1 }<br>
&gt;But now RFI mib also apply to 1.1 CMTSes with no concept of ifType 205<br>
&gt;but 129<br>
&gt;<br>
&gt;Contributor - Eduardo Cardona Cablelabs<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;12) docsIfCmtsCmStatusValue - add new defined value <br>
&gt;registeredBPIInitializing(9),<br>
&gt;deprecate former value operational(8).<br>
&gt;<br>
&gt;Contributors - Eduardo Cardona Cablelabs, Lucy Pollak TI, Minnie Lu Cisco, <br>
&gt;David White Arris,<br>
&gt;Matt Schmitt Arris, Kirk Friedman Correlant, Fred Oko Stargus, Joe Godas <br>
&gt;Kar-el, Steve Malenfant Com21<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;13) Adjust compliance statements for objects designated optional. Add <br>
&gt;separate augmentation table for<br>
&gt;optional objects in docsIfCmtsUpChannelCounterTable.<br>
&gt;<br>
&gt;Contributors - Will Murwin Motorola, Rich Woundy IPCDN/Comcast, Mike <br>
&gt;StJohns Mindspring, Eduardo Cardona Cablelabs<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;14) Add section explaining counter interaction between Docsis 1.0/1.1/2.0.<br>
&gt;The QOS MIB tried to handle<br>
&gt;DOCSIS 1.1 changes to RFC2670. Now that rfc2670 is being obsoleted, the <br>
&gt;rf-mib v2 and the DOCSIS OSS Specs is the place<br>
&gt;that should clearly state how these counters and other tables interact in <br>
&gt;DOCSIS 1.0, DOCSIS 1.1, and DOCSIS 2.0.<br>
&gt;I would even hope to see a section in the rf-mib v2, &quot;Interoperation with <br>
&gt;the version of DOCSIS&quot; like or to replace<br>
&gt;what the DOCSIS QOS MIB has. This is the place to describe what table are <br>
&gt;populated under the docsIfMib when the<br>
&gt;the modems are registering.<br>
&gt;This way this issue can be re-discussed and whatever conculsion is <br>
&gt;reached, can be document in the description of those<br>
&gt;objects.<br>
&gt;<br>
&gt;Contributor - Will Murwin Motorola, Minnie Lu Cisco<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;15) Change docsIfCmtsServiceTable to count packets for both upstream and <br>
&gt;downstream flows.<br>
&gt;One of the things that has long been an issue with the RF MIB is that the <br>
&gt;docsIfCmtsServiceTable only counts<br>
&gt;InOctets and InPackets (i.e. upstream packets only). If the reason for <br>
&gt;keeping this table is to support DOCSIS<br>
&gt;1.0 modems would it also make sense to add downstream packet counts to <br>
&gt;this table, too? Many CMTS'es already<br>
&gt;count this information and store it in a proprietary MIB. It would be nice <br>
&gt;to standardize this as a requirement<br>
&gt;so that NMS such as usage monitoring systems could (a) count on it <br>
&gt;existing and (b) find it in a standard location.<br>
&gt;<br>
&gt;Contributor - Andrew Sundelin Stargus<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;16) Add 4 objects to docsIfCmtsCmStatusTable<br>
&gt;While writing DOCS-IETF-QOS-MIB version 9, I find myself still thinking <br>
&gt;about Minnie suggestion of having<br>
&gt;docsIfCmtsServiceInPackets and docsIfCmtsServiceInOctets count for DOCSIS <br>
&gt;1.1 and 2.0. Even though the QOS<br>
&gt;MIB has pawned off this discussion, I have had some thoughts on the subject.<br>
&gt;(1) If these counters where used to count the DOCSIS 1.1 and 2.0, than <br>
&gt;this would the best place in all<br>
&gt;of the mibs to<br>
&gt; &nbsp; &nbsp; get a quick summary of the upstream data received by a particular <br>
&gt; modem, no matter the version.<br>
&gt;(2) At the same time, The rest of the docsIfCmtsCmServiceTable might not <br>
&gt;make sense for DOCSIS 1.1 or 2.0<br>
&gt;However the more I looked around at the different counters that existed in <br>
&gt;all of MIB required by DOCSIS,<br>
&gt;the more I kept looking for an overall counter on the CMTS to count data <br>
&gt;packet received and transmitted<br>
&gt;for a particular CM.<br>
&gt;I would like to start a discussion on about adding 4 new object to the <br>
&gt;docsIfCmtsCmStatusTable:<br>
&gt;docsIfCmtsCmStatusInPackets<br>
&gt;docsIfCmtsCmStatusInOctets<br>
&gt;docsIfCmtsCmStatusOutPackets<br>
&gt;docsIfCmtsCmStatusOutoctets<br>
&gt;While I understand that these counts can be gathered by via numerous <br>
&gt;objects on both the CMTS and CM<br>
&gt;and then just appling simple math. However I want to query only one agent <br>
&gt;and just get a quick summary<br>
&gt;without have to determine which version of DOCSIS the modem is, which will <br>
&gt;determine which mibs I look etc.<br>
&gt;and objects I query.<br>
&gt;<br>
&gt;For example if I want query only one agent(i.e. the CMTS) and get the <br>
&gt;number of transmitted and received<br>
&gt;data for each CM, then<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp;(1) GET-NEXT the docsIfCmtsCmStatusRegMode to see what version of <br>
&gt; DOCSIS this modem is operting<br>
&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp;if 'docsis10(1)' then<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;(2) WALK the entire docsIfCmtsServiceTable for <br>
&gt; ifIndex and SID that<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;have docsIfCmtsServiceNewCmStatusIndex that <br>
&gt; matches the index for step (1).<br>
&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;(3) Add the all the instances of <br>
&gt; docsIfCmtsServiceInPacket for the<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;ifIndex and SIDs that match from step(2) to get <br>
&gt; the total Received packets from a CM.<br>
&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;NOTE: Not sure it is possible to get from a CMTS <br>
&gt; agent from the Standard MIBs the number of<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;of packets transmitted to a single docsis 1.0 <br>
&gt; cable modem.<br>
&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp;else if 'docsis11(2)' or 'docsis20()' then<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;(2) WALK the docsQosCmtsMacToSrvFlowTable all for <br>
&gt; the instances of that contain the<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;same mac address.<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;(3) Then GET the docQosServiceFlowPkts using the <br>
&gt; ifIndex and<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; service flow id from step(2). Add this to the total <br>
&gt; of received or transmitted for this CM.<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;To determine the direction of the flow use the <br>
&gt; same index and query the docsQosServiceFlowDirection.<br>
&gt;This seems very complicated for something so simple. This is just a <br>
&gt;suggestion of simple way the RF MIB v2 can correct the<br>
&gt;mistakes of the past.<br>
&gt;<br>
&gt;Contributors - Will Murwin Motorola, Minnie Lu Cisco<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;17) docsIfCmtsCmStatusTimingOffset - possibly change decription of <br>
&gt;existing object or<br>
&gt;add new object to reconcile unit differences between 1.1/2.0. Still under <br>
&gt;discussion.<br>
&gt;<br>
&gt;Contributors - Victor Hou Juniper, Rich Woundy IPCDN/Comcast, Kirk <br>
&gt;Friedman Correlant.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;************************************<br>
&gt;David Raftus<br>
&gt;Terayon Canada Ltd<br>
&gt;340 Terry Fox Drive, Suite 202<br>
&gt;Ottawa Canada &nbsp;K2K 3A2<br>
&gt;<br>
&gt;david.raftus@terayon.com<br>
&gt;613.592.1052 &nbsp;ext 222<br>
&gt;************************************<br>
&gt;<br>
&gt;<br>
<br>
</font>
<br>
<br>
--=_alternative 006DBD4F87256D48_=--

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



From exim@www1.ietf.org  Tue Jun 17 17:57:04 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11668
	for <ipcdn-archive@odin.ietf.org>; Tue, 17 Jun 2003 17:08:29 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5HL81009993
	for ipcdn-archive@odin.ietf.org; Tue, 17 Jun 2003 17:08:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SNgO-0002aW-Jy; Tue, 17 Jun 2003 17:08:00 -0400
Received: from lists.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus with esmtp (Exim 4.20)
	id 19SK3o-0004Hs-9U
	for ipcdn@optimus.ietf.org; Tue, 17 Jun 2003 13:15:56 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26954
	for <ipcdn@ietf.org>; Tue, 17 Jun 2003 13:15:52 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SK1Z-0001v1-00
	for ipcdn@ietf.org; Tue, 17 Jun 2003 13:13:37 -0400
Received: from kar-el.eng.cv.net ([167.206.9.41] helo=kar-el.cvnet.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SK1Y-0001uc-00
	for ipcdn@ietf.org; Tue, 17 Jun 2003 13:13:36 -0400
Received: from IBM (localhost [127.0.0.1])
 by kar-el.cvnet.com (iPlanet Messaging Server 5.1 (built May  7 2001))
 with SMTP id <0HGM00769YATBR@kar-el.cvnet.com> for ipcdn@ietf.org; Tue,
 17 Jun 2003 13:08:56 -0400 (EDT)
Date: Tue, 17 Jun 2003 13:14:46 -0400
From: Joe Godas <joe@kar-el.cvnet.com>
To: "Raftus, David" <david.raftus@Terayon.com>,
        "Rich Woundy (Work) (E-mail)" <Richard_Woundy@cable.comcast.com>,
        milu@cisco.com, stevem@com21.com, mdolas@broadcom.com,
        jdemarty@juniper.net, e.cardona@cablelabs.com, g.white@cablelabs.com,
        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, W.Murwin@motorola.com,
        ASundelin@stargus.com, vhou@juniper.net
Cc: "Docsis 20 Reflector (E-mail)" <docsis-20@cablelabs.com>,
        "Docsis Oss Reflector (E-mail)" <docsis-oss@cablelabs.com>,
        "Ipcdn List (E-mail)" <ipcdn@ietf.org>,
        "Raftus, David" <david.raftus@Terayon.com>
Message-id: <007201c334f4$04ba7920$1a02a8c0@IBM>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
Content-type: multipart/alternative;
 boundary="Boundary_(ID_O1ha9TV6poqCUsqB0mWm4A)"
X-Priority: 3
X-MSMail-priority: Normal
References: <E54A98375651D511816A00306E06B970C4A51A@OTNOAMEXCH01>
Subject: [ipcdn] Re: rf mib draft v6 to draft v7 suggestions
Sender: ipcdn-admin@ietf.org
Errors-To: ipcdn-admin@ietf.org
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

--Boundary_(ID_O1ha9TV6poqCUsqB0mWm4A)
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7BIT

Hi,
<I hope I'm not missing something obvious ;>

Regarding Item 12 (docsIfCmtsCmStatusValue)and its relation to BPI state....I am concerned that we haven't captured the case where a modem has successfully negotiated BPI but it's network access has been disabled. 

Implementation example: on a Cisco CMTS a BPI enabled voice product would look like this:
ubr110.cmts.hcvlny#scm | inc pt
<snip>
MAC Address    IP Address      I/F       MAC         Prim RxPwr  Timing  Num BPI
                                         State       Sid  (db)   Offset  CPE Enb
0008.0e72.1e30 10.13.18.73     C3/0/U0   online(pt)  6899 0.75   1946    0   Y 

This modem is showing as online (with BPI) whether or not it's network access has been disabled due to customer not paying their bill.

Is there a response code in the Mib that reflects this BPI negotiated (with data disabled) state or do we have to rely on querying the forwarding state of the actual CM?

Thanks,
Joe Godas
Cablevision


  ----- Original Message ----- 
  From: Raftus, David 
  To: Rich Woundy (Work) (E-mail) ; 'milu@cisco.com' ; 'stevem@com21.com' ; 'mdolas@broadcom.com' ; 'jdemarty@juniper.net' ; 'e.cardona@cablelabs.com' ; 'g.white@cablelabs.com' ; '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 20 Reflector (E-mail) ; Docsis Oss Reflector (E-mail) ; Ipcdn List (E-mail) ; Raftus, David 
  Sent: Tuesday, June 17, 2003 11:36 AM
  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

  ************************************               

   

   


--Boundary_(ID_O1ha9TV6poqCUsqB0mWm4A)
Content-type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns="http://www.w3.org/TR/REC-html40" xmlns:o = 
"urn:schemas-microsoft-com:office:office" xmlns:w = 
"urn:schemas-microsoft-com:office:word"><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content=Word.Document name=ProgId>
<META content="MSHTML 6.00.2600.0" name=GENERATOR>
<META content="Microsoft Word 9" name=Originator><LINK 
href="cid:filelist.xml@01C334C4.C53BF0A0" rel=File-List><!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:View>Normal</w:View>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<STYLE>@page Section1 {size: 612.0pt 792.0pt; margin: 72.0pt 90.0pt 72.0pt 90.0pt; mso-header-margin: 36.0pt; mso-footer-margin: 36.0pt; mso-paper-source: 0; }
P.MsoNormal {
	FONT-SIZE: 9pt; MARGIN: 0pt; COLOR: black; FONT-FAMILY: Arial; mso-bidi-font-size: 12.0pt; mso-style-parent: ""; mso-pagination: widow-orphan; mso-fareast-font-family: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 9pt; MARGIN: 0pt; COLOR: black; FONT-FAMILY: Arial; mso-bidi-font-size: 12.0pt; mso-style-parent: ""; mso-pagination: widow-orphan; mso-fareast-font-family: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 9pt; MARGIN: 0pt; COLOR: black; FONT-FAMILY: Arial; mso-bidi-font-size: 12.0pt; mso-style-parent: ""; mso-pagination: widow-orphan; mso-fareast-font-family: "Times New Roman"
}
P.MsoAutoSig {
	FONT-SIZE: 9pt; MARGIN: 0pt; COLOR: black; FONT-FAMILY: Arial; mso-bidi-font-size: 12.0pt; mso-pagination: widow-orphan; mso-fareast-font-family: "Times New Roman"
}
LI.MsoAutoSig {
	FONT-SIZE: 9pt; MARGIN: 0pt; COLOR: black; FONT-FAMILY: Arial; mso-bidi-font-size: 12.0pt; mso-pagination: widow-orphan; mso-fareast-font-family: "Times New Roman"
}
DIV.MsoAutoSig {
	FONT-SIZE: 9pt; MARGIN: 0pt; COLOR: black; FONT-FAMILY: Arial; mso-bidi-font-size: 12.0pt; mso-pagination: widow-orphan; mso-fareast-font-family: "Times New Roman"
}
SPAN.EmailStyle15 {
	COLOR: black; mso-style-type: personal-compose; mso-ansi-font-size: 10.0pt; mso-ascii-font-family: Arial; mso-hansi-font-family: Arial; mso-bidi-font-family: Arial
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=EN-US style="tab-interval: 36.0pt" bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Hi,</FONT></DIV>
<DIV><FONT face=Arial size=2>&lt;I hope I'm not missing something obvious 
;&gt;</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>Regarding Item 12 (<FONT 
face="Courier New">docsIfCmtsCmStatusValue)and its relation to BPI state....I am 
concerned that we haven't captured the case where a modem has successfully 
negotiated BPI but it's network access has been disabled. </FONT></FONT></DIV>
<DIV><FONT face=Arial size=2><FONT face="Courier New"></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><FONT face="Courier New">Implementation example: on 
a Cisco CMTS a BPI enabled voice product would look like 
this:</FONT></FONT></DIV>
<DIV><FONT face=Arial size=2>ubr110.cmts.hcvlny#scm | inc 
pt<BR>&lt;snip&gt;</FONT></DIV>
<DIV><FONT face=Arial size=2>MAC Address&nbsp;&nbsp;&nbsp; IP 
Address&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I/F&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
MAC&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Prim RxPwr&nbsp; 
Timing&nbsp; Num 
BPI<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
State&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sid&nbsp; (db)&nbsp;&nbsp; 
Offset&nbsp; CPE Enb</FONT></DIV>
<DIV><FONT face=Arial size=2>0008.0e72.1e30 10.13.18.73&nbsp;&nbsp;&nbsp;&nbsp; 
C3/0/U0&nbsp;&nbsp; online(pt)&nbsp; 6899 0.75&nbsp;&nbsp; 
1946&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp; Y </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>This modem is showing as online (with BPI) whether 
or not it's network access has been disabled due to customer not paying their 
bill.</DIV>
<DIV><BR></FONT><FONT face=Arial size=2><FONT face="Courier New">Is there a 
response code in the Mib that reflects this BPI negotiated (with data disabled) 
state or do we have to rely on querying the forwarding state of the actual 
CM?</FONT></FONT></DIV>
<DIV><FONT face="Courier New" size=2></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" size=2>Thanks,</FONT></DIV>
<DIV><FONT face="Courier New" size=2>Joe Godas</FONT></DIV>
<DIV><FONT face="Courier New" size=2>Cablevision</FONT></DIV>
<DIV><FONT face="Courier New" size=2></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" size=2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV 
  style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B> 
  <A title=david.raftus@Terayon.com 
  href="mailto:david.raftus@Terayon.com">Raftus, David</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>To:</B> <A 
  title=Richard_Woundy@cable.comcast.com 
  href="mailto:Richard_Woundy@cable.comcast.com">Rich Woundy (Work) (E-mail)</A> 
  ; <A title=milu@cisco.com href="mailto:'milu@cisco.com'">'milu@cisco.com'</A> 
  ; <A title=stevem@com21.com 
  href="mailto:'stevem@com21.com'">'stevem@com21.com'</A> ; <A 
  title=mdolas@broadcom.com 
  href="mailto:'mdolas@broadcom.com'">'mdolas@broadcom.com'</A> ; <A 
  title=jdemarty@juniper.net 
  href="mailto:'jdemarty@juniper.net'">'jdemarty@juniper.net'</A> ; <A 
  title=e.cardona@cablelabs.com 
  href="mailto:'e.cardona@cablelabs.com'">'e.cardona@cablelabs.com'</A> ; <A 
  title=g.white@cablelabs.com 
  href="mailto:'g.white@cablelabs.com'">'g.white@cablelabs.com'</A> ; <A 
  title=john.gillis@adc.com 
  href="mailto:'john.gillis@adc.com'">'john.gillis@adc.com'</A> ; <A 
  title=lucy.pollak@ti.com 
  href="mailto:'lucy.pollak@ti.com'">'lucy.pollak@ti.com'</A> ; <A 
  title=alexb@coresma.com 
  href="mailto:'alexb@coresma.com'">'alexb@coresma.com'</A> ; <A 
  title=david.white@arrisi.com 
  href="mailto:'david.white@arrisi.com'">'david.white@arrisi.com'</A> ; <A 
  title=matt.schmitt@arrisi.com 
  href="mailto:'matt.schmitt@arrisi.com'">'matt.schmitt@arrisi.com'</A> ; <A 
  title=kfriedman@correlant.com 
  href="mailto:'kfriedman@correlant.com'">'kfriedman@correlant.com'</A> ; <A 
  title=fred@stargus.com href="mailto:'fred@stargus.com'">'fred@stargus.com'</A> 
  ; <A title=joe@kar-el.cvnet.com 
  href="mailto:'joe@kar-el.cvnet.com'">'joe@kar-el.cvnet.com'</A> ; <A 
  title=W.Murwin@motorola.com 
  href="mailto:'W.Murwin@motorola.com'">'W.Murwin@motorola.com'</A> ; <A 
  title=ASundelin@stargus.com 
  href="mailto:'ASundelin@stargus.com'">'ASundelin@stargus.com'</A> ; <A 
  title=vhou@juniper.net href="mailto:'vhou@juniper.net'">'vhou@juniper.net'</A> 
  </DIV>
  <DIV style="FONT: 10pt arial"><B>Cc:</B> <A title=docsis-20@cablelabs.com 
  href="mailto:docsis-20@cablelabs.com">Docsis 20 Reflector (E-mail)</A> ; <A 
  title=docsis-oss@cablelabs.com href="mailto:docsis-oss@cablelabs.com">Docsis 
  Oss Reflector (E-mail)</A> ; <A title=ipcdn@ietf.org 
  href="mailto:ipcdn@ietf.org">Ipcdn List (E-mail)</A> ; <A 
  title=david.raftus@Terayon.com href="mailto:david.raftus@Terayon.com">Raftus, 
  David</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> Tuesday, June 17, 2003 11:36 
  AM</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> rf mib draft v6 to draft v7 
  suggestions</DIV>
  <DIV><BR></DIV>
  <DIV class=Section1>
  <P class=MsoNormal style="mso-layout-grid-align: none"><SPAN 
  class=EmailStyle15><FONT face=Arial color=black size=2><SPAN 
  style="FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt">Hi 
  everyone,<o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=MsoNormal style="mso-layout-grid-align: none"><SPAN 
  class=EmailStyle15><FONT face=Arial color=black size=2><SPAN 
  style="FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt"><![if !supportEmptyParas]><![endif]>&nbsp;<o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=MsoNormal style="mso-layout-grid-align: none"><SPAN 
  class=EmailStyle15><FONT face=Arial color=black size=2><SPAN 
  style="FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt">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. 
  <o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=MsoNormal style="mso-layout-grid-align: none"><SPAN 
  class=EmailStyle15><FONT face=Arial color=black size=2><SPAN 
  style="FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt"><![if !supportEmptyParas]><![endif]>&nbsp;<o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=MsoNormal style="mso-layout-grid-align: none"><SPAN 
  class=EmailStyle15><FONT face=Arial color=black size=2><SPAN 
  style="FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt">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.<o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=MsoNormal style="mso-layout-grid-align: none"><SPAN 
  class=EmailStyle15><FONT face=Arial color=black size=2><SPAN 
  style="FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt"><![if !supportEmptyParas]><![endif]>&nbsp;<o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=MsoNormal style="mso-layout-grid-align: none"><SPAN 
  class=EmailStyle15><FONT face=Arial color=black size=2><SPAN 
  style="FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt">Thanks for your 
  time,<o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=MsoNormal style="mso-layout-grid-align: none"><SPAN 
  class=EmailStyle15><FONT face=Arial color=black size=2><SPAN 
  style="FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt">Dave<o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=MsoNormal style="mso-layout-grid-align: none"><FONT 
  face="Courier New" color=black size=1><SPAN 
  style="FONT-SIZE: 8.5pt; FONT-FAMILY: 'Courier New'"><![if !supportEmptyParas]><![endif]>&nbsp;</SPAN></FONT><FONT 
  face="Courier New" color=black size=1><SPAN 
  style="FONT-SIZE: 8.5pt; COLOR: black; FONT-FAMILY: 'Courier New'; mso-color-alt: windowtext"><o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal style="mso-layout-grid-align: none"><FONT 
  face="Courier New" color=black size=1><SPAN 
  style="FONT-SIZE: 8.5pt; FONT-FAMILY: 'Courier New'"><BR><BR>1) Return name to 
  pre draft v6 DOCS-IF-MIB from draft v6 DOCS-IETF-RFI-MIB. <BR><BR>Contributors 
  - Rich Woundy IPCDN/Comcast, Minnie Lu Cisco, Steve Malenfant 
  Com21<BR><BR><BR>2) docsIfCmtsChannelUtUtilization formula - remove line (100 
  * ((raw bytes - stuffed bytes) / raw bytes))<BR>since it assumes that MPEG 
  payload consists only DOC MAC payload. As we <BR>know, MPEG could consist 
  video payload and NULL packets. Suggest to remove <BR>this line since the 
  first 2 lines in the formula are good enough.<BR><BR>Contributor - Minnie 
  Lu<SPAN style="mso-tab-count: 1">&nbsp;&nbsp;&nbsp; </SPAN>Cisco<BR><BR><BR>3) 
  Add discontinuity descriptions to all counters related to an 
  interface.<BR><BR>Contributor - Minnie Lu<SPAN 
  style="mso-tab-count: 1">&nbsp;&nbsp;&nbsp; </SPAN>Cisco<BR><BR><BR>4) 
  docsIfCmtsInsertInterval - For the docsIfCmtsInsertInterval object, there is 
  no such thing as a <BR>"broadcast station maintenance" interval for new modems 
  joining the network.<SPAN style="mso-spacerun: yes">&nbsp;&nbsp; 
  </SPAN>Station should be <BR>changed to initial to make the text read - "The 
  amount of time to elapse between each broadcast <BR>initial maintenance 
  grant.<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>Broadcast initial 
  maintenance grants are used to allow new cable modems <BR>to join the 
  network.<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>Zero indicates that a 
  vendor-specific algorithm is used instead of a fixed time.<SPAN 
  style="mso-spacerun: yes">&nbsp; </SPAN><BR>Maximum amount of time permitted 
  by the specification is 2 seconds."<BR><BR>Contributor - Margo Dolas 
  Broadcom<BR><BR><BR>5) docsIfCmtsModPreambleType - (Joel) In 
  docsIfCmtsModulationTable, the docsIfCmtsModPreambleType object has <BR>2 
  possible values qpsk0(1) and qpsk1(2). It seems like it's the only object in 
  this table without a <BR>meaningful default value when this parameter does not 
  make sense. For instance, for a TDMA modulation <BR>profile using QAM16, the 
  actual preamble type is indeed not QPSK0 but something else. Does it make 
  sense <BR>to have a value of 0 in this case, like 
  docsIfCmtsModScdmaInterleaverStepSize for non-SCDMA profiles?<BR><BR>(Eduardo) 
  for the benefit of clarifications wouldn't be good to have a enumeration 
  unknown(0) for this <BR>object when not a 2.0 burst ?<BR>Also a note in the 
  DESCRIPTION like "if docsIfCmtsModChannelType is tdma(1) a value unknown(0) is 
  used for this object" <BR>I would say unknown(0) rather than unknown(3) since 
  it looks like the possible current implementation may be reporting<SPAN 
  style="mso-spacerun: yes">&nbsp; </SPAN><BR>'0' , and defendable in IETF since 
  RFC 3291 uses '0' for inetAddressType<BR><BR>Contributors - Joel Demarty 
  Juniper, Eduardo Cardona Cablelabs<BR><BR><BR>6) docsIfUpstreamChannelTable 
  clone mechanism - improve descriptive wording. The spec is vague about the 
  minimum set of parameters <BR>that the <BR>CMTS must transfer during a clone 
  operation to be DOCSIS 2.0 compliant. Only those starting with 
  docsIfUpChannelScdma or <BR>all parameters defining an SCDMA channel, like the 
  channel width? Then what about the frequency? <BR>Definitely, this clone 
  mechanism is sophisticated enough that it would deserve a more detailed 
  specification <BR>(and testing) and, as a consequence, an 
  ECR.<BR><BR>Contributor - Joel Demarty Juniper<BR><BR><BR>7) 
  docsIfUpChannelPreEqEnable - add DEFVAL clause.<BR><BR>Contributor - John 
  Gillis ADC<BR><BR><BR>8) docsIfCmtsUpChnlCtrUcastGrantedMslots - In Cisco 
  CMTS, we use IUC14 (reserved) and SID (HEX): 1FFF (max. of <BR>unicast sid 
  number) for quite some time.<BR>Q: Should it be counted in 
  docsIfCmtsUpChnlCtrUcastGrantedMslots ?<BR>My personal think that this objects 
  seems to mean the <BR>meaningful<SPAN style="mso-spacerun: yes">&nbsp; 
  </SPAN>UNICAST SID, so user could get a good idea about the how many 
  <BR>minislots really assigned to some meaningful CM.<SPAN 
  style="mso-spacerun: yes">&nbsp; </SPAN>So, the reserved IUCs <BR>should be 
  excluded from this object though minislots for reserved IUCs are <BR>still be 
  counted into docsIfCmtsUpChnlCtrTotalMslots.<BR>Minnie,<BR>I agree, I think 
  IUC14 grants to SID 1FFF (assuming the CMTS reserves<BR>that SID to mean no 
  CM) should not be counted in UcastGrantedMslots.<BR>I also think (and maybe 
  this case is more obvious) than grants to SID 0<BR>should not be counted in 
  UcastGrantedMslots.<BR>This brings up a question that I've had for some 
  time.<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>Why does the<BR>Cisco CMTS 
  use IUC14 and SID 1FFF????<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>The 
  use of IUC14 is prohibited by<BR>the spec, since it is labeled as "Reserved", 
  and SID 0 is already<BR>defined to mean "no CM".<BR>-Greg<BR><BR>Contributors 
  - Minnie Lu Cisco, Greg White Cablelabs<BR><BR><BR>9) docsIfCmStatusTable - 
  possibly add new objects for successful/failed ucc transactions. <BR>Hi, 
  Alex,<BR>I do not think that this is good idea. What will you count 
  into<BR>docsQosDCCAcks? The relationships between DCC Req/Rsp/Ack is important 
  and<BR>should not be lost because of UCC additions. I guess, the better place 
  for<BR>this counters is RFI MIB docsIfCmStatusTable. It may be extended in 
  future<BR>versions.<BR>Regards.<BR>Lucy<BR>Hello all,<BR>A question about 
  counting successful and failed UCC transactions.<BR>It seems like there is no 
  counters dedicated for UCC failed or<BR>succeeded operation as it is for DCC 
  transactions.<BR>The question is, since UCC is a subset of DCC operation for 
  1.1 modem,<BR>should the modem count UCC transactions in DCC counters 
  (docsQosDCCs,<BR>docsQosDCCFails) ?<BR>Thank you in 
  advance.<BR><BR>Contributors - Lucy Pollak TI, Alex Betis 
  Coresma<BR><BR><BR>10) docsIfUpChannelPreEqEnable, 
  docsIfCmStatusEqualizationData - clarify descriptions.<BR>Lucy,<BR>Sorry for 
  the delay in responding.<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>I don't 
  have an objection to your proposal, as long as the <BR>format of the object is 
  clear.<BR>To summarize, the object docsIfCmStatusEqualizationData will only 
  include the "value" from figure 8-23.<SPAN style="mso-spacerun: yes">&nbsp; 
  </SPAN><BR>In other words, the first byte reported in the MIB object will be 
  the main tap location.<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>A 
  clarification <BR>should also be made to the description of 
  docsIfUpChannelPreEqEnable to indicate your interpretation (b). <BR>Regarding 
  the question about reverse taps, figure 8-23 is a simplification of figure 
  6-23 from the 1.1 RFI <BR>spec (which includes a format to encode reverse 
  taps).<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>It seems to make sense to 
  me to use the format <BR>shown in that figure.<SPAN 
  style="mso-spacerun: yes">&nbsp; </SPAN>Perhaps this MIB object could be 
  clarified to reference both figures.<BR>-Greg<BR><BR>Greg,<BR>to summarize our 
  objections:<BR>1. MIB requires equalization data, then type/length is 
  irrelevant.<BR>2. There are 2 possible types 4 (Transmit Equalization Adjust) 
  or 9 (Transmit Equalization Set), which is <BR>irrelevant after 
  convolution.<BR>3. To be consistent with DS equa data, some TLV should be 
  added also into it. What?<BR>We propose to use only value from referenced 
  figure without type/length to avoid questions in the future. If not, <BR>(2) 
  and (3) should be clarified. I guess, that it will be also very helpful if 
  clarification (b) will be entered into MIB. <BR>Best 
  Regards.<BR>Lucy<BR><BR>Contributors - Lucy Pollak TI, Greg White 
  Cablelabs<BR><BR><BR>11) docsIfSignalQualityEntry - clarify wording for back 
  compatibility.<BR>In draft -03 the description of<SPAN 
  style="mso-spacerun: yes">&nbsp; </SPAN>docsIfSignalQualityEntry was changed 
  <BR>from : <BR>docsIfSignalQualityEntry OBJECT-TYPE <BR><SPAN 
  style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN>SYNTAX<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN>DocsIfSignalQualityEntry <BR><SPAN 
  style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN>MAX-ACCESS<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>not-accessible 
  <BR><SPAN 
  style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN>STATUS<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN>current <BR><SPAN 
  style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN>DESCRIPTION <BR><SPAN 
  style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN>"At the CM, describes the PHY characteristics of a <BR><SPAN 
  style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN>downstream channel. At the CMTS, describes the PHY <BR>signal <BR><SPAN 
  style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN>quality of an upstream channel. <BR><SPAN 
  style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN>An entry in this table exists for each ifEntry with an <BR><SPAN 
  style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN>ifType of docsCableUpstream(129) for Cable Modem <BR>Termination 
  <BR><SPAN 
  style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN>Systems and docsCableDownstream(128) for Cable Modems." <BR><SPAN 
  style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN>INDEX { ifIndex } <BR><SPAN 
  style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN>::= { docsIfSignalQualityTable 1 } <BR>to : 
  <BR>docsIfSignalQualityEntry OBJECT-TYPE <BR><SPAN 
  style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN>SYNTAX<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN>DocsIfSignalQualityEntry <BR><SPAN 
  style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN>MAX-ACCESS<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>not-accessible 
  <BR><SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN>STATUS<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN>current <BR><SPAN 
  style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN>DESCRIPTION <BR><SPAN 
  style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN>"At the CM, describes the PHY characteristics of a <BR><SPAN 
  style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN>downstream channel. At the CMTS, describes the PHY signal <BR><SPAN 
  style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN>quality of an upstream channel. <BR><SPAN 
  style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN>An entry in this table exists for each ifEntry with an <BR><SPAN 
  style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN>ifType of docsCableUpstreamChannel(205) for Cable Modem <BR>Termination 
  <BR><SPAN 
  style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN>Systems and docsCableDownstream(128) for Cable Modems." <BR><SPAN 
  style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN>INDEX { ifIndex } <BR><SPAN 
  style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN><SPAN 
  style="mso-spacerun: yes">&nbsp;</SPAN>::= { docsIfSignalQualityTable 1 } 
  <BR>But now RFI mib also apply to 1.1 CMTSes with no concept of ifType 205 
  <BR>but 129 <BR><BR>Contributor - Eduardo Cardona Cablelabs<BR><BR><BR>12) 
  docsIfCmtsCmStatusValue - add new defined value 
  registeredBPIInitializing(9),<BR>deprecate former value 
  operational(8).<BR><BR>Contributors - Eduardo Cardona Cablelabs, Lucy Pollak 
  TI, Minnie Lu Cisco, David White Arris,<BR>Matt Schmitt Arris, Kirk Friedman 
  Correlant, Fred Oko Stargus, Joe Godas Kar-el, Steve Malenfant 
  Com21<BR><BR><BR>13) Adjust compliance statements for objects designated 
  optional. Add separate augmentation table for <BR>optional objects in 
  docsIfCmtsUpChannelCounterTable.<BR><BR>Contributors - Will Murwin Motorola, 
  Rich Woundy IPCDN/Comcast, Mike StJohns Mindspring, Eduardo Cardona 
  Cablelabs<BR><BR><BR>14) Add section explaining counter interaction between 
  Docsis 1.0/1.1/2.0.<BR>The QOS MIB tried to handle<BR>DOCSIS 1.1 changes to 
  RFC2670. Now that rfc2670 is being obsoleted, the rf-mib v2 and the DOCSIS OSS 
  Specs is the place<BR>that should clearly state how these counters and other 
  tables interact in DOCSIS 1.0, DOCSIS 1.1, and DOCSIS 2.0.<BR>I would even 
  hope to see a section in the rf-mib v2, "Interoperation with the version of 
  DOCSIS" like or to replace<BR>what the DOCSIS QOS MIB has. This is the place 
  to describe what table are populated under the docsIfMib when the<BR>the 
  modems are registering.<BR>This way this issue can be re-discussed and 
  whatever conculsion is reached, can be document in the description of 
  those<BR>objects.<BR><BR>Contributor - Will Murwin Motorola, Minnie Lu 
  Cisco<BR><BR><BR>15) Change docsIfCmtsServiceTable to count packets for both 
  upstream and downstream flows. <BR>One of the things that has long been an 
  issue with the RF MIB is that the docsIfCmtsServiceTable only counts 
  <BR>InOctets and InPackets (i.e. upstream packets only). If the reason for 
  keeping this table is to support DOCSIS <BR>1.0 modems would it also make 
  sense to add downstream packet counts to this table, too? Many CMTS'es already 
  <BR>count this information and store it in a proprietary MIB. It would be nice 
  to standardize this as a requirement <BR>so that NMS such as usage monitoring 
  systems could (a) count on it existing and (b) find it in a standard 
  location.<BR><BR>Contributor - Andrew Sundelin Stargus<BR><BR><BR>16) Add 4 
  objects to docsIfCmtsCmStatusTable<BR>While writing DOCS-IETF-QOS-MIB version 
  9, I find myself still thinking about Minnie suggestion of having<SPAN 
  style="mso-spacerun: yes">&nbsp; </SPAN><BR>docsIfCmtsServiceInPackets and 
  docsIfCmtsServiceInOctets count for DOCSIS 1.1 and 2.0. Even though the QOS 
  <BR>MIB has pawned off this discussion, I have had some thoughts on the 
  subject.<BR>(1) If these counters where used to count the DOCSIS 1.1 and 2.0, 
  than this would the best place in all <BR>of the mibs to<BR><SPAN 
  style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>get a quick summary of the 
  upstream data received by a particular modem, no matter the version.<BR>(2) At 
  the same time, The rest of the docsIfCmtsCmServiceTable might not make sense 
  for DOCSIS 1.1 or 2.0<BR>However the more I looked around at the different 
  counters that existed in all of MIB required by DOCSIS, <BR>the more I kept 
  looking for an overall counter on the CMTS to count data packet received and 
  transmitted <BR>for a particular CM. <BR>I would like to start a discussion on 
  about adding 4 new object to the 
  docsIfCmtsCmStatusTable:<BR>docsIfCmtsCmStatusInPackets 
  <BR>docsIfCmtsCmStatusInOctets<BR>docsIfCmtsCmStatusOutPackets<BR>docsIfCmtsCmStatusOutoctets<BR>While 
  I understand that these counts can be gathered by via numerous objects on both 
  the CMTS and CM <BR>and then just appling simple math. However I want to query 
  only one agent and just get a quick summary <BR>without have to determine 
  which version of DOCSIS the modem is, which will determine which mibs I look 
  etc.<BR>and objects I query.<BR><BR>For example if I want query only one 
  agent(i.e. the CMTS) and get the number of transmitted and received <BR>data 
  for each CM, then <BR><SPAN 
  style="mso-tab-count: 1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>(1) 
  GET-NEXT the docsIfCmtsCmStatusRegMode to see what version of DOCSIS this 
  modem is operting <BR><BR><SPAN 
  style="mso-tab-count: 1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>if 
  'docsis10(1)' then <BR><SPAN 
  style="mso-tab-count: 3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN>(2) WALK the entire docsIfCmtsServiceTable for ifIndex and SID 
  that<BR><SPAN style="mso-tab-count: 1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN><SPAN 
  style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN>have docsIfCmtsServiceNewCmStatusIndex that matches the index for step 
  (1).<BR><SPAN style="mso-tab-count: 1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN><BR><SPAN 
  style="mso-tab-count: 3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN>(3) Add the all the instances of docsIfCmtsServiceInPacket for 
  the<BR><SPAN style="mso-tab-count: 1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN><SPAN 
  style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN>ifIndex and SIDs that match from step(2) to get the total Received 
  packets from a CM.<BR><BR><SPAN 
  style="mso-tab-count: 3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN>NOTE: Not sure it is possible to get from a CMTS agent from the 
  Standard MIBs the number of <BR><SPAN 
  style="mso-tab-count: 1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN><SPAN 
  style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN>of packets transmitted to a single docsis 1.0 cable modem.<BR><BR><SPAN 
  style="mso-tab-count: 1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>else if 
  'docsis11(2)' or 'docsis20()' then<BR><SPAN 
  style="mso-tab-count: 3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN>(2) WALK the docsQosCmtsMacToSrvFlowTable all for the instances of that 
  contain the<BR><SPAN 
  style="mso-tab-count: 1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN><SPAN 
  style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN>same mac address.<BR><SPAN 
  style="mso-tab-count: 2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN><SPAN style="mso-tab-count: 1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN>(3) Then GET the docQosServiceFlowPkts using the ifIndex and<BR><SPAN 
  style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN>service flow id from step(2). Add this to the total of received or 
  transmitted for this CM.<BR><SPAN 
  style="mso-tab-count: 3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN><SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>To determine 
  the direction of the flow use the same index and query the 
  docsQosServiceFlowDirection.<BR>This seems very complicated for something so 
  simple. This is just a suggestion of simple way the RF MIB v2 can correct the 
  <BR>mistakes of the past.<SPAN style="mso-spacerun: yes">&nbsp; 
  </SPAN><BR><BR>Contributors - Will Murwin Motorola, Minnie Lu 
  Cisco<BR><BR><BR>17) docsIfCmtsCmStatusTimingOffset - possibly change 
  decription of existing object or<BR>add new object to reconcile unit 
  differences between 1.1/2.0. Still under discussion.<BR><BR>Contributors - 
  Victor Hou Juniper, Rich Woundy IPCDN/Comcast, Kirk Friedman 
  Correlant.<BR><BR><BR><BR style="mso-special-character: line-break"><![if !supportLineBreakNewLine]><BR 
  style="mso-special-character: line-break"><![endif]></SPAN></FONT><FONT 
  face="Courier New" color=black size=1><SPAN 
  style="FONT-SIZE: 8.5pt; COLOR: black; FONT-FAMILY: 'Courier New'; mso-color-alt: windowtext"><o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><SPAN class=EmailStyle15><FONT face=Arial color=black 
  size=2><SPAN style="FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt"><![if !supportEmptyParas]><![endif]>&nbsp;<o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=MsoNormal><SPAN class=EmailStyle15><FONT face=Arial color=black 
  size=2><SPAN style="FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt"><![if !supportEmptyParas]><![endif]>&nbsp;<o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=MsoNormal><!--[if supportFields]><span style='mso-element:field-begin'></span><span 
style="mso-spacerun: yes">&nbsp;</span>AUTOTEXTLIST \s &quot;E-mail 
Signature&quot; <span style='mso-element:field-separator'></span><![endif]--><FONT 
  color=blue size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; mso-bidi-font-size: 12.0pt">************************************<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><I style="mso-bidi-font-style: normal"><FONT face=Arial 
  color=blue size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-STYLE: italic; mso-bidi-font-size: 12.0pt">David 
  Raftus<o:p></o:p></SPAN></FONT></I></P>
  <P class=MsoNormal><I style="mso-bidi-font-style: normal"><FONT face=Arial 
  color=blue size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-STYLE: italic; mso-bidi-font-size: 12.0pt">Terayon 
  Canada Ltd<o:p></o:p></SPAN></FONT></I></P>
  <P class=MsoNormal><I style="mso-bidi-font-style: normal"><FONT face=Arial 
  color=blue size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-STYLE: italic; mso-bidi-font-size: 12.0pt">340 
  Terry Fox Drive, Suite 202<o:p></o:p></SPAN></FONT></I></P>
  <P class=MsoNormal><I style="mso-bidi-font-style: normal"><FONT face=Arial 
  color=blue size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-STYLE: italic; mso-bidi-font-size: 12.0pt">Ottawa 
  Canada<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>K2K 
  3A2<o:p></o:p></SPAN></FONT></I></P>
  <P class=MsoNormal><I style="mso-bidi-font-style: normal"><FONT face=Arial 
  color=blue size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-STYLE: italic; mso-bidi-font-size: 12.0pt"><![if !supportEmptyParas]><![endif]>&nbsp;<o:p></o:p></SPAN></FONT></I></P>
  <P class=MsoNormal><I style="mso-bidi-font-style: normal"><FONT face=Arial 
  color=blue size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-STYLE: italic; mso-bidi-font-size: 12.0pt">david.raftus@terayon.com<SPAN 
  style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN><o:p></o:p></SPAN></FONT></I></P>
  <P class=MsoNormal><I style="mso-bidi-font-style: normal"><FONT face=Arial 
  color=blue size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-STYLE: italic; mso-bidi-font-size: 12.0pt">613.592.1052<SPAN 
  style="mso-spacerun: yes">&nbsp; </SPAN>ext 
  222<o:p></o:p></SPAN></FONT></I></P>
  <P class=MsoNormal><I style="mso-bidi-font-style: normal"><FONT face=Arial 
  color=blue size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-STYLE: italic; mso-bidi-font-size: 12.0pt">************************************<SPAN 
  style="mso-spacerun: yes">&nbsp; </SPAN></SPAN></FONT></I><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt"><SPAN 
  style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN><o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=black size=1><SPAN 
  style="FONT-SIZE: 9pt"><![if !supportEmptyParas]><![endif]>&nbsp;</SPAN><o:p></o:p></FONT></P>
  <P class=MsoNormal><!--[if supportFields]><span style='mso-element:field-end'></span><![endif]--><![if !supportEmptyParas]><![endif]>&nbsp;<o:p></o:p></P></DIV></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_O1ha9TV6poqCUsqB0mWm4A)--

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



From exim@www1.ietf.org  Wed Jun 18 19:26:19 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05999
	for <ipcdn-archive@odin.ietf.org>; Wed, 18 Jun 2003 19:26:19 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5INPqs12397
	for ipcdn-archive@odin.ietf.org; Wed, 18 Jun 2003 19:25:52 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SmEf-00034Z-EP; Wed, 18 Jun 2003 19:21:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SOO0-0003w5-O3
	for ipcdn@optimus.ietf.org; Tue, 17 Jun 2003 17:53:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12806
	for <ipcdn@ietf.org>; Tue, 17 Jun 2003 17:53:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SOLl-0005Rg-00
	for ipcdn@ietf.org; Tue, 17 Jun 2003 17:50:45 -0400
Received: from kar-el.eng.cv.net ([167.206.9.41] helo=kar-el.cvnet.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SOLk-0005RQ-00
	for ipcdn@ietf.org; Tue, 17 Jun 2003 17:50:44 -0400
Received: from ZOREL (jg125.eng.cv.net [167.206.9.125])
 by kar-el.cvnet.com (iPlanet Messaging Server 5.1 (built May  7 2001))
 with SMTP id <0HGN007FXB4SBR@kar-el.cvnet.com> for ipcdn@ietf.org; Tue,
 17 Jun 2003 17:46:06 -0400 (EDT)
Date: Tue, 17 Jun 2003 17:56:40 -0400
From: Joe Godas <joe@kar-el.cvnet.com>
To: matt.schmitt@arrisi.com, Minnie Lu <milu@cisco.com>
Cc: alexb@coresma.com, ASundelin@stargus.com,
        "Raftus, David" <david.raftus@Terayon.com>, david.white@arrisi.com,
        "Docsis 20 Reflector (E-mail)" <docsis-20@cablelabs.com>,
        "Docsis Oss Reflector (E-mail)" <docsis-oss@cablelabs.com>,
        e.cardona@cablelabs.com, fred@stargus.com, g.white@cablelabs.com,
        "Ipcdn List (E-mail)" <ipcdn@ietf.org>, jdemarty@juniper.net,
        john.gillis@adc.com, kfriedman@correlant.com, lucy.pollak@ti.com,
        mdolas@broadcom.com, milu@cisco.com,
        "Rich Woundy (Work) (E-mail)" <Richard_Woundy@cable.comcast.com>,
        stevem@com21.com, vhou@juniper.net, W.Murwin@motorola.com
Message-id: <00f801c3351b$916b18d0$7d09cea7@ZOREL>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
Content-type: multipart/alternative;
 boundary="Boundary_(ID_zmtya632AvP/qNtaXw1LVQ)"
X-Priority: 3
X-MSMail-priority: Normal
References: 
 <OF0C1E27A0.CC93A5B8-ON87256D48.006CF9AC-87256D48.006DBD56@arrisi.com>
Subject: [ipcdn] Re: rf mib draft v6 to draft v7 suggestions
Sender: ipcdn-admin@ietf.org
Errors-To: ipcdn-admin@ietf.org
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

--Boundary_(ID_zmtya632AvP/qNtaXw1LVQ)
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7BIT

Interesting subtleties Matt, thanks.
It might be best solved in vendor implementation than spec....

In terms of using the Cmts as one stop shopping for CM device status, this has the potential for some thorny migration issues wrt backend customer service tools (at least the ones we have here! ;).  A combination of service class and CmtsCmStatusValue will likely have to be queried on the CMTS if the MSO decides to only trust the CMTS Mib to derive a given CM's provisioned state and status....

-Joe
  ----- Original Message ----- 
  From: matt.schmitt@arrisi.com 
  To: Minnie Lu 
  Cc: alexb@coresma.com ; ASundelin@stargus.com ; Raftus, David ; david.white@arrisi.com ; Docsis 20 Reflector (E-mail) ; Docsis Oss Reflector (E-mail) ; e.cardona@cablelabs.com ; fred@stargus.com ; g.white@cablelabs.com ; Ipcdn List (E-mail) ; jdemarty@juniper.net ; Joe Godas ; john.gillis@adc.com ; kfriedman@correlant.com ; lucy.pollak@ti.com ; mdolas@broadcom.com ; milu@cisco.com ; Rich Woundy (Work) (E-mail) ; stevem@com21.com ; vhou@juniper.net ; W.Murwin@motorola.com 
  Sent: Tuesday, June 17, 2003 3:57 PM
  Subject: Re: rf mib draft v6 to draft v7 suggestions



  Minnie, 
          I do have a slight concern with this. 
          Right now, a CMTS does not need to track whether or not a modem has NACO enabled or disabled.  From the 1.1 RFI spec, section C.1.1.3: "The value of this field does not affect CMTS service flow operation and does not affect CMTS data forwarding operation. ... With respect to DOCSIS v1.1 provisioning, a CMTS should ignore the NACO value and allocate any service flows that have been authorized by the provisioning server." 
          If the MIB were changed so that the CMTS has to indicate if NACO is disabled, then that's one additional thing a CMTS is going to have to track that it doesn't now.  It may well be a minor change, but then again it might not be, and that makes me hesitate. 
          Additionally, NACO is enforced at the modem, not at the CMTS.  Therefore, it might actually be more logical to check that state at the modem than at the CMTS. 
          Just a couple of thoughts. 

  Matt 



       Minnie Lu <milu@cisco.com> 
        06/17/03 11:49 AM 

               
                To:        Joe Godas <joe@kar-el.cvnet.com> 
                cc:        "Raftus, David" <david.raftus@Terayon.com>, "Rich Woundy (Work) (E-mail)" <Richard_Woundy@cable.comcast.com>, milu@cisco.com, stevem@com21.com, mdolas@broadcom.com, jdemarty@juniper.net, e.cardona@cablelabs.com, g.white@cablelabs.com, 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, W.Murwin@motorola.com, ASundelin@stargus.com, vhou@juniper.net, "Docsis 20 Reflector (E-mail)" <docsis-20@cablelabs.com>, "Docsis Oss Reflector (E-mail)" <docsis-oss@cablelabs.com>, "Ipcdn List (E-mail)" <ipcdn@ietf.org>, "Raftus, David" <david.raftus@Terayon.com> 
                Subject:        Re: rf mib draft v6 to draft v7 suggestions 



  Hi, Joe,

  Good suggestion.  Maybe in more general, no matter the BPI is enabled or 
  not, a new state for the case that CM is registrationComplete but network 
  access has being disabled by operator/system administrator.

  Thanks!
  Minnie

  At 01:14 PM 6/17/2003 -0400, Joe Godas wrote:
  >"urn:schemas-microsoft-com:office:office" xmlns:w = 
  >"urn:schemas-microsoft-com:office:word">
  >Hi,
  ><I hope I'm not missing something obvious ;>
  >
  >Regarding Item 12 (docsIfCmtsCmStatusValue)and its relation to BPI 
  >state....I am concerned that we haven't captured the case where a modem 
  >has successfully negotiated BPI but it's network access has been disabled.
  >
  >Implementation example: on a Cisco CMTS a BPI enabled voice product would 
  >look like this:
  >ubr110.cmts.hcvlny#scm | inc pt
  ><snip>
  >MAC Address    IP Address      I/F       MAC         Prim 
  >RxPwr  Timing  Num BPI
  >                                          State       Sid  (db)   Offset 
  > CPE Enb
  >0008.0e72.1e30 10.13.18.73     C3/0/U0   online(pt)  6899 
  >0.75   1946    0   Y
  >
  >This modem is showing as online (with BPI) whether or not it's network 
  >access has been disabled due to customer not paying their bill.
  >
  >Is there a response code in the Mib that reflects this BPI negotiated 
  >(with data disabled) state or do we have to rely on querying the 
  >forwarding state of the actual CM?
  >
  >Thanks,
  >Joe Godas
  >Cablevision
  >
  >
  >----- Original Message -----
  >From: <mailto:david.raftus@Terayon.com>Raftus, David
  >To: <mailto:Richard_Woundy@cable.comcast.com>Rich Woundy (Work) (E-mail) ; 
  ><mailto:'milu@cisco.com'>'milu@cisco.com' ; 
  ><mailto:'stevem@com21.com'>'stevem@com21.com' ; 
  ><mailto:'mdolas@broadcom.com'>'mdolas@broadcom.com' ; 
  ><mailto:'jdemarty@juniper.net'>'jdemarty@juniper.net' ; 
  ><mailto:'e.cardona@cablelabs.com'>'e.cardona@cablelabs.com' ; 
  ><mailto:'g.white@cablelabs.com'>'g.white@cablelabs.com' ; 
  ><mailto:'john.gillis@adc.com'>'john.gillis@adc.com' ; 
  ><mailto:'lucy.pollak@ti.com'>'lucy.pollak@ti.com' ; 
  ><mailto:'alexb@coresma.com'>'alexb@coresma.com' ; 
  ><mailto:'david.white@arrisi.com'>'david.white@arrisi.com' ; 
  ><mailto:'matt.schmitt@arrisi.com'>'matt.schmitt@arrisi.com' ; 
  ><mailto:'kfriedman@correlant.com'>'kfriedman@correlant.com' ; 
  ><mailto:'fred@stargus.com'>'fred@stargus.com' ; 
  ><mailto:'joe@kar-el.cvnet.com'>'joe@kar-el.cvnet.com' ; 
  ><mailto:'W.Murwin@motorola.com'>'W.Murwin@motorola.com' ; 
  ><mailto:'ASundelin@stargus.com'>'ASundelin@stargus.com' ; 
  ><mailto:'vhou@juniper.net'>'vhou@juniper.net'
  >Cc: <mailto:docsis-20@cablelabs.com>Docsis 20 Reflector (E-mail) ; 
  ><mailto:docsis-oss@cablelabs.com>Docsis Oss Reflector (E-mail) ; 
  ><mailto:ipcdn@ietf.org>Ipcdn List (E-mail) ; 
  ><mailto:david.raftus@Terayon.com>Raftus, David
  >Sent: Tuesday, June 17, 2003 11:36 AM
  >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
  >************************************
  >
  >




--Boundary_(ID_zmtya632AvP/qNtaXw1LVQ)
Content-type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1141" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Interesting subtleties Matt, thanks.</FONT></DIV>
<DIV><FONT face=Arial size=2>It might be best solved in vendor implementation 
than spec....</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>In terms of using the Cmts as one stop shopping for 
CM device status, this has the potential for&nbsp;some&nbsp;thorny migration 
issues wrt backend customer service tools (at least the ones we have here! 
;).&nbsp; </FONT><FONT face=Arial size=2>A combination of service class and 
<FONT face="Courier New">CmtsCmStatusValue will likely have to be queried on the 
CMTS if the MSO decides to only trust the CMTS Mib to derive a given CM's 
provisioned state and status....</FONT></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>-Joe</FONT></DIV>
<BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV 
  style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B> 
  <A title=matt.schmitt@arrisi.com 
  href="mailto:matt.schmitt@arrisi.com">matt.schmitt@arrisi.com</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>To:</B> <A title=milu@cisco.com 
  href="mailto:milu@cisco.com">Minnie Lu</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Cc:</B> <A title=alexb@coresma.com 
  href="mailto:alexb@coresma.com">alexb@coresma.com</A> ; <A 
  title=ASundelin@stargus.com 
  href="mailto:ASundelin@stargus.com">ASundelin@stargus.com</A> ; <A 
  title=david.raftus@Terayon.com href="mailto:david.raftus@Terayon.com">Raftus, 
  David</A> ; <A title=david.white@arrisi.com 
  href="mailto:david.white@arrisi.com">david.white@arrisi.com</A> ; <A 
  title=docsis-20@cablelabs.com href="mailto:docsis-20@cablelabs.com">Docsis 20 
  Reflector (E-mail)</A> ; <A title=docsis-oss@cablelabs.com 
  href="mailto:docsis-oss@cablelabs.com">Docsis Oss Reflector (E-mail)</A> ; <A 
  title=e.cardona@cablelabs.com 
  href="mailto:e.cardona@cablelabs.com">e.cardona@cablelabs.com</A> ; <A 
  title=fred@stargus.com href="mailto:fred@stargus.com">fred@stargus.com</A> ; 
  <A title=g.white@cablelabs.com 
  href="mailto:g.white@cablelabs.com">g.white@cablelabs.com</A> ; <A 
  title=ipcdn@ietf.org href="mailto:ipcdn@ietf.org">Ipcdn List (E-mail)</A> ; <A 
  title=jdemarty@juniper.net 
  href="mailto:jdemarty@juniper.net">jdemarty@juniper.net</A> ; <A 
  title=joe@kar-el.cvnet.com href="mailto:joe@kar-el.cvnet.com">Joe Godas</A> ; 
  <A title=john.gillis@adc.com 
  href="mailto:john.gillis@adc.com">john.gillis@adc.com</A> ; <A 
  title=kfriedman@correlant.com 
  href="mailto:kfriedman@correlant.com">kfriedman@correlant.com</A> ; <A 
  title=lucy.pollak@ti.com 
  href="mailto:lucy.pollak@ti.com">lucy.pollak@ti.com</A> ; <A 
  title=mdolas@broadcom.com 
  href="mailto:mdolas@broadcom.com">mdolas@broadcom.com</A> ; <A 
  title=milu@cisco.com href="mailto:milu@cisco.com">milu@cisco.com</A> ; <A 
  title=Richard_Woundy@cable.comcast.com 
  href="mailto:Richard_Woundy@cable.comcast.com">Rich Woundy (Work) (E-mail)</A> 
  ; <A title=stevem@com21.com 
  href="mailto:stevem@com21.com">stevem@com21.com</A> ; <A 
  title=vhou@juniper.net href="mailto:vhou@juniper.net">vhou@juniper.net</A> ; 
  <A title=W.Murwin@motorola.com 
  href="mailto:W.Murwin@motorola.com">W.Murwin@motorola.com</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> Tuesday, June 17, 2003 3:57 
PM</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> Re: rf mib draft v6 to draft v7 
  suggestions</DIV>
  <DIV><FONT face=Arial size=2></FONT><BR></DIV><BR><FONT face=sans-serif 
  size=2>Minnie,</FONT> <BR><FONT face=sans-serif size=2>&nbsp; &nbsp; &nbsp; 
  &nbsp; I do have a slight concern with this.</FONT> <BR><FONT face=sans-serif 
  size=2>&nbsp; &nbsp; &nbsp; &nbsp; Right now, a CMTS does not need to track 
  whether or not a modem has NACO enabled or disabled. &nbsp;From the 1.1 RFI 
  spec, section C.1.1.3: "The value of this field does not affect CMTS service 
  flow operation and does not affect CMTS data forwarding operation. ... With 
  respect to DOCSIS v1.1 provisioning, a CMTS should ignore the NACO value and 
  allocate any service flows that have been authorized by the provisioning 
  server."</FONT> <BR><FONT face=sans-serif size=2>&nbsp; &nbsp; &nbsp; &nbsp; 
  If the MIB were changed so that the CMTS has to indicate if NACO is disabled, 
  then that's one additional thing a CMTS is going to have to track that it 
  doesn't now. &nbsp;It may well be a minor change, but then again it might not 
  be, and that makes me hesitate.</FONT> <BR><FONT face=sans-serif size=2>&nbsp; 
  &nbsp; &nbsp; &nbsp; Additionally, NACO is enforced at the modem, not at the 
  CMTS. &nbsp;Therefore, it might actually be more logical to check that state 
  at the modem than at the CMTS.</FONT> <BR><FONT face=sans-serif size=2>&nbsp; 
  &nbsp; &nbsp; &nbsp; Just a couple of thoughts.</FONT> <BR><BR><FONT 
  face=sans-serif size=2>Matt</FONT> <BR><BR><BR><BR>
  <TABLE width="100%">
    <TBODY>
    <TR vAlign=top>
      <TD>
      <TD><FONT face=sans-serif size=1><B>Minnie Lu &lt;<A 
        href="mailto:milu@cisco.com">milu@cisco.com</A>&gt;</B></FONT> 
        <P><FONT face=sans-serif size=1>06/17/03 11:49 AM</FONT> <BR></P>
      <TD><FONT face=Arial size=1>&nbsp; &nbsp; &nbsp; &nbsp; </FONT><BR><FONT 
        face=sans-serif size=1>&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; 
        &nbsp; &nbsp;Joe Godas &lt;<A 
        href="mailto:joe@kar-el.cvnet.com">joe@kar-el.cvnet.com</A>&gt;</FONT> 
        <BR><FONT face=sans-serif size=1>&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; 
        &nbsp; &nbsp; &nbsp;"Raftus, David" &lt;<A 
        href="mailto:david.raftus@Terayon.com">david.raftus@Terayon.com</A>&gt;, 
        "Rich Woundy (Work) (E-mail)" &lt;<A 
        href="mailto:Richard_Woundy@cable.comcast.com">Richard_Woundy@cable.comcast.com</A>&gt;, 
        <A href="mailto:milu@cisco.com">milu@cisco.com</A>, <A 
        href="mailto:stevem@com21.com">stevem@com21.com</A>, <A 
        href="mailto:mdolas@broadcom.com">mdolas@broadcom.com</A>, <A 
        href="mailto:jdemarty@juniper.net">jdemarty@juniper.net</A>, <A 
        href="mailto:e.cardona@cablelabs.com">e.cardona@cablelabs.com</A>, <A 
        href="mailto:g.white@cablelabs.com">g.white@cablelabs.com</A>, <A 
        href="mailto:john.gillis@adc.com">john.gillis@adc.com</A>, <A 
        href="mailto:lucy.pollak@ti.com">lucy.pollak@ti.com</A>, <A 
        href="mailto:alexb@coresma.com">alexb@coresma.com</A>, <A 
        href="mailto:david.white@arrisi.com">david.white@arrisi.com</A>, <A 
        href="mailto:matt.schmitt@arrisi.com">matt.schmitt@arrisi.com</A>, <A 
        href="mailto:kfriedman@correlant.com">kfriedman@correlant.com</A>, <A 
        href="mailto:fred@stargus.com">fred@stargus.com</A>, <A 
        href="mailto:W.Murwin@motorola.com">W.Murwin@motorola.com</A>, <A 
        href="mailto:ASundelin@stargus.com">ASundelin@stargus.com</A>, <A 
        href="mailto:vhou@juniper.net">vhou@juniper.net</A>, "Docsis 20 
        Reflector (E-mail)" &lt;<A 
        href="mailto:docsis-20@cablelabs.com">docsis-20@cablelabs.com</A>&gt;, 
        "Docsis Oss Reflector (E-mail)" &lt;<A 
        href="mailto:docsis-oss@cablelabs.com">docsis-oss@cablelabs.com</A>&gt;, 
        "Ipcdn List (E-mail)" &lt;<A 
        href="mailto:ipcdn@ietf.org">ipcdn@ietf.org</A>&gt;, "Raftus, David" 
        &lt;<A 
        href="mailto:david.raftus@Terayon.com">david.raftus@Terayon.com</A>&gt;</FONT> 
        <BR><FONT face=sans-serif size=1>&nbsp; &nbsp; &nbsp; &nbsp; Subject: 
        &nbsp; &nbsp; &nbsp; &nbsp;Re: rf mib draft v6 to draft v7 
        suggestions</FONT></TR></TBODY></TABLE><BR><BR><BR><FONT face="Courier New" 
  size=2>Hi, Joe,<BR><BR>Good suggestion. &nbsp;Maybe in more general, no matter 
  the BPI is enabled or <BR>not, a new state for the case that CM is 
  registrationComplete but network <BR>access has being disabled by 
  operator/system administrator.<BR><BR>Thanks!<BR>Minnie<BR><BR>At 01:14 PM 
  6/17/2003 -0400, Joe Godas 
  wrote:<BR>&gt;"urn:schemas-microsoft-com:office:office" xmlns:w = 
  <BR>&gt;"urn:schemas-microsoft-com:office:word"&gt;<BR>&gt;Hi,<BR>&gt;&lt;I 
  hope I'm not missing something obvious ;&gt;<BR>&gt;<BR>&gt;Regarding Item 12 
  (docsIfCmtsCmStatusValue)and its relation to BPI <BR>&gt;state....I am 
  concerned that we haven't captured the case where a modem <BR>&gt;has 
  successfully negotiated BPI but it's network access has been 
  disabled.<BR>&gt;<BR>&gt;Implementation example: on a Cisco CMTS a BPI enabled 
  voice product would <BR>&gt;look like this:<BR>&gt;ubr110.cmts.hcvlny#scm | 
  inc pt<BR>&gt;&lt;snip&gt;<BR>&gt;MAC Address &nbsp; &nbsp;IP Address &nbsp; 
  &nbsp; &nbsp;I/F &nbsp; &nbsp; &nbsp; MAC &nbsp; &nbsp; &nbsp; &nbsp; Prim 
  <BR>&gt;RxPwr &nbsp;Timing &nbsp;Num BPI<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; 
  &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
  &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;State &nbsp; &nbsp; &nbsp; Sid 
  &nbsp;(db) &nbsp; Offset <BR>&gt; CPE Enb<BR>&gt;0008.0e72.1e30 10.13.18.73 
  &nbsp; &nbsp; C3/0/U0 &nbsp; online(pt) &nbsp;6899 <BR>&gt;0.75 &nbsp; 1946 
  &nbsp; &nbsp;0 &nbsp; Y<BR>&gt;<BR>&gt;This modem is showing as online (with 
  BPI) whether or not it's network <BR>&gt;access has been disabled due to 
  customer not paying their bill.<BR>&gt;<BR>&gt;Is there a response code in the 
  Mib that reflects this BPI negotiated <BR>&gt;(with data disabled) state or do 
  we have to rely on querying the <BR>&gt;forwarding state of the actual 
  CM?<BR>&gt;<BR>&gt;Thanks,<BR>&gt;Joe 
  Godas<BR>&gt;Cablevision<BR>&gt;<BR>&gt;<BR>&gt;----- Original Message 
  -----<BR>&gt;From: &lt;mailto:david.raftus@Terayon.com&gt;Raftus, 
  David<BR>&gt;To: &lt;mailto:Richard_Woundy@cable.comcast.com&gt;Rich Woundy 
  (Work) (E-mail) ; <BR>&gt;&lt;mailto:'milu@cisco.com'&gt;'milu@cisco.com' ; 
  <BR>&gt;&lt;mailto:'stevem@com21.com'&gt;'stevem@com21.com' ; 
  <BR>&gt;&lt;mailto:'mdolas@broadcom.com'&gt;'mdolas@broadcom.com' ; 
  <BR>&gt;&lt;mailto:'jdemarty@juniper.net'&gt;'jdemarty@juniper.net' ; 
  <BR>&gt;&lt;mailto:'e.cardona@cablelabs.com'&gt;'e.cardona@cablelabs.com' ; 
  <BR>&gt;&lt;mailto:'g.white@cablelabs.com'&gt;'g.white@cablelabs.com' ; 
  <BR>&gt;&lt;mailto:'john.gillis@adc.com'&gt;'john.gillis@adc.com' ; 
  <BR>&gt;&lt;mailto:'lucy.pollak@ti.com'&gt;'lucy.pollak@ti.com' ; 
  <BR>&gt;&lt;mailto:'alexb@coresma.com'&gt;'alexb@coresma.com' ; 
  <BR>&gt;&lt;mailto:'david.white@arrisi.com'&gt;'david.white@arrisi.com' ; 
  <BR>&gt;&lt;mailto:'matt.schmitt@arrisi.com'&gt;'matt.schmitt@arrisi.com' ; 
  <BR>&gt;&lt;mailto:'kfriedman@correlant.com'&gt;'kfriedman@correlant.com' ; 
  <BR>&gt;&lt;mailto:'fred@stargus.com'&gt;'fred@stargus.com' ; 
  <BR>&gt;&lt;mailto:'joe@kar-el.cvnet.com'&gt;'joe@kar-el.cvnet.com' ; 
  <BR>&gt;&lt;mailto:'W.Murwin@motorola.com'&gt;'W.Murwin@motorola.com' ; 
  <BR>&gt;&lt;mailto:'ASundelin@stargus.com'&gt;'ASundelin@stargus.com' ; 
  </FONT><BR><FONT face="Courier New" 
  size=2>&gt;&lt;mailto:'vhou@juniper.net'&gt;'vhou@juniper.net'<BR>&gt;Cc: 
  &lt;mailto:docsis-20@cablelabs.com&gt;Docsis 20 Reflector (E-mail) ; 
  <BR>&gt;&lt;mailto:docsis-oss@cablelabs.com&gt;Docsis Oss Reflector (E-mail) ; 
  <BR>&gt;&lt;mailto:ipcdn@ietf.org&gt;Ipcdn List (E-mail) ; 
  <BR>&gt;&lt;mailto:david.raftus@Terayon.com&gt;Raftus, David<BR>&gt;Sent: 
  Tuesday, June 17, 2003 11:36 AM<BR>&gt;Subject: rf mib draft v6 to draft v7 
  suggestions<BR>&gt;<BR>&gt;Hi everyone,<BR>&gt;<BR>&gt;Since RF mib v2 draft 6 
  was released in March, I have received publicly or <BR>&gt;privately 17 
  requests for updates/changes to appear in draft v7. The <BR>&gt;people on the 
  To: list have participated in either initiating or <BR>&gt;commenting on the 
  suggestions.<BR>&gt;<BR>&gt;Could I ask these people to please verify their 
  suggestions as they are <BR>&gt;listed below? This mib update from v6 to v7 is 
  extensive - want to ensure <BR>&gt;data is accurate before undertaking. The 
  wider communities are also <BR>&gt;welcome to comment.<BR>&gt;<BR>&gt;Thanks 
  for your time,<BR>&gt;Dave<BR>&gt;<BR>&gt;<BR>&gt;1) Return name to pre draft 
  v6 DOCS-IF-MIB from draft v6 DOCS-IETF-RFI-MIB.<BR>&gt;<BR>&gt;Contributors - 
  Rich Woundy IPCDN/Comcast, Minnie Lu Cisco, Steve Malenfant 
  <BR>&gt;Com21<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;2) docsIfCmtsChannelUtUtilization 
  formula - remove line (100 * ((raw bytes <BR>&gt;- stuffed bytes) / raw 
  bytes))<BR>&gt;since it assumes that MPEG payload consists only DOC MAC 
  payload. As we<BR>&gt;know, MPEG could consist video payload and NULL packets. 
  Suggest to remove<BR>&gt;this line since the first 2 lines in the formula are 
  good enough.<BR>&gt;<BR>&gt;Contributor - Minnie Lu &nbsp; 
  &nbsp;Cisco<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;3) Add discontinuity descriptions 
  to all counters related to an interface.<BR>&gt;<BR>&gt;Contributor - Minnie 
  Lu &nbsp; &nbsp;Cisco<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;4) 
  docsIfCmtsInsertInterval - For the docsIfCmtsInsertInterval object, 
  <BR>&gt;there is no such thing as a<BR>&gt;"broadcast station maintenance" 
  interval for new modems joining the <BR>&gt;network. &nbsp; Station should 
  be<BR>&gt;changed to initial to make the text read - "The amount of time to 
  elapse <BR>&gt;between each broadcast<BR>&gt;initial maintenance grant. 
  &nbsp;Broadcast initial maintenance grants are used <BR>&gt;to allow new cable 
  modems<BR>&gt;to join the network. &nbsp;Zero indicates that a vendor-specific 
  algorithm is <BR>&gt;used instead of a fixed time.<BR>&gt;Maximum amount of 
  time permitted by the specification is 2 seconds."<BR>&gt;<BR>&gt;Contributor 
  - Margo Dolas Broadcom<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;5) 
  docsIfCmtsModPreambleType - (Joel) In docsIfCmtsModulationTable, the 
  <BR>&gt;docsIfCmtsModPreambleType object has<BR>&gt;2 possible values qpsk0(1) 
  and qpsk1(2). It seems like it's the only <BR>&gt;object in this table without 
  a<BR>&gt;meaningful default value when this parameter does not make sense. For 
  <BR>&gt;instance, for a TDMA modulation<BR>&gt;profile using QAM16, the actual 
  preamble type is indeed not QPSK0 but <BR>&gt;something else. Does it make 
  sense<BR>&gt;to have a value of 0 in this case, like 
  <BR>&gt;docsIfCmtsModScdmaInterleaverStepSize for non-SCDMA 
  profiles?<BR>&gt;<BR>&gt;(Eduardo) for the benefit of clarifications wouldn't 
  be good to have a <BR>&gt;enumeration unknown(0) for this<BR>&gt;object when 
  not a 2.0 burst ?<BR>&gt;Also a note in the DESCRIPTION like "if 
  docsIfCmtsModChannelType is <BR>&gt;tdma(1) a value unknown(0) is used for 
  this object"<BR>&gt;I would say unknown(0) rather than unknown(3) since it 
  looks like the <BR>&gt;possible current implementation may be 
  reporting<BR>&gt;'0' , and defendable in IETF since RFC 3291 uses '0' for 
  inetAddressType<BR>&gt;<BR>&gt;Contributors - Joel Demarty Juniper, Eduardo 
  Cardona Cablelabs<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;6) docsIfUpstreamChannelTable 
  clone mechanism - improve descriptive <BR>&gt;wording. The spec is vague about 
  the minimum set of parameters<BR>&gt;that the<BR>&gt;CMTS must transfer during 
  a clone operation to be DOCSIS 2.0 compliant. <BR>&gt;Only those starting with 
  docsIfUpChannelScdma or<BR>&gt;all parameters defining an SCDMA channel, like 
  the channel width? Then <BR>&gt;what about the frequency?<BR>&gt;Definitely, 
  this clone mechanism is sophisticated enough that it would <BR>&gt;deserve a 
  more detailed specification<BR>&gt;(and testing) and, as a consequence, an 
  ECR.<BR>&gt;<BR>&gt;Contributor - Joel Demarty 
  Juniper<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;7) docsIfUpChannelPreEqEnable - add 
  DEFVAL clause.<BR>&gt;<BR>&gt;Contributor - John Gillis 
  ADC<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;8) docsIfCmtsUpChnlCtrUcastGrantedMslots - 
  In Cisco CMTS, we use IUC14 <BR>&gt;(reserved) and SID (HEX): 1FFF (max. 
  of<BR>&gt;unicast sid number) for quite some time.<BR>&gt;Q: Should it be 
  counted in docsIfCmtsUpChnlCtrUcastGrantedMslots ?<BR>&gt;My personal think 
  that this objects seems to mean the<BR>&gt;meaningful &nbsp;UNICAST SID, so 
  user could get a good idea about the how many<BR>&gt;minislots really assigned 
  to some meaningful CM. &nbsp;So, the reserved IUCs<BR>&gt;should be excluded 
  from this object though minislots for reserved IUCs are<BR>&gt;still be 
  counted into docsIfCmtsUpChnlCtrTotalMslots.<BR>&gt;Minnie,<BR>&gt;I agree, I 
  think IUC14 grants to SID 1FFF (assuming the CMTS reserves<BR>&gt;that SID to 
  mean no CM) should not be counted in UcastGrantedMslots.<BR>&gt;I also think 
  (and maybe this case is more obvious) than grants to SID 0<BR>&gt;should not 
  be counted in UcastGrantedMslots.<BR>&gt;This brings up a question that I've 
  had for some time. &nbsp;Why does the<BR>&gt;Cisco CMTS use IUC14 and SID 
  1FFF???? &nbsp;The use of IUC14 is prohibited by<BR>&gt;the spec, since it is 
  labeled as "Reserved", and SID 0 is already<BR>&gt;defined to mean "no 
  CM".<BR>&gt;-Greg<BR>&gt;<BR>&gt;Contributors - Minnie Lu Cisco, Greg White 
  Cablelabs<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;9) docsIfCmStatusTable - possibly add 
  new objects for successful/failed <BR>&gt;ucc transactions.<BR>&gt;Hi, 
  Alex,<BR>&gt;I do not think that this is good idea. What will you count 
  into<BR>&gt;docsQosDCCAcks? The relationships between DCC Req/Rsp/Ack is 
  important and<BR>&gt;should not be lost because of UCC additions. I guess, the 
  better place for<BR>&gt;this counters is RFI MIB docsIfCmStatusTable. It may 
  be extended in 
  future<BR>&gt;versions.<BR>&gt;Regards.<BR>&gt;Lucy<BR>&gt;Hello all,<BR>&gt;A 
  question about counting successful and failed UCC transactions.<BR>&gt;It 
  seems like there is no counters dedicated for UCC failed or<BR>&gt;succeeded 
  operation as it is for DCC transactions.<BR>&gt;The question is, since UCC is 
  a subset of DCC operation for 1.1 modem,<BR>&gt;should the modem count UCC 
  transactions in DCC counters (docsQosDCCs,<BR>&gt;docsQosDCCFails) 
  ?<BR>&gt;Thank you in advance.<BR>&gt;<BR>&gt;Contributors - Lucy Pollak TI, 
  Alex Betis Coresma<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;10) 
  docsIfUpChannelPreEqEnable, docsIfCmStatusEqualizationData - clarify 
  <BR>&gt;descriptions.<BR>&gt;Lucy,<BR>&gt;Sorry for the delay in responding. 
  &nbsp;I don't have an objection to your <BR>&gt;proposal, as long as 
  the<BR>&gt;format of the object is clear.<BR>&gt;To summarize, the object 
  docsIfCmStatusEqualizationData will only include <BR>&gt;the "value" from 
  figure 8-23.<BR>&gt;In other words, the first byte reported in the MIB object 
  will be the main <BR>&gt;tap location. &nbsp;A clarification<BR>&gt;should 
  also be made to the description of docsIfUpChannelPreEqEnable to 
  <BR>&gt;indicate your interpretation (b).<BR>&gt;Regarding the question about 
  reverse taps, figure 8-23 is a simplification <BR>&gt;of figure 6-23 from the 
  1.1 RFI<BR>&gt;spec (which includes a format to encode reverse taps). &nbsp;It 
  seems to make <BR>&gt;sense to me to use the format<BR>&gt;shown in that 
  figure. &nbsp;Perhaps this MIB object could be clarified to <BR>&gt;reference 
  both figures.<BR>&gt;-Greg<BR>&gt;<BR>&gt;Greg,<BR>&gt;to summarize our 
  objections:<BR>&gt;1. MIB requires equalization data, then type/length is 
  irrelevant.<BR>&gt;2. There are 2 possible types 4 (Transmit Equalization 
  Adjust) or 9 <BR>&gt;(Transmit Equalization Set), which is<BR>&gt;irrelevant 
  after convolution.<BR>&gt;3. To be consistent with DS equa data, some TLV 
  should be added also into <BR>&gt;it. What?<BR>&gt;We propose to use only 
  value from referenced figure without type/length to <BR>&gt;avoid questions in 
  the future. If not,<BR>&gt;(2) and (3) should be clarified. I guess, that it 
  will be also very <BR>&gt;helpful if clarification (b) will be entered into 
  MIB.<BR>&gt;Best Regards.<BR>&gt;Lucy<BR>&gt;<BR>&gt;Contributors - Lucy 
  Pollak TI, Greg White Cablelabs<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;11) 
  docsIfSignalQualityEntry - clarify wording for back compatibility.<BR>&gt;In 
  draft -03 the description of &nbsp;docsIfSignalQualityEntry was 
  changed<BR>&gt;from :<BR>&gt;docsIfSignalQualityEntry OBJECT-TYPE<BR>&gt; 
  &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;SYNTAX &nbsp; &nbsp; 
  &nbsp;DocsIfSignalQualityEntry<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
  &nbsp;MAX-ACCESS &nbsp;not-accessible<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; 
  &nbsp; &nbsp;STATUS &nbsp; &nbsp; &nbsp;current<BR>&gt; &nbsp; &nbsp; &nbsp; 
  &nbsp; &nbsp; &nbsp;DESCRIPTION<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
  &nbsp; &nbsp; &nbsp;"At the CM, describes the PHY characteristics of a<BR>&gt; 
  &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; downstream channel. At 
  the CMTS, describes the PHY<BR>&gt;signal<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; 
  &nbsp; &nbsp; &nbsp; &nbsp; quality of an upstream channel.<BR>&gt; &nbsp; 
  &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; An entry in this table exists 
  for each ifEntry with an<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
  &nbsp; &nbsp; ifType of docsCableUpstream(129) for Cable 
  Modem<BR>&gt;Termination<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
  &nbsp; &nbsp; Systems and docsCableDownstream(128) for Cable Modems."<BR>&gt; 
  &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INDEX { ifIndex }</FONT> <BR><FONT 
  face="Courier New" size=2>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;::= { 
  docsIfSignalQualityTable 1 }<BR>&gt;to :<BR>&gt;docsIfSignalQualityEntry 
  OBJECT-TYPE<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; SYNTAX &nbsp; &nbsp; 
  &nbsp;DocsIfSignalQualityEntry<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; MAX-ACCESS 
  &nbsp;not-accessible<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; STATUS &nbsp; &nbsp; 
  &nbsp;current<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; DESCRIPTION<BR>&gt; &nbsp; 
  &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "At the CM, describes the PHY 
  characteristics of a<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
  &nbsp;downstream channel. At the CMTS, describes the PHY signal<BR>&gt; &nbsp; 
  &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;quality of an upstream 
  channel.<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;An entry in 
  this table exists for each ifEntry with an<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; 
  &nbsp; &nbsp; &nbsp;ifType of docsCableUpstreamChannel(205) for Cable 
  Modem<BR>&gt;Termination<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
  &nbsp;Systems and docsCableDownstream(128) for Cable Modems."<BR>&gt; &nbsp; 
  &nbsp; &nbsp; &nbsp; INDEX { ifIndex }<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; ::= 
  { docsIfSignalQualityTable 1 }<BR>&gt;But now RFI mib also apply to 1.1 CMTSes 
  with no concept of ifType 205<BR>&gt;but 129<BR>&gt;<BR>&gt;Contributor - 
  Eduardo Cardona Cablelabs<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;12) 
  docsIfCmtsCmStatusValue - add new defined value 
  <BR>&gt;registeredBPIInitializing(9),<BR>&gt;deprecate former value 
  operational(8).<BR>&gt;<BR>&gt;Contributors - Eduardo Cardona Cablelabs, Lucy 
  Pollak TI, Minnie Lu Cisco, <BR>&gt;David White Arris,<BR>&gt;Matt Schmitt 
  Arris, Kirk Friedman Correlant, Fred Oko Stargus, Joe Godas <BR>&gt;Kar-el, 
  Steve Malenfant Com21<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;13) Adjust compliance 
  statements for objects designated optional. Add <BR>&gt;separate augmentation 
  table for<BR>&gt;optional objects in 
  docsIfCmtsUpChannelCounterTable.<BR>&gt;<BR>&gt;Contributors - Will Murwin 
  Motorola, Rich Woundy IPCDN/Comcast, Mike <BR>&gt;StJohns Mindspring, Eduardo 
  Cardona Cablelabs<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;14) Add section explaining 
  counter interaction between Docsis 1.0/1.1/2.0.<BR>&gt;The QOS MIB tried to 
  handle<BR>&gt;DOCSIS 1.1 changes to RFC2670. Now that rfc2670 is being 
  obsoleted, the <BR>&gt;rf-mib v2 and the DOCSIS OSS Specs is the 
  place<BR>&gt;that should clearly state how these counters and other tables 
  interact in <BR>&gt;DOCSIS 1.0, DOCSIS 1.1, and DOCSIS 2.0.<BR>&gt;I would 
  even hope to see a section in the rf-mib v2, "Interoperation with <BR>&gt;the 
  version of DOCSIS" like or to replace<BR>&gt;what the DOCSIS QOS MIB has. This 
  is the place to describe what table are <BR>&gt;populated under the docsIfMib 
  when the<BR>&gt;the modems are registering.<BR>&gt;This way this issue can be 
  re-discussed and whatever conculsion is <BR>&gt;reached, can be document in 
  the description of those<BR>&gt;objects.<BR>&gt;<BR>&gt;Contributor - Will 
  Murwin Motorola, Minnie Lu Cisco<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;15) Change 
  docsIfCmtsServiceTable to count packets for both upstream and 
  <BR>&gt;downstream flows.<BR>&gt;One of the things that has long been an issue 
  with the RF MIB is that the <BR>&gt;docsIfCmtsServiceTable only 
  counts<BR>&gt;InOctets and InPackets (i.e. upstream packets only). If the 
  reason for <BR>&gt;keeping this table is to support DOCSIS<BR>&gt;1.0 modems 
  would it also make sense to add downstream packet counts to <BR>&gt;this 
  table, too? Many CMTS'es already<BR>&gt;count this information and store it in 
  a proprietary MIB. It would be nice <BR>&gt;to standardize this as a 
  requirement<BR>&gt;so that NMS such as usage monitoring systems could (a) 
  count on it <BR>&gt;existing and (b) find it in a standard 
  location.<BR>&gt;<BR>&gt;Contributor - Andrew Sundelin 
  Stargus<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;16) Add 4 objects to 
  docsIfCmtsCmStatusTable<BR>&gt;While writing DOCS-IETF-QOS-MIB version 9, I 
  find myself still thinking <BR>&gt;about Minnie suggestion of 
  having<BR>&gt;docsIfCmtsServiceInPackets and docsIfCmtsServiceInOctets count 
  for DOCSIS <BR>&gt;1.1 and 2.0. Even though the QOS<BR>&gt;MIB has pawned off 
  this discussion, I have had some thoughts on the subject.<BR>&gt;(1) If these 
  counters where used to count the DOCSIS 1.1 and 2.0, than <BR>&gt;this would 
  the best place in all<BR>&gt;of the mibs to<BR>&gt; &nbsp; &nbsp; get a quick 
  summary of the upstream data received by a particular <BR>&gt; modem, no 
  matter the version.<BR>&gt;(2) At the same time, The rest of the 
  docsIfCmtsCmServiceTable might not <BR>&gt;make sense for DOCSIS 1.1 or 
  2.0<BR>&gt;However the more I looked around at the different counters that 
  existed in <BR>&gt;all of MIB required by DOCSIS,<BR>&gt;the more I kept 
  looking for an overall counter on the CMTS to count data <BR>&gt;packet 
  received and transmitted<BR>&gt;for a particular CM.<BR>&gt;I would like to 
  start a discussion on about adding 4 new object to the 
  <BR>&gt;docsIfCmtsCmStatusTable:<BR>&gt;docsIfCmtsCmStatusInPackets<BR>&gt;docsIfCmtsCmStatusInOctets<BR>&gt;docsIfCmtsCmStatusOutPackets<BR>&gt;docsIfCmtsCmStatusOutoctets<BR>&gt;While 
  I understand that these counts can be gathered by via numerous <BR>&gt;objects 
  on both the CMTS and CM<BR>&gt;and then just appling simple math. However I 
  want to query only one agent <BR>&gt;and just get a quick 
  summary<BR>&gt;without have to determine which version of DOCSIS the modem is, 
  which will <BR>&gt;determine which mibs I look etc.<BR>&gt;and objects I 
  query.<BR>&gt;<BR>&gt;For example if I want query only one agent(i.e. the 
  CMTS) and get the <BR>&gt;number of transmitted and received<BR>&gt;data for 
  each CM, then<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp;(1) GET-NEXT the 
  docsIfCmtsCmStatusRegMode to see what version of <BR>&gt; DOCSIS this modem is 
  operting<BR>&gt;<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp;if 'docsis10(1)' 
  then<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
  &nbsp; &nbsp;(2) WALK the entire docsIfCmtsServiceTable for <BR>&gt; ifIndex 
  and SID that<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
  &nbsp; &nbsp; &nbsp; &nbsp;have docsIfCmtsServiceNewCmStatusIndex that 
  <BR>&gt; matches the index for step (1).<BR>&gt;<BR>&gt; &nbsp; &nbsp; &nbsp; 
  &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;(3) Add the all the 
  instances of <BR>&gt; docsIfCmtsServiceInPacket for the<BR>&gt; &nbsp; &nbsp; 
  &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;ifIndex 
  and SIDs that match from step(2) to get <BR>&gt; the total Received packets 
  from a CM.<BR>&gt;<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
  &nbsp; &nbsp; &nbsp; &nbsp;NOTE: Not sure it is possible to get from a CMTS 
  <BR>&gt; agent from the Standard MIBs the number of<BR>&gt; &nbsp; &nbsp; 
  &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;of 
  packets transmitted to a single docsis 1.0 <BR>&gt; cable 
  modem.<BR>&gt;<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp;else if 'docsis11(2)' or 
  'docsis20()' then<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
  &nbsp; &nbsp; &nbsp; &nbsp;(2) WALK the docsQosCmtsMacToSrvFlowTable all for 
  <BR>&gt; the instances of that contain the<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; 
  &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;same mac 
  address.<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
  &nbsp; &nbsp; &nbsp;(3) Then GET the docQosServiceFlowPkts using the <BR>&gt; 
  ifIndex and<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
  &nbsp; &nbsp; &nbsp; service flow id from step(2). Add this to the total 
  <BR>&gt; of received or transmitted for this CM.<BR>&gt; &nbsp; &nbsp; &nbsp; 
  &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;To 
  determine the direction of the flow use the <BR>&gt; same index and query the 
  docsQosServiceFlowDirection.<BR>&gt;This seems very complicated for something 
  so simple. This is just a <BR>&gt;suggestion of simple way the RF MIB v2 can 
  correct the<BR>&gt;mistakes of the past.<BR>&gt;<BR>&gt;Contributors - Will 
  Murwin Motorola, Minnie Lu Cisco<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;17) 
  docsIfCmtsCmStatusTimingOffset - possibly change decription of 
  <BR>&gt;existing object or<BR>&gt;add new object to reconcile unit differences 
  between 1.1/2.0. Still under <BR>&gt;discussion.<BR>&gt;<BR>&gt;Contributors - 
  Victor Hou Juniper, Rich Woundy IPCDN/Comcast, Kirk <BR>&gt;Friedman 
  Correlant.<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;************************************<BR>&gt;David 
  Raftus<BR>&gt;Terayon Canada Ltd<BR>&gt;340 Terry Fox Drive, Suite 
  202<BR>&gt;Ottawa Canada &nbsp;K2K 
  3A2<BR>&gt;<BR>&gt;david.raftus@terayon.com<BR>&gt;613.592.1052 &nbsp;ext 
  222<BR>&gt;************************************<BR>&gt;<BR>&gt;<BR><BR></FONT><BR><BR></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_zmtya632AvP/qNtaXw1LVQ)--

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



From exim@www1.ietf.org  Wed Jun 18 19:29:11 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06054
	for <ipcdn-archive@odin.ietf.org>; Wed, 18 Jun 2003 19:29:11 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5INSis12896
	for ipcdn-archive@odin.ietf.org; Wed, 18 Jun 2003 19:28:44 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SmEf-00034h-Ml; Wed, 18 Jun 2003 19:21:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SYYb-0006dC-Vm
	for ipcdn@optimus.ietf.org; Wed, 18 Jun 2003 04:44:42 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24267
	for <ipcdn@ietf.org>; Wed, 18 Jun 2003 04:44:39 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SYWM-0001RJ-00
	for ipcdn@ietf.org; Wed, 18 Jun 2003 04:42:22 -0400
Received: from jester.ti.com ([192.94.94.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SYWK-0001RF-00
	for ipcdn@ietf.org; Wed, 18 Jun 2003 04:42:21 -0400
Received: from dlep52.itg.ti.com ([157.170.134.103])
	by jester.ti.com (8.12.9/8.12.9) with ESMTP id h5I8fWm1008145;
	Wed, 18 Jun 2003 03:41:32 -0500 (CDT)
Received: from dlep98.itg.ti.com (localhost [127.0.0.1])
	by dlep52.itg.ti.com (8.12.9/8.12.9) with ESMTP id h5I8fV2s016584;
	Wed, 18 Jun 2003 03:41:31 -0500 (CDT)
Received: from dile70.itg.ti.com (dile70.itg.ti.com [137.167.177.22])
	by dlep98.itg.ti.com (8.9.3/8.9.3) with ESMTP id DAA26335;
	Wed, 18 Jun 2003 03:41:25 -0500 (CDT)
Received: by dile70.itg.ti.com with Internet Mail Service (5.5.2653.19)
	id <M2D1C7TM>; Wed, 18 Jun 2003 11:41:24 +0300
Message-ID: <7DF2A1B372BBD611912F00508BDFBA9A9C1A86@dile03.itg.ti.com>
From: "Pollak, Lucy" <Lucy.pollak@ti.com>
To: "'Joe Godas'" <joe@kar-el.cvnet.com>,
        "'matt.schmitt@arrisi.com'"
	 <matt.schmitt@arrisi.com>,
        "'Minnie Lu'" <milu@cisco.com>
Cc: "'alexb@coresma.com'" <alexb@coresma.com>,
        "'ASundelin@stargus.com'"
	 <ASundelin@stargus.com>,
        "'Raftus, David'" <david.raftus@Terayon.com>,
        "'david.white@arrisi.com'" <david.white@arrisi.com>,
        "'Docsis 20 Reflector (E-mail)'" <docsis-20@cablelabs.com>,
        "'Docsis Oss Reflector (E-mail)'" <docsis-oss@cablelabs.com>,
        "'e.cardona@cablelabs.com'" <e.cardona@cablelabs.com>,
        "'fred@stargus.com'" <fred@stargus.com>,
        "'g.white@cablelabs.com'"
	 <g.white@cablelabs.com>,
        "'Ipcdn List (E-mail)'" <ipcdn@ietf.org>,
        "'jdemarty@juniper.net'" <jdemarty@juniper.net>,
        "'john.gillis@adc.com'"
	 <john.gillis@adc.com>,
        "'kfriedman@correlant.com'"
	 <kfriedman@correlant.com>,
        "'mdolas@broadcom.com'" <mdolas@broadcom.com>,
        "'milu@cisco.com'" <milu@cisco.com>,
        "'Rich Woundy (Work) (E-mail)'"
	 <Richard_Woundy@cable.comcast.com>,
        "'stevem@com21.com'"
	 <stevem@com21.com>,
        "'vhou@juniper.net'" <vhou@juniper.net>,
        "'W.Murwin@motorola.com'" <W.Murwin@motorola.com>
Date: Wed, 18 Jun 2003 11:41:24 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C33575.474CC782"
Subject: [ipcdn] RE: rf mib draft v6 to draft v7 suggestions
Sender: ipcdn-admin@ietf.org
Errors-To: ipcdn-admin@ietf.org
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=subscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C33575.474CC782
Content-Type: text/plain;
	charset="iso-8859-1"

I want to remind that even for CM the NACO==0 is not shown in
docsIfCmStatusValue. The MAC interface is considered operational if CM
registered and BPI initialized. NACO==0 is considered as pure bridging
issue. It is reported in docsDevServerBootState, which covers the state of
the overall device. Considering that this layering model is correct, we
should not change anything in CMTS status also.
Lucy

-----Original Message-----
From: Joe Godas [mailto:joe@kar-el.cvnet.com]
Sent: Wednesday, June 18, 2003 12:57 AM
To: matt.schmitt@arrisi.com; Minnie Lu
Cc: alexb@coresma.com; ASundelin@stargus.com; Raftus, David;
david.white@arrisi.com; Docsis 20 Reflector (E-mail); Docsis Oss Reflector
(E-mail); e.cardona@cablelabs.com; fred@stargus.com; g.white@cablelabs.com;
Ipcdn List (E-mail); jdemarty@juniper.net; john.gillis@adc.com;
kfriedman@correlant.com; Pollak, Lucy; mdolas@broadcom.com; milu@cisco.com;
Rich Woundy (Work) (E-mail); stevem@com21.com; vhou@juniper.net;
W.Murwin@motorola.com
Subject: Re: rf mib draft v6 to draft v7 suggestions


Interesting subtleties Matt, thanks.
It might be best solved in vendor implementation than spec....
 
In terms of using the Cmts as one stop shopping for CM device status, this
has the potential for some thorny migration issues wrt backend customer
service tools (at least the ones we have here! ;).  A combination of service
class and CmtsCmStatusValue will likely have to be queried on the CMTS if
the MSO decides to only trust the CMTS Mib to derive a given CM's
provisioned state and status....
 
-Joe

----- Original Message ----- 
From: matt.schmitt@arrisi.com <mailto:matt.schmitt@arrisi.com>  
To: Minnie Lu <mailto:milu@cisco.com>  
Cc: alexb@coresma.com <mailto:alexb@coresma.com>  ; ASundelin@stargus.com
<mailto:ASundelin@stargus.com>  ; Raftus, David
<mailto:david.raftus@Terayon.com>  ; david.white@arrisi.com
<mailto:david.white@arrisi.com>  ; Docsis  <mailto:docsis-20@cablelabs.com>
20 Reflector (E-mail) ; Docsis Oss Reflector (E-mail)
<mailto:docsis-oss@cablelabs.com>  ; e.cardona@cablelabs.com
<mailto:e.cardona@cablelabs.com>  ; fred@stargus.com
<mailto:fred@stargus.com>  ; g.white@cablelabs.com
<mailto:g.white@cablelabs.com>  ; Ipcdn List (E-mail)
<mailto:ipcdn@ietf.org>  ; jdemarty@juniper.net
<mailto:jdemarty@juniper.net>  ; Joe Godas <mailto:joe@kar-el.cvnet.com>  ;
john.gillis@adc.com <mailto:john.gillis@adc.com>  ; kfriedman@correlant.com
<mailto:kfriedman@correlant.com>  ; lucy.pollak@ti.com
<mailto:lucy.pollak@ti.com>  ; mdolas@broadcom.com
<mailto:mdolas@broadcom.com>  ; milu@cisco.com <mailto:milu@cisco.com>  ;
Rich Woundy (Work)  <mailto:Richard_Woundy@cable.comcast.com> (E-mail) ;
stevem@com21.com <mailto:stevem@com21.com>  ; vhou@juniper.net
<mailto:vhou@juniper.net>  ; W.Murwin@motorola.com
<mailto:W.Murwin@motorola.com>  
Sent: Tuesday, June 17, 2003 3:57 PM
Subject: Re: rf mib draft v6 to draft v7 suggestions



Minnie, 
        I do have a slight concern with this. 
        Right now, a CMTS does not need to track whether or not a modem has
NACO enabled or disabled.  From the 1.1 RFI spec, section C.1.1.3: "The
value of this field does not affect CMTS service flow operation and does not
affect CMTS data forwarding operation. ... With respect to DOCSIS v1.1
provisioning, a CMTS should ignore the NACO value and allocate any service
flows that have been authorized by the provisioning server." 
        If the MIB were changed so that the CMTS has to indicate if NACO is
disabled, then that's one additional thing a CMTS is going to have to track
that it doesn't now.  It may well be a minor change, but then again it might
not be, and that makes me hesitate. 
        Additionally, NACO is enforced at the modem, not at the CMTS.
Therefore, it might actually be more logical to check that state at the
modem than at the CMTS. 
        Just a couple of thoughts. 

Matt 




	Minnie Lu < milu@cisco.com <mailto:milu@cisco.com> > 


06/17/03 11:49 AM 


        
        To:        Joe Godas < joe@kar-el.cvnet.com
<mailto:joe@kar-el.cvnet.com> > 
        cc:        "Raftus, David" < david.raftus@Terayon.com
<mailto:david.raftus@Terayon.com> >, "Rich Woundy (Work) (E-mail)" <
Richard_Woundy@cable.comcast.com <mailto:Richard_Woundy@cable.comcast.com>
>, milu@cisco.com <mailto:milu@cisco.com> , stevem@com21.com
<mailto:stevem@com21.com> , mdolas@broadcom.com <mailto:mdolas@broadcom.com>
, jdemarty@juniper.net <mailto:jdemarty@juniper.net> ,
e.cardona@cablelabs.com <mailto:e.cardona@cablelabs.com> ,
g.white@cablelabs.com <mailto:g.white@cablelabs.com> , john.gillis@adc.com
<mailto:john.gillis@adc.com> , lucy.pollak@ti.com
<mailto:lucy.pollak@ti.com> , alexb@coresma.com <mailto:alexb@coresma.com> ,
david.white@arrisi.com <mailto:david.white@arrisi.com> ,
matt.schmitt@arrisi.com <mailto:matt.schmitt@arrisi.com> ,
kfriedman@correlant.com <mailto:kfriedman@correlant.com> , fred@stargus.com
<mailto:fred@stargus.com> , W.Murwin@motorola.com
<mailto:W.Murwin@motorola.com> , ASundelin@stargus.com
<mailto:ASundelin@stargus.com> , vhou@juniper.net <mailto:vhou@juniper.net>
, "Docsis 20 Reflector (E-mail)" < docsis-20@cablelabs.com
<mailto:docsis-20@cablelabs.com> >, "Docsis Oss Reflector (E-mail)" <
docsis-oss@cablelabs.com <mailto:docsis-oss@cablelabs.com> >, "Ipcdn List
(E-mail)" < ipcdn@ietf.org <mailto:ipcdn@ietf.org> >, "Raftus, David" <
david.raftus@Terayon.com <mailto:david.raftus@Terayon.com> > 
        Subject:        Re: rf mib draft v6 to draft v7 suggestions	



Hi, Joe,

Good suggestion.  Maybe in more general, no matter the BPI is enabled or 
not, a new state for the case that CM is registrationComplete but network 
access has being disabled by operator/system administrator.

Thanks!
Minnie

At 01:14 PM 6/17/2003 -0400, Joe Godas wrote:
>"urn:schemas-microsoft-com:office:office" xmlns:w = 
>"urn:schemas-microsoft-com:office:word">
>Hi,
><I hope I'm not missing something obvious ;>
>
>Regarding Item 12 (docsIfCmtsCmStatusValue)and its relation to BPI 
>state....I am concerned that we haven't captured the case where a modem 
>has successfully negotiated BPI but it's network access has been disabled.
>
>Implementation example: on a Cisco CMTS a BPI enabled voice product would 
>look like this:
>ubr110.cmts.hcvlny#scm | inc pt
><snip>
>MAC Address    IP Address      I/F       MAC         Prim 
>RxPwr  Timing  Num BPI
>                                          State       Sid  (db)   Offset 
> CPE Enb
>0008.0e72.1e30 10.13.18.73     C3/0/U0   online(pt)  6899 
>0.75   1946    0   Y
>
>This modem is showing as online (with BPI) whether or not it's network 
>access has been disabled due to customer not paying their bill.
>
>Is there a response code in the Mib that reflects this BPI negotiated 
>(with data disabled) state or do we have to rely on querying the 
>forwarding state of the actual CM?
>
>Thanks,
>Joe Godas
>Cablevision
>
>
>----- Original Message -----
>From: <mailto:david.raftus@Terayon.com>Raftus, David
>To: <mailto:Richard_Woundy@cable.comcast.com>Rich Woundy (Work) (E-mail) ; 
><mailto:'milu@cisco.com'>'milu@cisco.com' ; 
><mailto:'stevem@com21.com'>'stevem@com21.com' ; 
><mailto:'mdolas@broadcom.com'>'mdolas@broadcom.com' ; 
><mailto:'jdemarty@juniper.net'>'jdemarty@juniper.net' ; 
><mailto:'e.cardona@cablelabs.com'>'e.cardona@cablelabs.com' ; 
><mailto:'g.white@cablelabs.com'>'g.white@cablelabs.com' ; 
><mailto:'john.gillis@adc.com'>'john.gillis@adc.com' ; 
><mailto:'lucy.pollak@ti.com'>'lucy.pollak@ti.com' ; 
><mailto:'alexb@coresma.com'>'alexb@coresma.com' ; 
><mailto:'david.white@arrisi.com'>'david.white@arrisi.com' ; 
><mailto:'matt.schmitt@arrisi.com'>'matt.schmitt@arrisi.com' ; 
><mailto:'kfriedman@correlant.com'>'kfriedman@correlant.com' ; 
><mailto:'fred@stargus.com'>'fred@stargus.com' ; 
><mailto:'joe@kar-el.cvnet.com'>'joe@kar-el.cvnet.com' ; 
><mailto:'W.Murwin@motorola.com'>'W.Murwin@motorola.com' ; 
><mailto:'ASundelin@stargus.com'>'ASundelin@stargus.com' ; 
><mailto:'vhou@juniper.net'>'vhou@juniper.net'
>Cc: <mailto:docsis-20@cablelabs.com>Docsis 20 Reflector (E-mail) ; 
><mailto:docsis-oss@cablelabs.com>Docsis Oss Reflector (E-mail) ; 
><mailto:ipcdn@ietf.org>Ipcdn List (E-mail) ; 
><mailto:david.raftus@Terayon.com>Raftus, David
>Sent: Tuesday, June 17, 2003 11:36 AM
>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
>************************************
>
>






------_=_NextPart_001_01C33575.474CC782
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 6.00.2600.0" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV>
<DIV><SPAN class=719383208-18062003><FONT size=2><FONT face=Arial 
color=#0000ff>I want to remind that even for CM the NACO==0 is not shown in 
</FONT><FONT size=1><FONT face=Arial color=#0000ff size=2>docsIfCmStatusValue. 
The MAC interface is considered operational if CM registered and BPI 
initialized. NACO==0 is considered as pure bridging issue. It is reported in 
<FONT face="&#12;charset0MS Sans Serif" size=1><FONT 
size=2>docsDevServerBootState, which covers the state of the overall device. 
Considering that this layering model is correct, we should not change anything 
in CMTS status also.</FONT></FONT></FONT></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=719383208-18062003><FONT size=2><FONT size=1><FONT size=2><FONT 
size=1><SPAN class=364533908-18062003><FONT face=Arial color=#0000ff 
size=2>Lucy</FONT></SPAN></DIV></FONT></FONT></FONT></FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Joe Godas 
  [mailto:joe@kar-el.cvnet.com]<BR><B>Sent:</B> Wednesday, June 18, 2003 12:57 
  AM<BR><B>To:</B> matt.schmitt@arrisi.com; Minnie Lu<BR><B>Cc:</B> 
  alexb@coresma.com; ASundelin@stargus.com; Raftus, David; 
  david.white@arrisi.com; Docsis 20 Reflector (E-mail); Docsis Oss Reflector 
  (E-mail); e.cardona@cablelabs.com; fred@stargus.com; g.white@cablelabs.com; 
  Ipcdn List (E-mail); jdemarty@juniper.net; john.gillis@adc.com; 
  kfriedman@correlant.com; Pollak, Lucy; mdolas@broadcom.com; milu@cisco.com; 
  Rich Woundy (Work) (E-mail); stevem@com21.com; vhou@juniper.net; 
  W.Murwin@motorola.com<BR><B>Subject:</B> Re: rf mib draft v6 to draft v7 
  suggestions<BR><BR></FONT></DIV>
  <DIV><FONT face=Arial size=2>Interesting subtleties Matt, thanks.</FONT></DIV>
  <DIV><FONT face=Arial size=2>It might be best solved in vendor implementation 
  than spec....</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>In terms of using the Cmts as one stop shopping 
  for CM device status, this has the potential for&nbsp;some&nbsp;thorny 
  migration issues wrt backend customer service tools (at least the ones we have 
  here! ;).&nbsp; </FONT><FONT face=Arial size=2>A combination of service class 
  and <FONT face="Courier New">CmtsCmStatusValue will likely have to be queried 
  on the CMTS if the MSO decides to only trust the CMTS Mib to derive a given 
  CM's provisioned state and status....</FONT></FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>-Joe</FONT></DIV>
  <BLOCKQUOTE 
  style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
    <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
    <DIV 
    style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B> 
    <A title=matt.schmitt@arrisi.com 
    href="mailto:matt.schmitt@arrisi.com">matt.schmitt@arrisi.com</A> </DIV>
    <DIV style="FONT: 10pt arial"><B>To:</B> <A title=milu@cisco.com 
    href="mailto:milu@cisco.com">Minnie Lu</A> </DIV>
    <DIV style="FONT: 10pt arial"><B>Cc:</B> <A title=alexb@coresma.com 
    href="mailto:alexb@coresma.com">alexb@coresma.com</A> ; <A 
    title=ASundelin@stargus.com 
    href="mailto:ASundelin@stargus.com">ASundelin@stargus.com</A> ; <A 
    title=david.raftus@Terayon.com 
    href="mailto:david.raftus@Terayon.com">Raftus, David</A> ; <A 
    title=david.white@arrisi.com 
    href="mailto:david.white@arrisi.com">david.white@arrisi.com</A> ; <A 
    title=docsis-20@cablelabs.com href="mailto:docsis-20@cablelabs.com">Docsis 
    20 Reflector (E-mail)</A> ; <A title=docsis-oss@cablelabs.com 
    href="mailto:docsis-oss@cablelabs.com">Docsis Oss Reflector (E-mail)</A> ; 
    <A title=e.cardona@cablelabs.com 
    href="mailto:e.cardona@cablelabs.com">e.cardona@cablelabs.com</A> ; <A 
    title=fred@stargus.com href="mailto:fred@stargus.com">fred@stargus.com</A> ; 
    <A title=g.white@cablelabs.com 
    href="mailto:g.white@cablelabs.com">g.white@cablelabs.com</A> ; <A 
    title=ipcdn@ietf.org href="mailto:ipcdn@ietf.org">Ipcdn List (E-mail)</A> ; 
    <A title=jdemarty@juniper.net 
    href="mailto:jdemarty@juniper.net">jdemarty@juniper.net</A> ; <A 
    title=joe@kar-el.cvnet.com href="mailto:joe@kar-el.cvnet.com">Joe Godas</A> 
    ; <A title=john.gillis@adc.com 
    href="mailto:john.gillis@adc.com">john.gillis@adc.com</A> ; <A 
    title=kfriedman@correlant.com 
    href="mailto:kfriedman@correlant.com">kfriedman@correlant.com</A> ; <A 
    title=lucy.pollak@ti.com 
    href="mailto:lucy.pollak@ti.com">lucy.pollak@ti.com</A> ; <A 
    title=mdolas@broadcom.com 
    href="mailto:mdolas@broadcom.com">mdolas@broadcom.com</A> ; <A 
    title=milu@cisco.com href="mailto:milu@cisco.com">milu@cisco.com</A> ; <A 
    title=Richard_Woundy@cable.comcast.com 
    href="mailto:Richard_Woundy@cable.comcast.com">Rich Woundy (Work) 
    (E-mail)</A> ; <A title=stevem@com21.com 
    href="mailto:stevem@com21.com">stevem@com21.com</A> ; <A 
    title=vhou@juniper.net href="mailto:vhou@juniper.net">vhou@juniper.net</A> ; 
    <A title=W.Murwin@motorola.com 
    href="mailto:W.Murwin@motorola.com">W.Murwin@motorola.com</A> </DIV>
    <DIV style="FONT: 10pt arial"><B>Sent:</B> Tuesday, June 17, 2003 3:57 
    PM</DIV>
    <DIV style="FONT: 10pt arial"><B>Subject:</B> Re: rf mib draft v6 to draft 
    v7 suggestions</DIV>
    <DIV><FONT face=Arial size=2></FONT><BR></DIV><BR><FONT face=sans-serif 
    size=2>Minnie,</FONT> <BR><FONT face=sans-serif size=2>&nbsp; &nbsp; &nbsp; 
    &nbsp; I do have a slight concern with this.</FONT> <BR><FONT 
    face=sans-serif size=2>&nbsp; &nbsp; &nbsp; &nbsp; Right now, a CMTS does 
    not need to track whether or not a modem has NACO enabled or disabled. 
    &nbsp;From the 1.1 RFI spec, section C.1.1.3: "The value of this field does 
    not affect CMTS service flow operation and does not affect CMTS data 
    forwarding operation. ... With respect to DOCSIS v1.1 provisioning, a CMTS 
    should ignore the NACO value and allocate any service flows that have been 
    authorized by the provisioning server."</FONT> <BR><FONT face=sans-serif 
    size=2>&nbsp; &nbsp; &nbsp; &nbsp; If the MIB were changed so that the CMTS 
    has to indicate if NACO is disabled, then that's one additional thing a CMTS 
    is going to have to track that it doesn't now. &nbsp;It may well be a minor 
    change, but then again it might not be, and that makes me hesitate.</FONT> 
    <BR><FONT face=sans-serif size=2>&nbsp; &nbsp; &nbsp; &nbsp; Additionally, 
    NACO is enforced at the modem, not at the CMTS. &nbsp;Therefore, it might 
    actually be more logical to check that state at the modem than at the 
    CMTS.</FONT> <BR><FONT face=sans-serif size=2>&nbsp; &nbsp; &nbsp; &nbsp; 
    Just a couple of thoughts.</FONT> <BR><BR><FONT face=sans-serif 
    size=2>Matt</FONT> <BR><BR><BR><BR>
    <TABLE width="100%">
      <TBODY>
      <TR vAlign=top>
        <TD>
        <TD><FONT face=sans-serif size=1><B>Minnie Lu &lt;<A 
          href="mailto:milu@cisco.com">milu@cisco.com</A>&gt;</B></FONT> 
          <P><FONT face=sans-serif size=1>06/17/03 11:49 AM</FONT> <BR></P>
        <TD><FONT face=Arial size=1>&nbsp; &nbsp; &nbsp; &nbsp; 
          </FONT><BR><FONT face=sans-serif size=1>&nbsp; &nbsp; &nbsp; &nbsp; 
          To: &nbsp; &nbsp; &nbsp; &nbsp;Joe Godas &lt;<A 
          href="mailto:joe@kar-el.cvnet.com">joe@kar-el.cvnet.com</A>&gt;</FONT> 
          <BR><FONT face=sans-serif size=1>&nbsp; &nbsp; &nbsp; &nbsp; cc: 
          &nbsp; &nbsp; &nbsp; &nbsp;"Raftus, David" &lt;<A 
          href="mailto:david.raftus@Terayon.com">david.raftus@Terayon.com</A>&gt;, 
          "Rich Woundy (Work) (E-mail)" &lt;<A 
          href="mailto:Richard_Woundy@cable.comcast.com">Richard_Woundy@cable.comcast.com</A>&gt;, 
          <A href="mailto:milu@cisco.com">milu@cisco.com</A>, <A 
          href="mailto:stevem@com21.com">stevem@com21.com</A>, <A 
          href="mailto:mdolas@broadcom.com">mdolas@broadcom.com</A>, <A 
          href="mailto:jdemarty@juniper.net">jdemarty@juniper.net</A>, <A 
          href="mailto:e.cardona@cablelabs.com">e.cardona@cablelabs.com</A>, <A 
          href="mailto:g.white@cablelabs.com">g.white@cablelabs.com</A>, <A 
          href="mailto:john.gillis@adc.com">john.gillis@adc.com</A>, <A 
          href="mailto:lucy.pollak@ti.com">lucy.pollak@ti.com</A>, <A 
          href="mailto:alexb@coresma.com">alexb@coresma.com</A>, <A 
          href="mailto:david.white@arrisi.com">david.white@arrisi.com</A>, <A 
          href="mailto:matt.schmitt@arrisi.com">matt.schmitt@arrisi.com</A>, <A 
          href="mailto:kfriedman@correlant.com">kfriedman@correlant.com</A>, <A 
          href="mailto:fred@stargus.com">fred@stargus.com</A>, <A 
          href="mailto:W.Murwin@motorola.com">W.Murwin@motorola.com</A>, <A 
          href="mailto:ASundelin@stargus.com">ASundelin@stargus.com</A>, <A 
          href="mailto:vhou@juniper.net">vhou@juniper.net</A>, "Docsis 20 
          Reflector (E-mail)" &lt;<A 
          href="mailto:docsis-20@cablelabs.com">docsis-20@cablelabs.com</A>&gt;, 
          "Docsis Oss Reflector (E-mail)" &lt;<A 
          href="mailto:docsis-oss@cablelabs.com">docsis-oss@cablelabs.com</A>&gt;, 
          "Ipcdn List (E-mail)" &lt;<A 
          href="mailto:ipcdn@ietf.org">ipcdn@ietf.org</A>&gt;, "Raftus, David" 
          &lt;<A 
          href="mailto:david.raftus@Terayon.com">david.raftus@Terayon.com</A>&gt;</FONT> 
          <BR><FONT face=sans-serif size=1>&nbsp; &nbsp; &nbsp; &nbsp; Subject: 
          &nbsp; &nbsp; &nbsp; &nbsp;Re: rf mib draft v6 to draft v7 
          suggestions</FONT></TD></TR></TBODY></TABLE><BR><BR><BR><FONT 
    face="Courier New" size=2>Hi, Joe,<BR><BR>Good suggestion. &nbsp;Maybe in 
    more general, no matter the BPI is enabled or <BR>not, a new state for the 
    case that CM is registrationComplete but network <BR>access has being 
    disabled by operator/system 
    administrator.<BR><BR>Thanks!<BR>Minnie<BR><BR>At 01:14 PM 6/17/2003 -0400, 
    Joe Godas wrote:<BR>&gt;"urn:schemas-microsoft-com:office:office" xmlns:w = 
    <BR>&gt;"urn:schemas-microsoft-com:office:word"&gt;<BR>&gt;Hi,<BR>&gt;&lt;I 
    hope I'm not missing something obvious ;&gt;<BR>&gt;<BR>&gt;Regarding Item 
    12 (docsIfCmtsCmStatusValue)and its relation to BPI <BR>&gt;state....I am 
    concerned that we haven't captured the case where a modem <BR>&gt;has 
    successfully negotiated BPI but it's network access has been 
    disabled.<BR>&gt;<BR>&gt;Implementation example: on a Cisco CMTS a BPI 
    enabled voice product would <BR>&gt;look like 
    this:<BR>&gt;ubr110.cmts.hcvlny#scm | inc pt<BR>&gt;&lt;snip&gt;<BR>&gt;MAC 
    Address &nbsp; &nbsp;IP Address &nbsp; &nbsp; &nbsp;I/F &nbsp; &nbsp; &nbsp; 
    MAC &nbsp; &nbsp; &nbsp; &nbsp; Prim <BR>&gt;RxPwr &nbsp;Timing &nbsp;Num 
    BPI<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
    &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
    &nbsp;State &nbsp; &nbsp; &nbsp; Sid &nbsp;(db) &nbsp; Offset <BR>&gt; CPE 
    Enb<BR>&gt;0008.0e72.1e30 10.13.18.73 &nbsp; &nbsp; C3/0/U0 &nbsp; 
    online(pt) &nbsp;6899 <BR>&gt;0.75 &nbsp; 1946 &nbsp; &nbsp;0 &nbsp; 
    Y<BR>&gt;<BR>&gt;This modem is showing as online (with BPI) whether or not 
    it's network <BR>&gt;access has been disabled due to customer not paying 
    their bill.<BR>&gt;<BR>&gt;Is there a response code in the Mib that reflects 
    this BPI negotiated <BR>&gt;(with data disabled) state or do we have to rely 
    on querying the <BR>&gt;forwarding state of the actual 
    CM?<BR>&gt;<BR>&gt;Thanks,<BR>&gt;Joe 
    Godas<BR>&gt;Cablevision<BR>&gt;<BR>&gt;<BR>&gt;----- Original Message 
    -----<BR>&gt;From: &lt;mailto:david.raftus@Terayon.com&gt;Raftus, 
    David<BR>&gt;To: &lt;mailto:Richard_Woundy@cable.comcast.com&gt;Rich Woundy 
    (Work) (E-mail) ; <BR>&gt;&lt;mailto:'milu@cisco.com'&gt;'milu@cisco.com' ; 
    <BR>&gt;&lt;mailto:'stevem@com21.com'&gt;'stevem@com21.com' ; 
    <BR>&gt;&lt;mailto:'mdolas@broadcom.com'&gt;'mdolas@broadcom.com' ; 
    <BR>&gt;&lt;mailto:'jdemarty@juniper.net'&gt;'jdemarty@juniper.net' ; 
    <BR>&gt;&lt;mailto:'e.cardona@cablelabs.com'&gt;'e.cardona@cablelabs.com' ; 
    <BR>&gt;&lt;mailto:'g.white@cablelabs.com'&gt;'g.white@cablelabs.com' ; 
    <BR>&gt;&lt;mailto:'john.gillis@adc.com'&gt;'john.gillis@adc.com' ; 
    <BR>&gt;&lt;mailto:'lucy.pollak@ti.com'&gt;'lucy.pollak@ti.com' ; 
    <BR>&gt;&lt;mailto:'alexb@coresma.com'&gt;'alexb@coresma.com' ; 
    <BR>&gt;&lt;mailto:'david.white@arrisi.com'&gt;'david.white@arrisi.com' ; 
    <BR>&gt;&lt;mailto:'matt.schmitt@arrisi.com'&gt;'matt.schmitt@arrisi.com' ; 
    <BR>&gt;&lt;mailto:'kfriedman@correlant.com'&gt;'kfriedman@correlant.com' ; 
    <BR>&gt;&lt;mailto:'fred@stargus.com'&gt;'fred@stargus.com' ; 
    <BR>&gt;&lt;mailto:'joe@kar-el.cvnet.com'&gt;'joe@kar-el.cvnet.com' ; 
    <BR>&gt;&lt;mailto:'W.Murwin@motorola.com'&gt;'W.Murwin@motorola.com' ; 
    <BR>&gt;&lt;mailto:'ASundelin@stargus.com'&gt;'ASundelin@stargus.com' ; 
    </FONT><BR><FONT face="Courier New" 
    size=2>&gt;&lt;mailto:'vhou@juniper.net'&gt;'vhou@juniper.net'<BR>&gt;Cc: 
    &lt;mailto:docsis-20@cablelabs.com&gt;Docsis 20 Reflector (E-mail) ; 
    <BR>&gt;&lt;mailto:docsis-oss@cablelabs.com&gt;Docsis Oss Reflector (E-mail) 
    ; <BR>&gt;&lt;mailto:ipcdn@ietf.org&gt;Ipcdn List (E-mail) ; 
    <BR>&gt;&lt;mailto:david.raftus@Terayon.com&gt;Raftus, David<BR>&gt;Sent: 
    Tuesday, June 17, 2003 11:36 AM<BR>&gt;Subject: rf mib draft v6 to draft v7 
    suggestions<BR>&gt;<BR>&gt;Hi everyone,<BR>&gt;<BR>&gt;Since RF mib v2 draft 
    6 was released in March, I have received publicly or <BR>&gt;privately 17 
    requests for updates/changes to appear in draft v7. The <BR>&gt;people on 
    the To: list have participated in either initiating or <BR>&gt;commenting on 
    the suggestions.<BR>&gt;<BR>&gt;Could I ask these people to please verify 
    their suggestions as they are <BR>&gt;listed below? This mib update from v6 
    to v7 is extensive - want to ensure <BR>&gt;data is accurate before 
    undertaking. The wider communities are also <BR>&gt;welcome to 
    comment.<BR>&gt;<BR>&gt;Thanks for your 
    time,<BR>&gt;Dave<BR>&gt;<BR>&gt;<BR>&gt;1) Return name to pre draft v6 
    DOCS-IF-MIB from draft v6 DOCS-IETF-RFI-MIB.<BR>&gt;<BR>&gt;Contributors - 
    Rich Woundy IPCDN/Comcast, Minnie Lu Cisco, Steve Malenfant 
    <BR>&gt;Com21<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;2) 
    docsIfCmtsChannelUtUtilization formula - remove line (100 * ((raw bytes 
    <BR>&gt;- stuffed bytes) / raw bytes))<BR>&gt;since it assumes that MPEG 
    payload consists only DOC MAC payload. As we<BR>&gt;know, MPEG could consist 
    video payload and NULL packets. Suggest to remove<BR>&gt;this line since the 
    first 2 lines in the formula are good enough.<BR>&gt;<BR>&gt;Contributor - 
    Minnie Lu &nbsp; &nbsp;Cisco<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;3) Add 
    discontinuity descriptions to all counters related to an 
    interface.<BR>&gt;<BR>&gt;Contributor - Minnie Lu &nbsp; 
    &nbsp;Cisco<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;4) docsIfCmtsInsertInterval - For 
    the docsIfCmtsInsertInterval object, <BR>&gt;there is no such thing as 
    a<BR>&gt;"broadcast station maintenance" interval for new modems joining the 
    <BR>&gt;network. &nbsp; Station should be<BR>&gt;changed to initial to make 
    the text read - "The amount of time to elapse <BR>&gt;between each 
    broadcast<BR>&gt;initial maintenance grant. &nbsp;Broadcast initial 
    maintenance grants are used <BR>&gt;to allow new cable modems<BR>&gt;to join 
    the network. &nbsp;Zero indicates that a vendor-specific algorithm is 
    <BR>&gt;used instead of a fixed time.<BR>&gt;Maximum amount of time 
    permitted by the specification is 2 seconds."<BR>&gt;<BR>&gt;Contributor - 
    Margo Dolas Broadcom<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;5) 
    docsIfCmtsModPreambleType - (Joel) In docsIfCmtsModulationTable, the 
    <BR>&gt;docsIfCmtsModPreambleType object has<BR>&gt;2 possible values 
    qpsk0(1) and qpsk1(2). It seems like it's the only <BR>&gt;object in this 
    table without a<BR>&gt;meaningful default value when this parameter does not 
    make sense. For <BR>&gt;instance, for a TDMA modulation<BR>&gt;profile using 
    QAM16, the actual preamble type is indeed not QPSK0 but <BR>&gt;something 
    else. Does it make sense<BR>&gt;to have a value of 0 in this case, like 
    <BR>&gt;docsIfCmtsModScdmaInterleaverStepSize for non-SCDMA 
    profiles?<BR>&gt;<BR>&gt;(Eduardo) for the benefit of clarifications 
    wouldn't be good to have a <BR>&gt;enumeration unknown(0) for 
    this<BR>&gt;object when not a 2.0 burst ?<BR>&gt;Also a note in the 
    DESCRIPTION like "if docsIfCmtsModChannelType is <BR>&gt;tdma(1) a value 
    unknown(0) is used for this object"<BR>&gt;I would say unknown(0) rather 
    than unknown(3) since it looks like the <BR>&gt;possible current 
    implementation may be reporting<BR>&gt;'0' , and defendable in IETF since 
    RFC 3291 uses '0' for inetAddressType<BR>&gt;<BR>&gt;Contributors - Joel 
    Demarty Juniper, Eduardo Cardona Cablelabs<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;6) 
    docsIfUpstreamChannelTable clone mechanism - improve descriptive 
    <BR>&gt;wording. The spec is vague about the minimum set of 
    parameters<BR>&gt;that the<BR>&gt;CMTS must transfer during a clone 
    operation to be DOCSIS 2.0 compliant. <BR>&gt;Only those starting with 
    docsIfUpChannelScdma or<BR>&gt;all parameters defining an SCDMA channel, 
    like the channel width? Then <BR>&gt;what about the 
    frequency?<BR>&gt;Definitely, this clone mechanism is sophisticated enough 
    that it would <BR>&gt;deserve a more detailed specification<BR>&gt;(and 
    testing) and, as a consequence, an ECR.<BR>&gt;<BR>&gt;Contributor - Joel 
    Demarty Juniper<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;7) docsIfUpChannelPreEqEnable 
    - add DEFVAL clause.<BR>&gt;<BR>&gt;Contributor - John Gillis 
    ADC<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;8) docsIfCmtsUpChnlCtrUcastGrantedMslots 
    - In Cisco CMTS, we use IUC14 <BR>&gt;(reserved) and SID (HEX): 1FFF (max. 
    of<BR>&gt;unicast sid number) for quite some time.<BR>&gt;Q: Should it be 
    counted in docsIfCmtsUpChnlCtrUcastGrantedMslots ?<BR>&gt;My personal think 
    that this objects seems to mean the<BR>&gt;meaningful &nbsp;UNICAST SID, so 
    user could get a good idea about the how many<BR>&gt;minislots really 
    assigned to some meaningful CM. &nbsp;So, the reserved IUCs<BR>&gt;should be 
    excluded from this object though minislots for reserved IUCs 
    are<BR>&gt;still be counted into 
    docsIfCmtsUpChnlCtrTotalMslots.<BR>&gt;Minnie,<BR>&gt;I agree, I think IUC14 
    grants to SID 1FFF (assuming the CMTS reserves<BR>&gt;that SID to mean no 
    CM) should not be counted in UcastGrantedMslots.<BR>&gt;I also think (and 
    maybe this case is more obvious) than grants to SID 0<BR>&gt;should not be 
    counted in UcastGrantedMslots.<BR>&gt;This brings up a question that I've 
    had for some time. &nbsp;Why does the<BR>&gt;Cisco CMTS use IUC14 and SID 
    1FFF???? &nbsp;The use of IUC14 is prohibited by<BR>&gt;the spec, since it 
    is labeled as "Reserved", and SID 0 is already<BR>&gt;defined to mean "no 
    CM".<BR>&gt;-Greg<BR>&gt;<BR>&gt;Contributors - Minnie Lu Cisco, Greg White 
    Cablelabs<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;9) docsIfCmStatusTable - possibly 
    add new objects for successful/failed <BR>&gt;ucc transactions.<BR>&gt;Hi, 
    Alex,<BR>&gt;I do not think that this is good idea. What will you count 
    into<BR>&gt;docsQosDCCAcks? The relationships between DCC Req/Rsp/Ack is 
    important and<BR>&gt;should not be lost because of UCC additions. I guess, 
    the better place for<BR>&gt;this counters is RFI MIB docsIfCmStatusTable. It 
    may be extended in 
    future<BR>&gt;versions.<BR>&gt;Regards.<BR>&gt;Lucy<BR>&gt;Hello 
    all,<BR>&gt;A question about counting successful and failed UCC 
    transactions.<BR>&gt;It seems like there is no counters dedicated for UCC 
    failed or<BR>&gt;succeeded operation as it is for DCC 
    transactions.<BR>&gt;The question is, since UCC is a subset of DCC operation 
    for 1.1 modem,<BR>&gt;should the modem count UCC transactions in DCC 
    counters (docsQosDCCs,<BR>&gt;docsQosDCCFails) ?<BR>&gt;Thank you in 
    advance.<BR>&gt;<BR>&gt;Contributors - Lucy Pollak TI, Alex Betis 
    Coresma<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;10) docsIfUpChannelPreEqEnable, 
    docsIfCmStatusEqualizationData - clarify 
    <BR>&gt;descriptions.<BR>&gt;Lucy,<BR>&gt;Sorry for the delay in responding. 
    &nbsp;I don't have an objection to your <BR>&gt;proposal, as long as 
    the<BR>&gt;format of the object is clear.<BR>&gt;To summarize, the object 
    docsIfCmStatusEqualizationData will only include <BR>&gt;the "value" from 
    figure 8-23.<BR>&gt;In other words, the first byte reported in the MIB 
    object will be the main <BR>&gt;tap location. &nbsp;A 
    clarification<BR>&gt;should also be made to the description of 
    docsIfUpChannelPreEqEnable to <BR>&gt;indicate your interpretation 
    (b).<BR>&gt;Regarding the question about reverse taps, figure 8-23 is a 
    simplification <BR>&gt;of figure 6-23 from the 1.1 RFI<BR>&gt;spec (which 
    includes a format to encode reverse taps). &nbsp;It seems to make 
    <BR>&gt;sense to me to use the format<BR>&gt;shown in that figure. 
    &nbsp;Perhaps this MIB object could be clarified to <BR>&gt;reference both 
    figures.<BR>&gt;-Greg<BR>&gt;<BR>&gt;Greg,<BR>&gt;to summarize our 
    objections:<BR>&gt;1. MIB requires equalization data, then type/length is 
    irrelevant.<BR>&gt;2. There are 2 possible types 4 (Transmit Equalization 
    Adjust) or 9 <BR>&gt;(Transmit Equalization Set), which is<BR>&gt;irrelevant 
    after convolution.<BR>&gt;3. To be consistent with DS equa data, some TLV 
    should be added also into <BR>&gt;it. What?<BR>&gt;We propose to use only 
    value from referenced figure without type/length to <BR>&gt;avoid questions 
    in the future. If not,<BR>&gt;(2) and (3) should be clarified. I guess, that 
    it will be also very <BR>&gt;helpful if clarification (b) will be entered 
    into MIB.<BR>&gt;Best Regards.<BR>&gt;Lucy<BR>&gt;<BR>&gt;Contributors - 
    Lucy Pollak TI, Greg White Cablelabs<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;11) 
    docsIfSignalQualityEntry - clarify wording for back compatibility.<BR>&gt;In 
    draft -03 the description of &nbsp;docsIfSignalQualityEntry was 
    changed<BR>&gt;from :<BR>&gt;docsIfSignalQualityEntry OBJECT-TYPE<BR>&gt; 
    &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;SYNTAX &nbsp; &nbsp; 
    &nbsp;DocsIfSignalQualityEntry<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
    &nbsp;MAX-ACCESS &nbsp;not-accessible<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; 
    &nbsp; &nbsp;STATUS &nbsp; &nbsp; &nbsp;current<BR>&gt; &nbsp; &nbsp; &nbsp; 
    &nbsp; &nbsp; &nbsp;DESCRIPTION<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
    &nbsp; &nbsp; &nbsp;"At the CM, describes the PHY characteristics of 
    a<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; downstream 
    channel. At the CMTS, describes the PHY<BR>&gt;signal<BR>&gt; &nbsp; &nbsp; 
    &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; quality of an upstream 
    channel.<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; An 
    entry in this table exists for each ifEntry with an<BR>&gt; &nbsp; &nbsp; 
    &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ifType of docsCableUpstream(129) 
    for Cable Modem<BR>&gt;Termination<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; 
    &nbsp; &nbsp; &nbsp; &nbsp; Systems and docsCableDownstream(128) for Cable 
    Modems."<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INDEX { ifIndex 
    }</FONT> <BR><FONT face="Courier New" size=2>&gt; &nbsp; &nbsp; &nbsp; 
    &nbsp; &nbsp; &nbsp;::= { docsIfSignalQualityTable 1 }<BR>&gt;to 
    :<BR>&gt;docsIfSignalQualityEntry OBJECT-TYPE<BR>&gt; &nbsp; &nbsp; &nbsp; 
    &nbsp; SYNTAX &nbsp; &nbsp; &nbsp;DocsIfSignalQualityEntry<BR>&gt; &nbsp; 
    &nbsp; &nbsp; &nbsp; MAX-ACCESS &nbsp;not-accessible<BR>&gt; &nbsp; &nbsp; 
    &nbsp; &nbsp; STATUS &nbsp; &nbsp; &nbsp;current<BR>&gt; &nbsp; &nbsp; 
    &nbsp; &nbsp; DESCRIPTION<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
    "At the CM, describes the PHY characteristics of a<BR>&gt; &nbsp; &nbsp; 
    &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;downstream channel. At the CMTS, describes 
    the PHY signal<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
    &nbsp;quality of an upstream channel.<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; 
    &nbsp; &nbsp; &nbsp;An entry in this table exists for each ifEntry with 
    an<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;ifType of 
    docsCableUpstreamChannel(205) for Cable Modem<BR>&gt;Termination<BR>&gt; 
    &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Systems and 
    docsCableDownstream(128) for Cable Modems."<BR>&gt; &nbsp; &nbsp; &nbsp; 
    &nbsp; INDEX { ifIndex }<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; ::= { 
    docsIfSignalQualityTable 1 }<BR>&gt;But now RFI mib also apply to 1.1 CMTSes 
    with no concept of ifType 205<BR>&gt;but 129<BR>&gt;<BR>&gt;Contributor - 
    Eduardo Cardona Cablelabs<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;12) 
    docsIfCmtsCmStatusValue - add new defined value 
    <BR>&gt;registeredBPIInitializing(9),<BR>&gt;deprecate former value 
    operational(8).<BR>&gt;<BR>&gt;Contributors - Eduardo Cardona Cablelabs, 
    Lucy Pollak TI, Minnie Lu Cisco, <BR>&gt;David White Arris,<BR>&gt;Matt 
    Schmitt Arris, Kirk Friedman Correlant, Fred Oko Stargus, Joe Godas 
    <BR>&gt;Kar-el, Steve Malenfant Com21<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;13) 
    Adjust compliance statements for objects designated optional. Add 
    <BR>&gt;separate augmentation table for<BR>&gt;optional objects in 
    docsIfCmtsUpChannelCounterTable.<BR>&gt;<BR>&gt;Contributors - Will Murwin 
    Motorola, Rich Woundy IPCDN/Comcast, Mike <BR>&gt;StJohns Mindspring, 
    Eduardo Cardona Cablelabs<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;14) Add section 
    explaining counter interaction between Docsis 1.0/1.1/2.0.<BR>&gt;The QOS 
    MIB tried to handle<BR>&gt;DOCSIS 1.1 changes to RFC2670. Now that rfc2670 
    is being obsoleted, the <BR>&gt;rf-mib v2 and the DOCSIS OSS Specs is the 
    place<BR>&gt;that should clearly state how these counters and other tables 
    interact in <BR>&gt;DOCSIS 1.0, DOCSIS 1.1, and DOCSIS 2.0.<BR>&gt;I would 
    even hope to see a section in the rf-mib v2, "Interoperation with 
    <BR>&gt;the version of DOCSIS" like or to replace<BR>&gt;what the DOCSIS QOS 
    MIB has. This is the place to describe what table are <BR>&gt;populated 
    under the docsIfMib when the<BR>&gt;the modems are registering.<BR>&gt;This 
    way this issue can be re-discussed and whatever conculsion is 
    <BR>&gt;reached, can be document in the description of 
    those<BR>&gt;objects.<BR>&gt;<BR>&gt;Contributor - Will Murwin Motorola, 
    Minnie Lu Cisco<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;15) Change 
    docsIfCmtsServiceTable to count packets for both upstream and 
    <BR>&gt;downstream flows.<BR>&gt;One of the things that has long been an 
    issue with the RF MIB is that the <BR>&gt;docsIfCmtsServiceTable only 
    counts<BR>&gt;InOctets and InPackets (i.e. upstream packets only). If the 
    reason for <BR>&gt;keeping this table is to support DOCSIS<BR>&gt;1.0 modems 
    would it also make sense to add downstream packet counts to <BR>&gt;this 
    table, too? Many CMTS'es already<BR>&gt;count this information and store it 
    in a proprietary MIB. It would be nice <BR>&gt;to standardize this as a 
    requirement<BR>&gt;so that NMS such as usage monitoring systems could (a) 
    count on it <BR>&gt;existing and (b) find it in a standard 
    location.<BR>&gt;<BR>&gt;Contributor - Andrew Sundelin 
    Stargus<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;16) Add 4 objects to 
    docsIfCmtsCmStatusTable<BR>&gt;While writing DOCS-IETF-QOS-MIB version 9, I 
    find myself still thinking <BR>&gt;about Minnie suggestion of 
    having<BR>&gt;docsIfCmtsServiceInPackets and docsIfCmtsServiceInOctets count 
    for DOCSIS <BR>&gt;1.1 and 2.0. Even though the QOS<BR>&gt;MIB has pawned 
    off this discussion, I have had some thoughts on the subject.<BR>&gt;(1) If 
    these counters where used to count the DOCSIS 1.1 and 2.0, than <BR>&gt;this 
    would the best place in all<BR>&gt;of the mibs to<BR>&gt; &nbsp; &nbsp; get 
    a quick summary of the upstream data received by a particular <BR>&gt; 
    modem, no matter the version.<BR>&gt;(2) At the same time, The rest of the 
    docsIfCmtsCmServiceTable might not <BR>&gt;make sense for DOCSIS 1.1 or 
    2.0<BR>&gt;However the more I looked around at the different counters that 
    existed in <BR>&gt;all of MIB required by DOCSIS,<BR>&gt;the more I kept 
    looking for an overall counter on the CMTS to count data <BR>&gt;packet 
    received and transmitted<BR>&gt;for a particular CM.<BR>&gt;I would like to 
    start a discussion on about adding 4 new object to the 
    <BR>&gt;docsIfCmtsCmStatusTable:<BR>&gt;docsIfCmtsCmStatusInPackets<BR>&gt;docsIfCmtsCmStatusInOctets<BR>&gt;docsIfCmtsCmStatusOutPackets<BR>&gt;docsIfCmtsCmStatusOutoctets<BR>&gt;While 
    I understand that these counts can be gathered by via numerous 
    <BR>&gt;objects on both the CMTS and CM<BR>&gt;and then just appling simple 
    math. However I want to query only one agent <BR>&gt;and just get a quick 
    summary<BR>&gt;without have to determine which version of DOCSIS the modem 
    is, which will <BR>&gt;determine which mibs I look etc.<BR>&gt;and objects I 
    query.<BR>&gt;<BR>&gt;For example if I want query only one agent(i.e. the 
    CMTS) and get the <BR>&gt;number of transmitted and received<BR>&gt;data for 
    each CM, then<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp;(1) GET-NEXT the 
    docsIfCmtsCmStatusRegMode to see what version of <BR>&gt; DOCSIS this modem 
    is operting<BR>&gt;<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp;if 'docsis10(1)' 
    then<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
    &nbsp; &nbsp;(2) WALK the entire docsIfCmtsServiceTable for <BR>&gt; ifIndex 
    and SID that<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
    &nbsp; &nbsp; &nbsp; &nbsp;have docsIfCmtsServiceNewCmStatusIndex that 
    <BR>&gt; matches the index for step (1).<BR>&gt;<BR>&gt; &nbsp; &nbsp; 
    &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;(3) Add the 
    all the instances of <BR>&gt; docsIfCmtsServiceInPacket for the<BR>&gt; 
    &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
    &nbsp;ifIndex and SIDs that match from step(2) to get <BR>&gt; the total 
    Received packets from a CM.<BR>&gt;<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; 
    &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;NOTE: Not sure it is 
    possible to get from a CMTS <BR>&gt; agent from the Standard MIBs the number 
    of<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
    &nbsp; &nbsp; &nbsp; &nbsp;of packets transmitted to a single docsis 1.0 
    <BR>&gt; cable modem.<BR>&gt;<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp;else if 
    'docsis11(2)' or 'docsis20()' then<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; 
    &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;(2) WALK the 
    docsQosCmtsMacToSrvFlowTable all for <BR>&gt; the instances of that contain 
    the<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
    &nbsp; &nbsp; &nbsp;same mac address.<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; 
    &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;(3) Then GET the 
    docQosServiceFlowPkts using the <BR>&gt; ifIndex and<BR>&gt; &nbsp; &nbsp; 
    &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; service flow 
    id from step(2). Add this to the total <BR>&gt; of received or transmitted 
    for this CM.<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
    &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;To determine the direction of the flow use 
    the <BR>&gt; same index and query the 
    docsQosServiceFlowDirection.<BR>&gt;This seems very complicated for 
    something so simple. This is just a <BR>&gt;suggestion of simple way the RF 
    MIB v2 can correct the<BR>&gt;mistakes of the 
    past.<BR>&gt;<BR>&gt;Contributors - Will Murwin Motorola, Minnie Lu 
    Cisco<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;17) docsIfCmtsCmStatusTimingOffset - 
    possibly change decription of <BR>&gt;existing object or<BR>&gt;add new 
    object to reconcile unit differences between 1.1/2.0. Still under 
    <BR>&gt;discussion.<BR>&gt;<BR>&gt;Contributors - Victor Hou Juniper, Rich 
    Woundy IPCDN/Comcast, Kirk <BR>&gt;Friedman 
    Correlant.<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;************************************<BR>&gt;David 
    Raftus<BR>&gt;Terayon Canada Ltd<BR>&gt;340 Terry Fox Drive, Suite 
    202<BR>&gt;Ottawa Canada &nbsp;K2K 
    3A2<BR>&gt;<BR>&gt;david.raftus@terayon.com<BR>&gt;613.592.1052 &nbsp;ext 
    222<BR>&gt;************************************<BR>&gt;<BR>&gt;<BR><BR></FONT><BR><BR></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C33575.474CC782--

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



From exim@www1.ietf.org  Mon Jun 23 13:39:32 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00314
	for <ipcdn-archive@odin.ietf.org>; Mon, 23 Jun 2003 13:39:32 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5NHd3W16730
	for ipcdn-archive@odin.ietf.org; Mon, 23 Jun 2003 13:39:03 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19UVHQ-0004Ld-LV; Mon, 23 Jun 2003 13:39:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19UVD7-00042r-P4
	for ipcdn@optimus.ietf.org; Mon, 23 Jun 2003 13:38:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00207
	for <ipcdn@ietf.org>; Mon, 23 Jun 2003 13:34:31 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19UVD5-0004A0-00
	for ipcdn@ietf.org; Mon, 23 Jun 2003 13:34:31 -0400
Received: from coral.tci.com ([198.178.8.81] helo=saipal.tci.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19UVCt-00049k-00
	for ipcdn@ietf.org; Mon, 23 Jun 2003 13:34:19 -0400
Received: from entexchimc04.broadband.att.com ([127.0.0.1])
	by saipal.tci.com (8.12.9/8.12.9) with ESMTP id h5NHWsI7002152;
	Mon, 23 Jun 2003 11:32:55 -0600 (MDT)
Received: by entexchimc04.broadband.att.com with Internet Mail Service (5.5.2653.19)
	id <MM0Z976L>; Mon, 23 Jun 2003 11:32:54 -0600
Message-ID: <6732623D2548D61193C90002A5C88DCC05663C02@entmaexch02.broadband.att.com>
From: "Woundy, Richard" <Richard_Woundy@cable.comcast.com>
To: "'Raftus, David'" <david.raftus@Terayon.com>,
        "'milu@cisco.com'"
	 <milu@cisco.com>,
        "'stevem@com21.com'" <stevem@com21.com>,
        "'mdolas@broadcom.com'" <mdolas@broadcom.com>,
        "'jdemarty@juniper.net'"
	 <jdemarty@juniper.net>,
        "'e.cardona@cablelabs.com'"
	 <e.cardona@cablelabs.com>,
        "'g.white@cablelabs.com'"
	 <g.white@cablelabs.com>,
        "'john.gillis@adc.com'" <john.gillis@adc.com>,
        "'lucy.pollak@ti.com'" <lucy.pollak@ti.com>,
        "'alexb@coresma.com'"
	 <alexb@coresma.com>,
        "'david.white@arrisi.com'" <david.white@arrisi.com>,
        "'matt.schmitt@arrisi.com'" <matt.schmitt@arrisi.com>,
        "'kfriedman@correlant.com'" <kfriedman@correlant.com>,
        "'fred@stargus.com'" <fred@stargus.com>,
        "'joe@kar-el.cvnet.com'"
	 <joe@kar-el.cvnet.com>,
        "'W.Murwin@motorola.com'"
	 <W.Murwin@motorola.com>,
        "'ASundelin@stargus.com'"
	 <ASundelin@stargus.com>,
        "'vhou@juniper.net'" <vhou@juniper.net>
Cc: "Docsis 20 Reflector (E-mail)" <docsis-20@cablelabs.com>,
        "Docsis Oss Reflector (E-mail)" <docsis-oss@cablelabs.com>,
        "Ipcdn List (E-mail)" <ipcdn@ietf.org>,
        "Raftus, David"
	 <david.raftus@Terayon.com>
Date: Mon, 23 Jun 2003 11:32:43 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C339AD.73D15550"
Subject: [ipcdn] RE: rf mib draft v6 to draft v7 suggestions
Sender: ipcdn-admin@ietf.org
Errors-To: ipcdn-admin@ietf.org
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=subscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C339AD.73D15550
Content-Type: text/plain;
	charset="iso-8859-1"

David,
 
Thanks for putting this extensive list of comments together for the RF MIB
v2 draft. I am hoping that we can start the WG last-call process for version
-07 of the draft, as soon as it is posted.
 
Concerning item #5 and adding "unknown(0)" to the enumeration list of
docsIfCmtsModPreambleType. I think this might be OK (to make it easier to
evolve the Preamble Type values in Table 8-19 of the RFIv2.0 spec), but note
that using value 0 in an INTEGER enumeration is often discouraged by the MIB
doctors. You might want to be extra-verbose with respect to your MIB
documentation when adding this enumeration. Section 4.6.1.1 of
draft-ietf-ops-mib-review-guidelines-01.txt states:
 
   Note that RFC 2578 recommends (but does not require) that integer-
   valued enumerations start at 1 and be numbered contiguously.  This
   recommendation SHOULD be followed unless there is a valid reason to
   do otherwise, e.g., to match values of external data or to indicate
   special cases, and any such special-case usage SHOULD be clearly
   documented.  For an example see the InetAddressType TC [RFC3291].

 
Concerning item #17 -- do we have consensus on the coarse/fine objects???
 
Also make sure that version -07 conforms to the requirements in
http://www.ietf.org/ID-nits.html <http://www.ietf.org/ID-nits.html> .
 
-- Rich
-----Original Message-----
From: Raftus, David [mailto:david.raftus@Terayon.com]
Sent: Tuesday, June 17, 2003 11:37 AM
To: Woundy, Richard; 'milu@cisco.com'; 'stevem@com21.com';
'mdolas@broadcom.com'; 'jdemarty@juniper.net'; 'e.cardona@cablelabs.com';
'g.white@cablelabs.com'; '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 20 Reflector (E-mail); Docsis Oss Reflector (E-mail); 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
************************************               
 
 

------_=_NextPart_001_01C339AD.73D15550
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word"><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3DWord.Document name=3DProgId>
<META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR>
<META content=3D"Microsoft Word 9" name=3DOriginator><LINK=20
href=3D"cid:filelist.xml@01C334C4.C53BF0A0" rel=3DFile-List><!--[if gte =
mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:View>Normal</w:View>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<STYLE>@page Section1 {size: 612.0pt 792.0pt; margin: 72.0pt 90.0pt =
72.0pt 90.0pt; mso-header-margin: 36.0pt; mso-footer-margin: 36.0pt; =
mso-paper-source: 0; }
P.MsoNormal {
	FONT-SIZE: 9pt; MARGIN: 0pt; COLOR: black; FONT-FAMILY: Arial; =
mso-bidi-font-size: 12.0pt; mso-style-parent: ""; mso-pagination: =
widow-orphan; mso-fareast-font-family: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 9pt; MARGIN: 0pt; COLOR: black; FONT-FAMILY: Arial; =
mso-bidi-font-size: 12.0pt; mso-style-parent: ""; mso-pagination: =
widow-orphan; mso-fareast-font-family: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 9pt; MARGIN: 0pt; COLOR: black; FONT-FAMILY: Arial; =
mso-bidi-font-size: 12.0pt; mso-style-parent: ""; mso-pagination: =
widow-orphan; mso-fareast-font-family: "Times New Roman"
}
P.MsoAutoSig {
	FONT-SIZE: 9pt; MARGIN: 0pt; COLOR: black; FONT-FAMILY: Arial; =
mso-bidi-font-size: 12.0pt; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
LI.MsoAutoSig {
	FONT-SIZE: 9pt; MARGIN: 0pt; COLOR: black; FONT-FAMILY: Arial; =
mso-bidi-font-size: 12.0pt; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
DIV.MsoAutoSig {
	FONT-SIZE: 9pt; MARGIN: 0pt; COLOR: black; FONT-FAMILY: Arial; =
mso-bidi-font-size: 12.0pt; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
SPAN.EmailStyle15 {
	COLOR: black; mso-style-type: personal-compose; mso-ansi-font-size: =
10.0pt; mso-ascii-font-family: Arial; mso-hansi-font-family: Arial; =
mso-bidi-font-family: Arial
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=3DEN-US style=3D"tab-interval: 36.0pt">
<DIV><FONT face=3D"Courier New"><FONT size=3D2><SPAN=20
class=3D126234612-23062003>David,</SPAN></FONT></FONT></DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D2><SPAN=20
class=3D126234612-23062003></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D2><SPAN =
class=3D126234612-23062003>Thanks=20
for putting this extensive list of comments together for the RF MIB v2 =
draft. I=20
am hoping that we&nbsp;can start the WG last-call process for version =
-07 of the=20
draft, as soon as it is posted.</SPAN></FONT></FONT></DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D2><SPAN=20
class=3D126234612-23062003></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D2><SPAN=20
class=3D126234612-23062003>Concerning item #5 and adding "unknown(0)" =
to the=20
enumeration list of docsIfCmtsModPreambleType. I think this&nbsp;might=20
be&nbsp;OK (to make it easier to evolve the Preamble Type values in =
Table 8-19=20
of the RFIv2.0 spec), but note that using value 0 in an INTEGER =
enumeration is=20
often discouraged by the MIB doctors.&nbsp;You might&nbsp;want to=20
be&nbsp;extra-verbose&nbsp;with respect to&nbsp;your MIB documentation =
when=20
adding this enumeration. Section 4.6.1.1 of=20
draft-ietf-ops-mib-review-guidelines-01.txt =
states:</SPAN></FONT></FONT></DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D2><SPAN=20
class=3D126234612-23062003></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D2><SPAN=20
class=3D126234612-23062003>&nbsp;&nbsp; Note that RFC 2578 recommends =
(but does=20
not require) that integer-<BR>&nbsp;&nbsp; valued enumerations start at =
1 and be=20
numbered contiguously.&nbsp; This<BR>&nbsp;&nbsp; recommendation SHOULD =
be=20
followed unless there is a valid reason to<BR>&nbsp;&nbsp; do =
otherwise, e.g.,=20
to match values of external data or to indicate<BR>&nbsp;&nbsp; special =
cases,=20
and any such special-case usage SHOULD be clearly<BR>&nbsp;&nbsp;=20
documented.&nbsp; For an example see the InetAddressType TC=20
[RFC3291].<BR></SPAN></FONT></FONT></DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D2><SPAN=20
class=3D126234612-23062003></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D2><SPAN=20
class=3D126234612-23062003>Concerning item #17 -- do we have consensus =
on the=20
coarse/fine objects???</SPAN></FONT></FONT></DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D2><SPAN=20
class=3D126234612-23062003></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT size=3D+0><SPAN class=3D126234612-23062003><FONT =
face=3D"Courier New"=20
size=3D2>Also make sure that version -07 conforms to the requirements =
in=20
</FONT><FONT face=3D"Courier New"><FONT size=3D2><A=20
href=3D"http://www.ietf.org/ID-nits.html">http://www.ietf.org/ID-nits.ht=
ml</A>.<SPAN=20
class=3D126234612-23062003></SPAN></FONT></FONT></SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D2><SPAN=20
class=3D126234612-23062003></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D2><SPAN =
class=3D126234612-23062003>--=20
Rich</SPAN></FONT></FONT></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Raftus, David=20
  [mailto:david.raftus@Terayon.com]<BR><B>Sent:</B> Tuesday, June 17, =
2003 11:37=20
  AM<BR><B>To:</B> Woundy, Richard; 'milu@cisco.com'; =
'stevem@com21.com';=20
  'mdolas@broadcom.com'; 'jdemarty@juniper.net'; =
'e.cardona@cablelabs.com';=20
  'g.white@cablelabs.com'; 'john.gillis@adc.com'; 'lucy.pollak@ti.com'; =

  'alexb@coresma.com'; 'david.white@arrisi.com'; =
'matt.schmitt@arrisi.com';=20
  'kfriedman@correlant.com'; 'fred@stargus.com'; =
'joe@kar-el.cvnet.com';=20
  'W.Murwin@motorola.com'; 'ASundelin@stargus.com';=20
  'vhou@juniper.net'<BR><B>Cc:</B> Docsis 20 Reflector (E-mail); Docsis =
Oss=20
  Reflector (E-mail); Ipcdn List (E-mail); Raftus, =
David<BR><B>Subject:</B> rf=20
  mib draft v6 to draft v7 suggestions<BR><BR></FONT></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal style=3D"mso-layout-grid-align: none"><SPAN=20
  class=3DEmailStyle15><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt">Hi=20
  everyone,<o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"mso-layout-grid-align: none"><SPAN=20
  class=3DEmailStyle15><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt"><![if =
!supportEmptyParas]><![endif]>&nbsp;<o:p></o:p></SPAN></FONT></SPAN></P>=

  <P class=3DMsoNormal style=3D"mso-layout-grid-align: none"><SPAN=20
  class=3DEmailStyle15><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt">Since RF mib v2 =
draft 6=20
  was released in March, I have received publicly or privately 17 =
requests for=20
  updates/changes to appear in draft v7. The people on the To: list =
have=20
  participated in either initiating or commenting on the suggestions.=20
  <o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"mso-layout-grid-align: none"><SPAN=20
  class=3DEmailStyle15><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt"><![if =
!supportEmptyParas]><![endif]>&nbsp;<o:p></o:p></SPAN></FONT></SPAN></P>=

  <P class=3DMsoNormal style=3D"mso-layout-grid-align: none"><SPAN=20
  class=3DEmailStyle15><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt">Could I ask =
these people=20
  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=20
  undertaking. The wider communities are also welcome to=20
  comment.<o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"mso-layout-grid-align: none"><SPAN=20
  class=3DEmailStyle15><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt"><![if =
!supportEmptyParas]><![endif]>&nbsp;<o:p></o:p></SPAN></FONT></SPAN></P>=

  <P class=3DMsoNormal style=3D"mso-layout-grid-align: none"><SPAN=20
  class=3DEmailStyle15><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt">Thanks for your =

  time,<o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"mso-layout-grid-align: none"><SPAN=20
  class=3DEmailStyle15><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; mso-bidi-font-size: =
12.0pt">Dave<o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"mso-layout-grid-align: none"><FONT=20
  face=3D"Courier New" size=3D1><SPAN=20
  style=3D"FONT-SIZE: 8.5pt; FONT-FAMILY: 'Courier New'"><![if =
!supportEmptyParas]><![endif]>&nbsp;</SPAN></FONT><FONT=20
  face=3D"Courier New" size=3D1><SPAN=20
  style=3D"FONT-SIZE: 8.5pt; COLOR: black; FONT-FAMILY: 'Courier New'; =
mso-color-alt: windowtext"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal style=3D"mso-layout-grid-align: none"><FONT=20
  face=3D"Courier New" size=3D1><SPAN=20
  style=3D"FONT-SIZE: 8.5pt; FONT-FAMILY: 'Courier New'"><BR><BR>1) =
Return name to=20
  pre draft v6 DOCS-IF-MIB from draft v6 DOCS-IETF-RFI-MIB. =
<BR><BR>Contributors=20
  - Rich Woundy IPCDN/Comcast, Minnie Lu Cisco, Steve Malenfant=20
  Com21<BR><BR><BR>2) docsIfCmtsChannelUtUtilization formula - remove =
line (100=20
  * ((raw bytes - stuffed bytes) / raw bytes))<BR>since it assumes that =
MPEG=20
  payload consists only DOC MAC payload. As we <BR>know, MPEG could =
consist=20
  video payload and NULL packets. Suggest to remove <BR>this line since =
the=20
  first 2 lines in the formula are good enough.<BR><BR>Contributor - =
Minnie=20
  Lu<SPAN style=3D"mso-tab-count: 1">&nbsp;&nbsp;&nbsp; =
</SPAN>Cisco<BR><BR><BR>3)=20
  Add discontinuity descriptions to all counters related to an=20
  interface.<BR><BR>Contributor - Minnie Lu<SPAN=20
  style=3D"mso-tab-count: 1">&nbsp;&nbsp;&nbsp; =
</SPAN>Cisco<BR><BR><BR>4)=20
  docsIfCmtsInsertInterval - For the docsIfCmtsInsertInterval object, =
there is=20
  no such thing as a <BR>"broadcast station maintenance" interval for =
new modems=20
  joining the network.<SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp;=20
  </SPAN>Station should be <BR>changed to initial to make the text read =
- "The=20
  amount of time to elapse between each broadcast <BR>initial =
maintenance=20
  grant.<SPAN style=3D"mso-spacerun: yes">&nbsp; </SPAN>Broadcast =
initial=20
  maintenance grants are used to allow new cable modems <BR>to join the =

  network.<SPAN style=3D"mso-spacerun: yes">&nbsp; </SPAN>Zero =
indicates that a=20
  vendor-specific algorithm is used instead of a fixed time.<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN><BR>Maximum amount of time =
permitted=20
  by the specification is 2 seconds."<BR><BR>Contributor - Margo Dolas=20
  Broadcom<BR><BR><BR>5) docsIfCmtsModPreambleType - (Joel) In=20
  docsIfCmtsModulationTable, the docsIfCmtsModPreambleType object has =
<BR>2=20
  possible values qpsk0(1) and qpsk1(2). It seems like it's the only =
object in=20
  this table without a <BR>meaningful default value when this parameter =
does not=20
  make sense. For instance, for a TDMA modulation <BR>profile using =
QAM16, the=20
  actual preamble type is indeed not QPSK0 but something else. Does it =
make=20
  sense <BR>to have a value of 0 in this case, like=20
  docsIfCmtsModScdmaInterleaverStepSize for non-SCDMA =
profiles?<BR><BR>(Eduardo)=20
  for the benefit of clarifications wouldn't be good to have a =
enumeration=20
  unknown(0) for this <BR>object when not a 2.0 burst ?<BR>Also a note =
in the=20
  DESCRIPTION like "if docsIfCmtsModChannelType is tdma(1) a value =
unknown(0) is=20
  used for this object" <BR>I would say unknown(0) rather than =
unknown(3) since=20
  it looks like the possible current implementation may be =
reporting<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN><BR>'0' , and defendable in =
IETF since=20
  RFC 3291 uses '0' for inetAddressType<BR><BR>Contributors - Joel =
Demarty=20
  Juniper, Eduardo Cardona Cablelabs<BR><BR><BR>6) =
docsIfUpstreamChannelTable=20
  clone mechanism - improve descriptive wording. The spec is vague =
about the=20
  minimum set of parameters <BR>that the <BR>CMTS must transfer during =
a clone=20
  operation to be DOCSIS 2.0 compliant. Only those starting with=20
  docsIfUpChannelScdma or <BR>all parameters defining an SCDMA channel, =
like the=20
  channel width? Then what about the frequency? <BR>Definitely, this =
clone=20
  mechanism is sophisticated enough that it would deserve a more =
detailed=20
  specification <BR>(and testing) and, as a consequence, an=20
  ECR.<BR><BR>Contributor - Joel Demarty Juniper<BR><BR><BR>7)=20
  docsIfUpChannelPreEqEnable - add DEFVAL clause.<BR><BR>Contributor - =
John=20
  Gillis ADC<BR><BR><BR>8) docsIfCmtsUpChnlCtrUcastGrantedMslots - In =
Cisco=20
  CMTS, we use IUC14 (reserved) and SID (HEX): 1FFF (max. of =
<BR>unicast sid=20
  number) for quite some time.<BR>Q: Should it be counted in=20
  docsIfCmtsUpChnlCtrUcastGrantedMslots ?<BR>My personal think that =
this objects=20
  seems to mean the <BR>meaningful<SPAN style=3D"mso-spacerun: =
yes">&nbsp;=20
  </SPAN>UNICAST SID, so user could get a good idea about the how many=20
  <BR>minislots really assigned to some meaningful CM.<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN>So, the reserved IUCs =
<BR>should be=20
  excluded from this object though minislots for reserved IUCs are =
<BR>still be=20
  counted into docsIfCmtsUpChnlCtrTotalMslots.<BR>Minnie,<BR>I agree, I =
think=20
  IUC14 grants to SID 1FFF (assuming the CMTS reserves<BR>that SID to =
mean no=20
  CM) should not be counted in UcastGrantedMslots.<BR>I also think (and =
maybe=20
  this case is more obvious) than grants to SID 0<BR>should not be =
counted in=20
  UcastGrantedMslots.<BR>This brings up a question that I've had for =
some=20
  time.<SPAN style=3D"mso-spacerun: yes">&nbsp; </SPAN>Why does =
the<BR>Cisco CMTS=20
  use IUC14 and SID 1FFF????<SPAN style=3D"mso-spacerun: yes">&nbsp; =
</SPAN>The=20
  use of IUC14 is prohibited by<BR>the spec, since it is labeled as =
"Reserved",=20
  and SID 0 is already<BR>defined to mean "no =
CM".<BR>-Greg<BR><BR>Contributors=20
  - Minnie Lu Cisco, Greg White Cablelabs<BR><BR><BR>9) =
docsIfCmStatusTable -=20
  possibly add new objects for successful/failed ucc transactions. =
<BR>Hi,=20
  Alex,<BR>I do not think that this is good idea. What will you count=20
  into<BR>docsQosDCCAcks? The relationships between DCC Req/Rsp/Ack is =
important=20
  and<BR>should not be lost because of UCC additions. I guess, the =
better place=20
  for<BR>this counters is RFI MIB docsIfCmStatusTable. It may be =
extended in=20
  future<BR>versions.<BR>Regards.<BR>Lucy<BR>Hello all,<BR>A question =
about=20
  counting successful and failed UCC transactions.<BR>It seems like =
there is no=20
  counters dedicated for UCC failed or<BR>succeeded operation as it is =
for DCC=20
  transactions.<BR>The question is, since UCC is a subset of DCC =
operation for=20
  1.1 modem,<BR>should the modem count UCC transactions in DCC counters =

  (docsQosDCCs,<BR>docsQosDCCFails) ?<BR>Thank you in=20
  advance.<BR><BR>Contributors - Lucy Pollak TI, Alex Betis=20
  Coresma<BR><BR><BR>10) docsIfUpChannelPreEqEnable,=20
  docsIfCmStatusEqualizationData - clarify =
descriptions.<BR>Lucy,<BR>Sorry for=20
  the delay in responding.<SPAN style=3D"mso-spacerun: yes">&nbsp; =
</SPAN>I don't=20
  have an objection to your proposal, as long as the <BR>format of the =
object is=20
  clear.<BR>To summarize, the object docsIfCmStatusEqualizationData =
will only=20
  include the "value" from figure 8-23.<SPAN style=3D"mso-spacerun: =
yes">&nbsp;=20
  </SPAN><BR>In other words, the first byte reported in the MIB object =
will be=20
  the main tap location.<SPAN style=3D"mso-spacerun: yes">&nbsp; =
</SPAN>A=20
  clarification <BR>should also be made to the description of=20
  docsIfUpChannelPreEqEnable to indicate your interpretation (b). =
<BR>Regarding=20
  the question about reverse taps, figure 8-23 is a simplification of =
figure=20
  6-23 from the 1.1 RFI <BR>spec (which includes a format to encode =
reverse=20
  taps).<SPAN style=3D"mso-spacerun: yes">&nbsp; </SPAN>It seems to =
make sense to=20
  me to use the format <BR>shown in that figure.<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN>Perhaps this MIB object =
could be=20
  clarified to reference both figures.<BR>-Greg<BR><BR>Greg,<BR>to =
summarize our=20
  objections:<BR>1. MIB requires equalization data, then type/length is =

  irrelevant.<BR>2. There are 2 possible types 4 (Transmit Equalization =
Adjust)=20
  or 9 (Transmit Equalization Set), which is <BR>irrelevant after=20
  convolution.<BR>3. To be consistent with DS equa data, some TLV =
should be=20
  added also into it. What?<BR>We propose to use only value from =
referenced=20
  figure without type/length to avoid questions in the future. If not, =
<BR>(2)=20
  and (3) should be clarified. I guess, that it will be also very =
helpful if=20
  clarification (b) will be entered into MIB. <BR>Best=20
  Regards.<BR>Lucy<BR><BR>Contributors - Lucy Pollak TI, Greg White=20
  Cablelabs<BR><BR><BR>11) docsIfSignalQualityEntry - clarify wording =
for back=20
  compatibility.<BR>In draft -03 the description of<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN>docsIfSignalQualityEntry =
was changed=20
  <BR>from : <BR>docsIfSignalQualityEntry OBJECT-TYPE <BR><SPAN=20
  style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>SYNTAX<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>DocsIfSignalQualityEntry <BR><SPAN=20
  style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>MAX-ACCESS<SPAN style=3D"mso-spacerun: yes">&nbsp; =
</SPAN>not-accessible=20
  <BR><SPAN=20
  style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>STATUS<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>current <BR><SPAN=20
  style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>DESCRIPTION <BR><SPAN=20
  style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;=20
  </SPAN>"At the CM, describes the PHY characteristics of a <BR><SPAN=20
  style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>downstream channel. At the CMTS, describes the PHY <BR>signal =
<BR><SPAN=20
  style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>quality of an upstream channel. <BR><SPAN=20
  style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>An entry in this table exists for each ifEntry with an =
<BR><SPAN=20
  style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>ifType of docsCableUpstream(129) for Cable Modem =
<BR>Termination=20
  <BR><SPAN=20
  style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>Systems and docsCableDownstream(128) for Cable Modems." =
<BR><SPAN=20
  style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>INDEX { ifIndex } <BR><SPAN=20
  style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>::=3D { docsIfSignalQualityTable 1 } <BR>to :=20
  <BR>docsIfSignalQualityEntry OBJECT-TYPE <BR><SPAN=20
  style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>SYNTAX<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>DocsIfSignalQualityEntry <BR><SPAN=20
  style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>MAX-ACCESS<SPAN style=3D"mso-spacerun: yes">&nbsp; =
</SPAN>not-accessible=20
  <BR><SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>STATUS<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>current <BR><SPAN=20
  style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>DESCRIPTION <BR><SPAN=20
  style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

  </SPAN>"At the CM, describes the PHY characteristics of a <BR><SPAN=20
  style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
  </SPAN>downstream channel. At the CMTS, describes the PHY signal =
<BR><SPAN=20
  style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
  </SPAN>quality of an upstream channel. <BR><SPAN=20
  style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
  </SPAN>An entry in this table exists for each ifEntry with an =
<BR><SPAN=20
  style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
  </SPAN>ifType of docsCableUpstreamChannel(205) for Cable Modem =
<BR>Termination=20
  <BR><SPAN=20
  style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
  </SPAN>Systems and docsCableDownstream(128) for Cable Modems." =
<BR><SPAN=20
  style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>INDEX { ifIndex } <BR><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;</SPAN>::=3D { =
docsIfSignalQualityTable 1 }=20
  <BR>But now RFI mib also apply to 1.1 CMTSes with no concept of =
ifType 205=20
  <BR>but 129 <BR><BR>Contributor - Eduardo Cardona =
Cablelabs<BR><BR><BR>12)=20
  docsIfCmtsCmStatusValue - add new defined value=20
  registeredBPIInitializing(9),<BR>deprecate former value=20
  operational(8).<BR><BR>Contributors - Eduardo Cardona Cablelabs, Lucy =
Pollak=20
  TI, Minnie Lu Cisco, David White Arris,<BR>Matt Schmitt Arris, Kirk =
Friedman=20
  Correlant, Fred Oko Stargus, Joe Godas Kar-el, Steve Malenfant=20
  Com21<BR><BR><BR>13) Adjust compliance statements for objects =
designated=20
  optional. Add separate augmentation table for <BR>optional objects in =

  docsIfCmtsUpChannelCounterTable.<BR><BR>Contributors - Will Murwin =
Motorola,=20
  Rich Woundy IPCDN/Comcast, Mike StJohns Mindspring, Eduardo Cardona=20
  Cablelabs<BR><BR><BR>14) Add section explaining counter interaction =
between=20
  Docsis 1.0/1.1/2.0.<BR>The QOS MIB tried to handle<BR>DOCSIS 1.1 =
changes to=20
  RFC2670. Now that rfc2670 is being obsoleted, the rf-mib v2 and the =
DOCSIS OSS=20
  Specs is the place<BR>that should clearly state how these counters =
and other=20
  tables interact in DOCSIS 1.0, DOCSIS 1.1, and DOCSIS 2.0.<BR>I would =
even=20
  hope to see a section in the rf-mib v2, "Interoperation with the =
version of=20
  DOCSIS" like or to replace<BR>what the DOCSIS QOS MIB has. This is =
the place=20
  to describe what table are populated under the docsIfMib when =
the<BR>the=20
  modems are registering.<BR>This way this issue can be re-discussed =
and=20
  whatever conculsion is reached, can be document in the description of =

  those<BR>objects.<BR><BR>Contributor - Will Murwin Motorola, Minnie =
Lu=20
  Cisco<BR><BR><BR>15) Change docsIfCmtsServiceTable to count packets =
for both=20
  upstream and downstream flows. <BR>One of the things that has long =
been an=20
  issue with the RF MIB is that the docsIfCmtsServiceTable only counts=20
  <BR>InOctets and InPackets (i.e. upstream packets only). If the =
reason for=20
  keeping this table is to support DOCSIS <BR>1.0 modems would it also =
make=20
  sense to add downstream packet counts to this table, too? Many =
CMTS'es already=20
  <BR>count this information and store it in a proprietary MIB. It =
would be nice=20
  to standardize this as a requirement <BR>so that NMS such as usage =
monitoring=20
  systems could (a) count on it existing and (b) find it in a standard=20
  location.<BR><BR>Contributor - Andrew Sundelin Stargus<BR><BR><BR>16) =
Add 4=20
  objects to docsIfCmtsCmStatusTable<BR>While writing DOCS-IETF-QOS-MIB =
version=20
  9, I find myself still thinking about Minnie suggestion of =
having<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; =
</SPAN><BR>docsIfCmtsServiceInPackets and=20
  docsIfCmtsServiceInOctets count for DOCSIS 1.1 and 2.0. Even though =
the QOS=20
  <BR>MIB has pawned off this discussion, I have had some thoughts on =
the=20
  subject.<BR>(1) If these counters where used to count the DOCSIS 1.1 =
and 2.0,=20
  than this would the best place in all <BR>of the mibs to<BR><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>get a quick =
summary of the=20
  upstream data received by a particular modem, no matter the =
version.<BR>(2) At=20
  the same time, The rest of the docsIfCmtsCmServiceTable might not =
make sense=20
  for DOCSIS 1.1 or 2.0<BR>However the more I looked around at the =
different=20
  counters that existed in all of MIB required by DOCSIS, <BR>the more =
I kept=20
  looking for an overall counter on the CMTS to count data packet =
received and=20
  transmitted <BR>for a particular CM. <BR>I would like to start a =
discussion on=20
  about adding 4 new object to the=20
  docsIfCmtsCmStatusTable:<BR>docsIfCmtsCmStatusInPackets=20
  =
<BR>docsIfCmtsCmStatusInOctets<BR>docsIfCmtsCmStatusOutPackets<BR>docsIf=
CmtsCmStatusOutoctets<BR>While=20
  I understand that these counts can be gathered by via numerous =
objects on both=20
  the CMTS and CM <BR>and then just appling simple math. However I want =
to query=20
  only one agent and just get a quick summary <BR>without have to =
determine=20
  which version of DOCSIS the modem is, which will determine which mibs =
I look=20
  etc.<BR>and objects I query.<BR><BR>For example if I want query only =
one=20
  agent(i.e. the CMTS) and get the number of transmitted and received =
<BR>data=20
  for each CM, then <BR><SPAN=20
  style=3D"mso-tab-count: 1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>(1)=20
  GET-NEXT the docsIfCmtsCmStatusRegMode to see what version of DOCSIS =
this=20
  modem is operting <BR><BR><SPAN=20
  style=3D"mso-tab-count: 1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>if=20
  'docsis10(1)' then <BR><SPAN=20
  style=3D"mso-tab-count: =
3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>(2) WALK the entire docsIfCmtsServiceTable for ifIndex and SID =

  that<BR><SPAN style=3D"mso-tab-count: =
1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN><SPAN=20
  style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>have docsIfCmtsServiceNewCmStatusIndex that matches the index =
for step=20
  (1).<BR><SPAN style=3D"mso-tab-count: =
1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN><BR><SPAN=20
  style=3D"mso-tab-count: =
3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>(3) Add the all the instances of docsIfCmtsServiceInPacket for =

  the<BR><SPAN style=3D"mso-tab-count: =
1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN><SPAN=20
  style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>ifIndex and SIDs that match from step(2) to get the total =
Received=20
  packets from a CM.<BR><BR><SPAN=20
  style=3D"mso-tab-count: =
3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>NOTE: Not sure it is possible to get from a CMTS agent from =
the=20
  Standard MIBs the number of <BR><SPAN=20
  style=3D"mso-tab-count: 1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN><SPAN=20
  style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>of packets transmitted to a single docsis 1.0 cable =
modem.<BR><BR><SPAN=20
  style=3D"mso-tab-count: 1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>else if=20
  'docsis11(2)' or 'docsis20()' then<BR><SPAN 
  style=3D"mso-tab-count: =
3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>(2) WALK the docsQosCmtsMacToSrvFlowTable all for the =
instances of that=20
  contain the<BR><SPAN=20
  style=3D"mso-tab-count: 1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN><SPAN=20
  style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>same mac address.<BR><SPAN=20
  style=3D"mso-tab-count: =
2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;=20
  </SPAN><SPAN style=3D"mso-tab-count: =
1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>(3) Then GET the docQosServiceFlowPkts using the ifIndex =
and<BR><SPAN=20
  style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>service flow id from step(2). Add this to the total of =
received or=20
  transmitted for this CM.<BR><SPAN=20
  style=3D"mso-tab-count: =
3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>To =
determine=20
  the direction of the flow use the same index and query the=20
  docsQosServiceFlowDirection.<BR>This seems very complicated for =
something so=20
  simple. This is just a suggestion of simple way the RF MIB v2 can =
correct the=20
  <BR>mistakes of the past.<SPAN style=3D"mso-spacerun: yes">&nbsp;=20
  </SPAN><BR><BR>Contributors - Will Murwin Motorola, Minnie Lu=20
  Cisco<BR><BR><BR>17) docsIfCmtsCmStatusTimingOffset - possibly change =

  decription of existing object or<BR>add new object to reconcile unit=20
  differences between 1.1/2.0. Still under =
discussion.<BR><BR>Contributors -=20
  Victor Hou Juniper, Rich Woundy IPCDN/Comcast, Kirk Friedman=20
  Correlant.<BR><BR><BR><BR style=3D"mso-special-character: =
line-break"><![if !supportLineBreakNewLine]><BR=20
  style=3D"mso-special-character: =
line-break"><![endif]></SPAN></FONT><FONT=20
  face=3D"Courier New" size=3D1><SPAN=20
  style=3D"FONT-SIZE: 8.5pt; COLOR: black; FONT-FAMILY: 'Courier New'; =
mso-color-alt: windowtext"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><SPAN class=3DEmailStyle15><FONT face=3DArial =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt"><![if =
!supportEmptyParas]><![endif]>&nbsp;<o:p></o:p></SPAN></FONT></SPAN></P>=

  <P class=3DMsoNormal><SPAN class=3DEmailStyle15><FONT face=3DArial =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt"><![if =
!supportEmptyParas]><![endif]>&nbsp;<o:p></o:p></SPAN></FONT></SPAN></P>=

  <P class=3DMsoNormal><!--[if supportFields]><span =
style=3D'mso-element:field-begin'></span><span=20
style=3D"mso-spacerun: yes">&nbsp;</span>AUTOTEXTLIST \s &quot;E-mail=20
Signature&quot; <span =
style=3D'mso-element:field-separator'></span><![endif]--><FONT=20
  color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; mso-bidi-font-size: =
12.0pt">************************************<o:p></o:p></SPAN></FONT></P=
>
  <P class=3DMsoNormal><I style=3D"mso-bidi-font-style: normal"><FONT =
face=3DArial=20
  color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-STYLE: italic; =
mso-bidi-font-size: 12.0pt">David=20
  Raftus<o:p></o:p></SPAN></FONT></I></P>
  <P class=3DMsoNormal><I style=3D"mso-bidi-font-style: normal"><FONT =
face=3DArial=20
  color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-STYLE: italic; =
mso-bidi-font-size: 12.0pt">Terayon=20
  Canada Ltd<o:p></o:p></SPAN></FONT></I></P>
  <P class=3DMsoNormal><I style=3D"mso-bidi-font-style: normal"><FONT =
face=3DArial=20
  color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-STYLE: italic; =
mso-bidi-font-size: 12.0pt">340=20
  Terry Fox Drive, Suite 202<o:p></o:p></SPAN></FONT></I></P>
  <P class=3DMsoNormal><I style=3D"mso-bidi-font-style: normal"><FONT =
face=3DArial=20
  color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-STYLE: italic; =
mso-bidi-font-size: 12.0pt">Ottawa=20
  Canada<SPAN style=3D"mso-spacerun: yes">&nbsp; </SPAN>K2K=20
  3A2<o:p></o:p></SPAN></FONT></I></P>
  <P class=3DMsoNormal><I style=3D"mso-bidi-font-style: normal"><FONT =
face=3DArial=20
  color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-STYLE: italic; =
mso-bidi-font-size: 12.0pt"><![if =
!supportEmptyParas]><![endif]>&nbsp;<o:p></o:p></SPAN></FONT></I></P>
  <P class=3DMsoNormal><I style=3D"mso-bidi-font-style: normal"><FONT =
face=3DArial=20
  color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-STYLE: italic; =
mso-bidi-font-size: 12.0pt">david.raftus@terayon.com<SPAN=20
  style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN><o:p></o:p></SPAN></FONT></I></P>
  <P class=3DMsoNormal><I style=3D"mso-bidi-font-style: normal"><FONT =
face=3DArial=20
  color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-STYLE: italic; =
mso-bidi-font-size: 12.0pt">613.592.1052<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN>ext=20
  222<o:p></o:p></SPAN></FONT></I></P>
  <P class=3DMsoNormal><I style=3D"mso-bidi-font-style: normal"><FONT =
face=3DArial=20
  color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-STYLE: italic; =
mso-bidi-font-size: 12.0pt">************************************<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN></SPAN></FONT></I><FONT =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt"><SPAN=20
  style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;</SPAN><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblack size=3D1><SPAN=20
  style=3D"FONT-SIZE: 9pt"><![if =
!supportEmptyParas]><![endif]>&nbsp;</SPAN><o:p></o:p></FONT></P>
  <P class=3DMsoNormal><!--[if supportFields]><span =
style=3D'mso-element:field-end'></span><![endif]--><![if =
!supportEmptyParas]><![endif]>&nbsp;<o:p></o:p></P></DIV></BLOCKQUOTE></=
BODY></HTML>

------_=_NextPart_001_01C339AD.73D15550--

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



From exim@www1.ietf.org  Tue Jun 24 13:56:31 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27598
	for <ipcdn-archive@odin.ietf.org>; Tue, 24 Jun 2003 13:56:31 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5OHu3424007
	for ipcdn-archive@odin.ietf.org; Tue, 24 Jun 2003 13:56:03 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Us1Q-0006Ee-T8; Tue, 24 Jun 2003 13:56:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Us0f-0006DY-3u
	for ipcdn@optimus.ietf.org; Tue, 24 Jun 2003 13:55:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27448
	for <ipcdn@ietf.org>; Tue, 24 Jun 2003 13:55:10 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Us0c-00055J-00
	for ipcdn@ietf.org; Tue, 24 Jun 2003 13:55:10 -0400
Received: from ondar.cablelabs.com ([192.160.73.61])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Us0R-00052k-00
	for ipcdn@ietf.org; Tue, 24 Jun 2003 13:54:59 -0400
Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20])
	by ondar.cablelabs.com (8.12.9/8.12.9) with ESMTP id h5OHrgwQ020186
	for <ipcdn@ietf.org>; Tue, 24 Jun 2003 11:53:42 -0600 (MDT)
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 24 Jun 2003 11:53:42 -0600
Message-ID: <E63E74E1F5391449BDFCAE1F352EC7DC01B3E8E5@srvxchg.cablelabs.com>
Thread-Topic: WGLC for MTA device mib
thread-index: AcM6eYwWK0L6MFjoSr+EJS0JsprTSg==
From: "Jean-Francois Mule" <jf.mule@cablelabs.com>
To: <ipcdn@ietf.org>
X-Approved: ondar
Content-Transfer-Encoding: quoted-printable
Subject: [ipcdn] WGLC for MTA device mib
Sender: ipcdn-admin@ietf.org
Errors-To: ipcdn-admin@ietf.org
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

Rich and I would like to request WGLC of the MTA device mib
Internet-Draft. The latest draft has been revised according to the
comments received on the list.

The current version can be found at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-mtamib-01.txt


We'd like to close WGLC by about July 18.
Please copy comments to the authors & ipcdn list. Thank you in advance.

-- Jean-Francois.

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



From exim@www1.ietf.org  Tue Jun 24 13:57:28 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27656
	for <ipcdn-archive@odin.ietf.org>; Tue, 24 Jun 2003 13:57:28 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5OHv0324178
	for ipcdn-archive@odin.ietf.org; Tue, 24 Jun 2003 13:57:00 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Us2O-0006Hr-EG; Tue, 24 Jun 2003 13:57:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19Us1q-0006Fm-T3
	for ipcdn@optimus.ietf.org; Tue, 24 Jun 2003 13:56:26 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27574
	for <ipcdn@ietf.org>; Tue, 24 Jun 2003 13:56:24 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Us1n-00056f-00
	for ipcdn@ietf.org; Tue, 24 Jun 2003 13:56:23 -0400
Received: from ondar.cablelabs.com ([192.160.73.61])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Us1c-00056N-00
	for ipcdn@ietf.org; Tue, 24 Jun 2003 13:56:13 -0400
Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20])
	by ondar.cablelabs.com (8.12.9/8.12.9) with ESMTP id h5OHtZwQ020242
	for <ipcdn@ietf.org>; Tue, 24 Jun 2003 11:55:35 -0600 (MDT)
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 24 Jun 2003 11:55:35 -0600
Message-ID: <E63E74E1F5391449BDFCAE1F352EC7DC01B3E8E6@srvxchg.cablelabs.com>
Thread-Topic: WGLC for MTA signaling mib
thread-index: AcM6ec6jR//dxQKpRAmLndaf/5rxpw==
From: "Jean-Francois Mule" <jf.mule@cablelabs.com>
To: <ipcdn@ietf.org>
X-Approved: ondar
Content-Transfer-Encoding: quoted-printable
Subject: [ipcdn] WGLC for MTA signaling mib
Sender: ipcdn-admin@ietf.org
Errors-To: ipcdn-admin@ietf.org
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

Rich and I would like to request WGLC of the MTA signaling mib
Internet-Draft.=20

The current version can be found at:
http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-01.t
xt


We'd like to close WGLC by about July 18.
Please copy comments to the authors & ipcdn list. Thank you in advance.

-- Jean-Francois.

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



From exim@www1.ietf.org  Wed Jun 25 11:06:28 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14098
	for <ipcdn-archive@odin.ietf.org>; Wed, 25 Jun 2003 11:06:27 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5PF62e26484
	for ipcdn-archive@odin.ietf.org; Wed, 25 Jun 2003 11:06:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VBqT-0006sP-1C; Wed, 25 Jun 2003 11:06:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VBpC-0006YL-79
	for ipcdn@optimus.ietf.org; Wed, 25 Jun 2003 11:04:42 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13168;
	Wed, 25 Jun 2003 10:54:24 -0400 (EDT)
Message-Id: <200306251454.KAA13168@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ipcdn@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 25 Jun 2003 10:54:24 -0400
Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-cable-gateway-tools-mib-00.txt
Sender: ipcdn-admin@ietf.org
Errors-To: ipcdn-admin@ietf.org
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP over Cable Data Network Working Group of the IETF.

	Title		: Cable Gateway Tools Management Information Base for 
                          CableHome compliant Residential Gateways
	Author(s)	: E. Cardona et al.
	Filename	: draft-ietf-ipcdn-cable-gateway-tools-mib-00.txt
	Pages		: 20
	Date		: 2003-6-24
	
This memo defines a portion of the Management Information Base (MIB) 
for use with network management protocols in the Internet community. 
In particular, it defines a basic set of managed objects for SNMP-
based management of CableHome compliant WAN Gateway Devices and home 
routers.  Specifically, this MIB defines managed objects for both a 
connection speed tool and an ICMP 'ping' tool between the Gateway and 
devices on the LAN. 
This memo specifies a MIB module in a manner that is compliant to the 
SNMP SMIv2 [5][6][7].  The set of objects is consistent with the SNMP 
framework and existing SNMP standards.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-cable-gateway-tools-mib-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ipcdn-cable-gateway-tools-mib-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ipcdn-cable-gateway-tools-mib-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-6-25103551.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipcdn-cable-gateway-tools-mib-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ipcdn-cable-gateway-tools-mib-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-6-25103551.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From exim@www1.ietf.org  Wed Jun 25 11:09:27 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14350
	for <ipcdn-archive@odin.ietf.org>; Wed, 25 Jun 2003 11:09:27 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5PF91K28906
	for ipcdn-archive@odin.ietf.org; Wed, 25 Jun 2003 11:09:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VBtN-0007Vw-KA; Wed, 25 Jun 2003 11:09:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VBpB-0006YL-Lx
	for ipcdn@optimus.ietf.org; Wed, 25 Jun 2003 11:04:41 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13152;
	Wed, 25 Jun 2003 10:54:19 -0400 (EDT)
Message-Id: <200306251454.KAA13152@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ipcdn@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 25 Jun 2003 10:54:19 -0400
Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-cable-gateway-security-mib-00.txt
Sender: ipcdn-admin@ietf.org
Errors-To: ipcdn-admin@ietf.org
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP over Cable Data Network Working Group of the IETF.

	Title		: Cable Gateway Security Management Information Base for
                          CableHome compliant Residential Gateways
	Author(s)	: E. Cardona et al.
	Filename	: draft-ietf-ipcdn-cable-gateway-security-mib-00.txt
	Pages		: 33
	Date		: 2003-6-24
	
This memo defines a portion of the Management Information Base (MIB) 
for use with network management protocols in the Internet community. 
In particular, it defines a basic set of managed objects for SNMP-
based security management of CableHome 1.0 compliant residential 
gateway devices. 
This memo specifies a MIB module in a manner that is compliant to the 
SNMP SMIv2 [5][6][7].  The set of objects is consistent with the SNMP 
framework and existing SNMP standards.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-cable-gateway-security-mib-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ipcdn-cable-gateway-security-mib-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ipcdn-cable-gateway-security-mib-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-6-25103540.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipcdn-cable-gateway-security-mib-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ipcdn-cable-gateway-security-mib-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-6-25103540.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From exim@www1.ietf.org  Wed Jun 25 11:09:28 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14356
	for <ipcdn-archive@odin.ietf.org>; Wed, 25 Jun 2003 11:09:27 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5PF92I28972
	for ipcdn-archive@odin.ietf.org; Wed, 25 Jun 2003 11:09:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VBtO-0007XB-2l; Wed, 25 Jun 2003 11:09:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VBpB-0006YL-G9
	for ipcdn@optimus.ietf.org; Wed, 25 Jun 2003 11:04:41 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13090;
	Wed, 25 Jun 2003 10:54:04 -0400 (EDT)
Message-Id: <200306251454.KAA13090@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ipcdn@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 25 Jun 2003 10:54:04 -0400
Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-cable-gateway-config-mib-00.txt
Sender: ipcdn-admin@ietf.org
Errors-To: ipcdn-admin@ietf.org
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP over Cable Data Network Working Group of the IETF.

	Title		: Cable Gateway Configuration Management Information 
                          Base 
                          for CableHome compliant Residential Gateways
	Author(s)	: E. Cardona et al.
	Filename	: draft-ietf-ipcdn-cable-gateway-config-mib-00.txt
	Pages		: 43
	Date		: 2003-6-24
	
This memo defines a portion of the Management Information Base (MIB) 
for use with network management protocols in the Internet community.  
In particular, it defines a basic set of managed objects for SNMP-
based management of DHCP [22] functionality within a CableHome 
compliant [21] residential gateway.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-cable-gateway-config-mib-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ipcdn-cable-gateway-config-mib-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ipcdn-cable-gateway-config-mib-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-6-25103508.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipcdn-cable-gateway-config-mib-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ipcdn-cable-gateway-config-mib-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-6-25103508.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From exim@www1.ietf.org  Wed Jun 25 11:17:31 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14351
	for <ipcdn-archive@odin.ietf.org>; Wed, 25 Jun 2003 11:09:27 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5PF91Z28930
	for ipcdn-archive@odin.ietf.org; Wed, 25 Jun 2003 11:09:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VBtN-0007WF-Qo; Wed, 25 Jun 2003 11:09:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VBpB-0006YL-J5
	for ipcdn@optimus.ietf.org; Wed, 25 Jun 2003 11:04:41 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13059;
	Wed, 25 Jun 2003 10:53:50 -0400 (EDT)
Message-Id: <200306251453.KAA13059@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ipcdn@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 25 Jun 2003 10:53:50 -0400
Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-cable-gateway-addressing-mib-00.txt
Sender: ipcdn-admin@ietf.org
Errors-To: ipcdn-admin@ietf.org
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP over Cable Data Network Working Group of the IETF.

	Title		: Cable Gateway Addressing Management Information Base 
                          for CableHome compliant Residential Gateways
	Author(s)	: E. Cardona et al.
	Filename	: draft-ietf-ipcdn-cable-gateway-addressing-mib-00.txt
	Pages		: 19
	Date		: 2003-6-24
	
This memo defines a portion of the Management Information Base (MIB) 
for use with network management protocols in the Internet community.  
In particular, it defines a basic set of managed objects for SNMP-
based management of Network Address Translation and transparent 
bridging functionality within a CableHome compliant residential 
gateway.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-cable-gateway-addressing-mib-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ipcdn-cable-gateway-addressing-mib-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ipcdn-cable-gateway-addressing-mib-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-6-25103457.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipcdn-cable-gateway-addressing-mib-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ipcdn-cable-gateway-addressing-mib-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-6-25103457.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From exim@www1.ietf.org  Wed Jun 25 11:17:32 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14099
	for <ipcdn-archive@odin.ietf.org>; Wed, 25 Jun 2003 11:06:27 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5PF62926485
	for ipcdn-archive@odin.ietf.org; Wed, 25 Jun 2003 11:06:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VBqT-0006sX-74; Wed, 25 Jun 2003 11:06:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VBpC-0006YL-4A
	for ipcdn@optimus.ietf.org; Wed, 25 Jun 2003 11:04:42 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13132;
	Wed, 25 Jun 2003 10:54:15 -0400 (EDT)
Message-Id: <200306251454.KAA13132@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ipcdn@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 25 Jun 2003 10:54:14 -0400
Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-cable-gateway-qos-mib-00.txt
Sender: ipcdn-admin@ietf.org
Errors-To: ipcdn-admin@ietf.org
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP over Cable Data Network Working Group of the IETF.

	Title		: Cable Gateway Quality of Service (QoS) Management 
                          Information Base for CableHome compliant Residential 
                          Gateways
	Author(s)	: A. Bhagwat et al.
	Filename	: draft-ietf-ipcdn-cable-gateway-qos-mib-00.txt
	Pages		: 20
	Date		: 2003-6-24
	
This memo defines a portion of the Management Information Base (MIB) 
for use with network management protocols in the Internet community.
In particular, it defines a basic set of managed objects for SNMP-
based management for prioritized Quality of Service functionality 
within a LAN, between a CableHome residential gateway device and 
CableHome compliant LAN host devices. 
This memo specifies a MIB module in a manner that is compliant to the 
SNMP SMIv2 [5][6][7].  The set of objects is consistent with the SNMP 
framework and existing SNMP standards.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-cable-gateway-qos-mib-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ipcdn-cable-gateway-qos-mib-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ipcdn-cable-gateway-qos-mib-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-6-25103530.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipcdn-cable-gateway-qos-mib-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ipcdn-cable-gateway-qos-mib-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-6-25103530.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From exim@www1.ietf.org  Wed Jun 25 11:35:40 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15720
	for <ipcdn-archive@odin.ietf.org>; Wed, 25 Jun 2003 11:35:35 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5PFZ7M03694
	for ipcdn-archive@odin.ietf.org; Wed, 25 Jun 2003 11:35:07 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VCIc-0000xA-Cz; Wed, 25 Jun 2003 11:35:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VBpB-0006YL-DH
	for ipcdn@optimus.ietf.org; Wed, 25 Jun 2003 11:04:41 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13110;
	Wed, 25 Jun 2003 10:54:10 -0400 (EDT)
Message-Id: <200306251454.KAA13110@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ipcdn@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 25 Jun 2003 10:54:10 -0400
Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-cable-gateway-device-mib-00.txt
Sender: ipcdn-admin@ietf.org
Errors-To: ipcdn-admin@ietf.org
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP over Cable Data Network Working Group of the IETF.

	Title		: Cable Gateway Device Management Information Base for 
                          CableHome compliant Residential Gateways
	Author(s)	: E. Cardona et al.
	Filename	: draft-ietf-ipcdn-cable-gateway-device-mib-00.txt
	Pages		: 37
	Date		: 2003-6-24
	
This memo defines a portion of the Management Information Base (MIB) 
for use with network management protocols in the Internet community. 
In particular, it defines a basic set of managed objects for SNMP 
based management of CableHome [21] compliant WAN Gateway Devices and 
home routers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-cable-gateway-device-mib-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ipcdn-cable-gateway-device-mib-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ipcdn-cable-gateway-device-mib-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-6-25103519.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipcdn-cable-gateway-device-mib-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ipcdn-cable-gateway-device-mib-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-6-25103519.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From exim@www1.ietf.org  Thu Jun 26 14:28:59 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13433
	for <ipcdn-archive@odin.ietf.org>; Thu, 26 Jun 2003 14:28:58 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5PFjSg22685
	for ipcdn-archive@odin.ietf.org; Wed, 25 Jun 2003 11:45:28 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VCSd-0005ti-3h; Wed, 25 Jun 2003 11:45:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19VBzS-0006YL-G7
	for ipcdn@optimus.ietf.org; Wed, 25 Jun 2003 11:15:33 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01375
	for <ipcdn@ietf.org>; Tue, 24 Jun 2003 21:31:33 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19UyQm-0000km-00
	for ipcdn@ietf.org; Tue, 24 Jun 2003 20:46:36 -0400
Received: from ondar.cablelabs.com ([192.160.73.61])
	by ietf-mx with esmtp (Exim 4.12)
	id 19UyQb-0000gh-00
	for ipcdn@ietf.org; Tue, 24 Jun 2003 20:46:25 -0400
Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20])
	by ondar.cablelabs.com (8.12.9/8.12.9) with ESMTP id h5P0jYwQ009908;
	Tue, 24 Jun 2003 18:45:34 -0600 (MDT)
Date: Tue, 24 Jun 2003 18:45:34 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message-ID: <E63E74E1F5391449BDFCAE1F352EC7DC0136108B@srvxchg.cablelabs.com>
content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Thread-Topic: Preliminary agenda for the IPCDN July 16'03 meeting in Vienna
Thread-Index: AcKF817qwqx0WLMUQ8ahOf2SFpiPNi0vOgXg
From: "Jean-Francois Mule" <jf.mule@cablelabs.com>
To: "IPCDN (E-mail)" <ipcdn@ietf.org>
Cc: "Richard Woundy" <Richard_Woundy@cable.comcast.com>
X-Approved: ondar
Content-Transfer-Encoding: quoted-printable
Subject: [ipcdn] Preliminary agenda for the IPCDN July 16'03 meeting in Vienna
Sender: ipcdn-admin@ietf.org
Errors-To: ipcdn-admin@ietf.org
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>,
	<mailto:ipcdn-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

This note is actually a call for agenda items for our next ipcdn wg
meeting. Please provide your input to me by July 1st.

Here's the preliminary agenda for the IPCDN WG meeting in Vienna.

=20
 IP over Cable Data Network WG (ipcdn)
=20
 Wednesday, July 16, 2003, at 0900-1130=20
 =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
 CHAIRS: Richard Woundy <Richard_Woundy@cable.comcast.com>
         Jean-Francois Mule <jf.mule@cablelabs.com>
=20
 AGENDA:
=20
 I.   Agenda Bashing
=20
 II.  Administration
       CableHome MIBs accepted as official wg items
       Determine new WG milestones
       WG handling of expired internet-drafts:
          applying the rule we discussed in the=20
          Atlanta meeting, 2 ipcdn wg meetings=20
          without any draft update =3D> draft is discontinued
          and removed from charter?
=20
 III. DOCSIS Submissions
    o  DOCSIS BPI+ MIB draft 09
       draft-ietf-ipcdn-bpiplus-mib-08.txt
       draft to be submitted soon
       review closure on MIB doctor review comments

    o  Subscriber Mgmt MIB draft 11
       draft-ietf-ipcdn-subscriber-mib-11.txt

    o  RF MIB v2 draft 07
       draft-ietf-ipcdn-docs-rfmibv2-06.txt
       draft to be submitted soon
       review of comments addressed in 07
       ready for WGLC

 IV. IPCablecom/PacketCable Submissions
    o MTA MIB
      draft-ietf-ipcdn-pktc-mtamib-01.txt
      any comments from the list?
      ready for WGLC

    o Signaling MIB
      draft-ietf-ipcdn-pktc-signaling-01.txt=20
      any comments from the list?
      ready for WGLC=20

    o Management Event MIB for PacketCable/IPCablecom=20
      draft-ietf-ipcdn-pktc-eventmess-02.txt
      draft to be submitted soon
      need volunteer to review against syslog & other event mgmt
mechanism

 V. CableHome Submissions

    o updated drafts:
      These drafts were submitted and should appear on ID repository
soon
      draft-ietf-ipcdn-cable-gateway-addressing-mib-00
      draft-ietf-ipcdn-cable-gateway-config-mib-00
      draft-ietf-ipcdn-cable-gateway-device-mib-00
      draft-ietf-ipcdn-cable-gateway-qos-mib-00
      draft-ietf-ipcdn-cable-gateway-config-mib-00
      -> need reviewers

 VI.  Status of other WG drafts

 VII. WG next steps

-- Richard Woundy and Jean-Francois Mule, IPCDN co-chairs

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