From mailnull@www1.ietf.org  Thu May  1 22:43:24 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 WAA22680
	for <ipcdn-archive@odin.ietf.org>; Thu, 1 May 2003 22:43:24 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h422ng831809
	for ipcdn-archive@odin.ietf.org; Thu, 1 May 2003 22:49:42 -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 h422nH831796;
	Thu, 1 May 2003 22:49: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 h422mQ831760
	for <ipcdn@optimus.ietf.org>; Thu, 1 May 2003 22:48: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 WAA22643
	for <ipcdn@ietf.org>; Thu, 1 May 2003 22:41:22 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19BQWK-0001RF-00
	for ipcdn@ietf.org; Thu, 01 May 2003 22:43:32 -0400
Received: from coral.tci.com ([198.178.8.81] helo=peacock.tci.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19BQWE-0001Qb-00
	for ipcdn@ietf.org; Thu, 01 May 2003 22:43:26 -0400
Received: from mms01-relaya.tci.com (mms01-relaya.broadband.att.com [147.191.90.228])
	by peacock.tci.com (8.12.9/8.12.9) with ESMTP id h422hCFv016469;
	Thu, 1 May 2003 20:43:12 -0600 (MDT)
Received: from 147.191.89.201 by mms01-relaya.tci.com with ESMTP (
 Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Thu, 01 May 2003 20:43:02
 -0600
Received: by entexchimc02.broadband.att.com with Internet Mail Service (
 5.5.2653.19) id <J79H6WQS>; Thu, 1 May 2003 20:42:22 -0600
Message-ID: <6732623D2548D61193C90002A5C88DCC056639C2@entmaexch02.broadband.att.com>
From: "Woundy, Richard" <Richard_Woundy@cable.comcast.com>
To: "'Stephen Palm'" <palm@broadcom.com>
cc: "IPCDN WG (E-mail)" <ipcdn@ietf.org>
Subject: RE: [ipcdn] IPCDN meeting minutes from San Francisco
Date: Thu, 1 May 2003 20:42:58 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-WSS-ID: 12AF04BC4396986-01-01
Content-Type: text/plain;
 charset=iso-8859-1
Content-Transfer-Encoding: 7bit
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

We don't have a timeline yet <http://www.ipcdn.org/milestones.html>, but I
agree it is needed.

-- Rich

-----Original Message-----
From: Stephen Palm [mailto:palm@broadcom.com]
Sent: Monday, April 21, 2003 1:08 PM
To: Woundy, Richard
Cc: IPCDN WG (E-mail)
Subject: Re: [ipcdn] IPCDN meeting minutes from San Francisco


Agreed!
So what is the revised timeline?

regards, kiwin


Woundy, Richard wrote:
> Stephen,
> 
> That *was* a very good question. But that material (CableHome 1.1 and the
> CableHome QoS MIB) is now publically available on:
> 
> http://www.cablelabs.com/projects/cablehome/specifications/
> 
> Now we should be able to tackle the CableHome drafts full-force!
> 
> -- Rich
> 
> -----Original Message-----
> From: Stephen Palm [mailto:palm@broadcom.com]
> Sent: Wednesday, April 02, 2003 6:36 PM
> To: Woundy, Richard
> Cc: IPCDN WG (E-mail)
> Subject: Re: [ipcdn] IPCDN meeting minutes from San Francisco
> 
> 
> 
> Woundy, Richard wrote:
> 
> 
>>Review of CableHome MIBs
>>------------------------
> 
> [...]
> 
>>No objections to accepting the CableHome MIBs were received from the
>>IPCDN mailing list, nor from the IETF meeting participants. The co-
>>chairs will add them to the WG charter.
> 
> 
> Some of the CableHome MIBs may point to material that might
> not be publically available.  In that light, what
> is the scope and timeline for CableHome MIBs?
> 
> regards, kiwin
> 


-- 
Stephen [kiwin] Palm   Ph.D.                          E:  palm@kiwin.com
Principal Engineer                                    T: +1-949-926-PALM
Broadcom Home & Wireless Networking Division          F: +1-530-325-9798
Irvine, California                               W: http://www.kiwin.com
    Secondary email accounts:   palm@hompna.org      palm@broadcom.com
s.palm@ieee.org  palm@itu.ch  spalm@cs.cmu.edu  palm@ics.t.u-tokyo.ac.jp

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



From mailnull@www1.ietf.org  Mon May  5 15:07:20 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 PAA12149
	for <ipcdn-archive@odin.ietf.org>; Mon, 5 May 2003 15:07:20 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h45JFRj27224
	for ipcdn-archive@odin.ietf.org; Mon, 5 May 2003 15:15:27 -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 h45JFM827217;
	Mon, 5 May 2003 15:15:22 -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 h45JE6827177
	for <ipcdn@optimus.ietf.org>; Mon, 5 May 2003 15:14:06 -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 PAA11897
	for <ipcdn@ietf.org>; Mon, 5 May 2003 15:05:14 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ClJ2-0007lY-00
	for ipcdn@ietf.org; Mon, 05 May 2003 15:07:20 -0400
Received: from ftpbox.mot.com ([129.188.136.101])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ClIw-0007lU-00
	for ipcdn@ietf.org; Mon, 05 May 2003 15:07:14 -0400
Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242])
	by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h45J7cNP008549
	for <ipcdn@ietf.org>; Mon, 5 May 2003 12:07:38 -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 h45J7aH4013865
	for <ipcdn@ietf.org>; Mon, 5 May 2003 14:07:36 -0500
Received: by ma07exm01.dma.isg.mot.com with Internet Mail Service (5.5.2656.59)
	id <HNFXDQKP>; Mon, 5 May 2003 15:07:36 -0400
Message-ID: <19CD0E423FC1D611893500508B6F0B9CF39672@ma07exm01.dma.isg.mot.com>
From: Murwin William-LWM008 <W.Murwin@motorola.com>
To: "'david.raftus@terayon.com'" <david.raftus@terayon.com>
Cc: "IPCDN (E-mail) (E-mail)" <ipcdn@ietf.org>
Date: Mon, 5 May 2003 15:07:30 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [ipcdn] "Optional" in the description of objects from the rfmibv2
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>

David,

	I was reading the description for the following objects:

docsIfCmtsUpChnlCtrCollCntnMslots              
docsIfCmtsUpChnlCtrTotalCntnReqMslots          
docsIfCmtsUpChnlCtrUsedCntnReqMslots           
docsIfCmtsUpChnlCtrCollCntnReqMslots           
docsIfCmtsUpChnlCtrTotalCntnReqDataMslots      
docsIfCmtsUpChnlCtrUsedCntnReqDataMslots       
docsIfCmtsUpChnlCtrCollCntnReqDataMslots       
docsIfCmtsUpChnlCtrTotalCntnInitMaintMslots    
docsIfCmtsUpChnlCtrUsedCntnInitMaintMslots     
docsIfCmtsUpChnlCtrCollCntnInitMaintMslots     
docsIfCmtsUpChnlCtrExtCollCntnMslots           
docsIfCmtsUpChnlCtrExtTotalCntnReqMslots       
docsIfCmtsUpChnlCtrExtUsedCntnReqMslots        
docsIfCmtsUpChnlCtrExtCollCntnReqMslots        
docsIfCmtsUpChnlCtrExtTotalCntnReqDataMslots   
docsIfCmtsUpChnlCtrExtUsedCntnReqDataMslots    
docsIfCmtsUpChnlCtrExtCollCntnReqDataMslots    
docsIfCmtsUpChnlCtrExtTotalCntnInitMaintMslots 
docsIfCmtsUpChnlCtrExtUsedCntnInitMaintMslots  
docsIfCmtsUpChnlCtrExtCollCntnInitMaintMslots

All contain the following description:

"...Support for this object is optional. If the object is not supported, a value of zero is returned." 
Yet in the compliance statement these object belong to the docsIfCmtsGroupV2 
Which is described as:
-- conditionally mandatory group 
GROUP docsIfCmtsGroupV2 DESCRIPTION "This group is implemented only in Cable Modem Termination Systems, not in Cable Modems." 
This description with the key word "optional" is confusing! If these objects are truly optional then they need not be implemented by the agent. 

rfc2580:
=======================================================================
	3.  Mapping of the OBJECT-GROUP macro

   For conformance purposes, it is useful to define a collection of
   related managed objects.  The OBJECT-GROUP macro is used to define
   each such collection of related objects.  It should be noted that the
   expansion of the OBJECT-GROUP macro is something which conceptually
   happens during implementation and not during run-time.

   To "implement" an object, an agent must return a reasonably accurate
   value for management protocol retrieval operations; similarly, if the
   object is writable, then in response to a management protocol set
   operation, an agent must accordingly be able to reasonably influence
   the underlying managed entity.  If an agent can not implement an
   object, the management protocol provides for it to return an
   exception or error, e.g, noSuchObject [4].  Under no circumstances
<----- NOTE
   shall an agent return a value for objects which it does not implement
<-----
   -- it must always return the appropriate exception or error, as
<------
   described in the protocol specification [4].  
========================================================================

I believe your intent is for these objects to be implemented by a CMTS agent, but not mandatory for the agent count these statistics.
I would remove the "optional" comment from the description of each of these objects and change the text to read "If statistics are not maintained by the agent, a value of zero is returned for this object."  or something to that nature.
But what really is need is a change to the description for the docsIfCmtsGroupV2, the comment above the group should be include in the description. I would go as far as to say these objects are "mandatory" for a CMTS agent, even though this is not a mandatory-group.
If I have mis-interrupted that these objects are not mandatory for the CMTS, then a new optional group is needed for the CMTS, just for these objects.
>From the current descriptions, am just not sure which approach you where trying to take. Any clarification is greatly appreciated.
Thanks,
Will Murwin



_____________________________
William Murwin
Broadband Communications Sector
Motorola Inc.
Email: W.Murwin@motorola.com
Tel: (508) 851-8385

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



From mailnull@www1.ietf.org  Mon May  5 16:01: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 QAA14146
	for <ipcdn-archive@odin.ietf.org>; Mon, 5 May 2003 16:01:16 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h45K9O131182
	for ipcdn-archive@odin.ietf.org; Mon, 5 May 2003 16:09:24 -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 h45K9L831157;
	Mon, 5 May 2003 16:09:21 -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 h45JpM829547
	for <ipcdn@optimus.ietf.org>; Mon, 5 May 2003 15:51: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 PAA13757
	for <ipcdn@ietf.org>; Mon, 5 May 2003 15:42:29 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Clt5-0000AF-00
	for ipcdn@ietf.org; Mon, 05 May 2003 15:44:35 -0400
Received: from desktop.terayon.com ([63.201.251.10] helo=SCBH02.terayon.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Clsz-00009s-00
	for ipcdn@ietf.org; Mon, 05 May 2003 15:44:29 -0400
Received: by scowa.terayon.com with Internet Mail Service (5.5.2656.59)
	id <KLA227B7>; Mon, 5 May 2003 12:17:16 -0700
Message-ID: <E54A98375651D511816A00306E06B970C4A174@OTNOAMEXCH01>
From: "Raftus, David" <david.raftus@imedia.com>
To: "'Murwin William-LWM008'" <W.Murwin@motorola.com>,
        "Raftus, David"
	 <david.raftus@imedia.com>
Cc: "IPCDN (E-mail) (E-mail)" <ipcdn@ietf.org>
Date: Mon, 5 May 2003 12:18:52 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3133B.29F339F0"
Subject: [ipcdn] RE: "Optional" in the description of objects from the rfmibv2
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_01C3133B.29F339F0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Will,

Thanks for the note. It's always surprising to see how well intentioned
words can be seen in another light. As you state, the intent is mandatory
implementation of the objects, but optional counting of the statistics
represented by the objects. I will make your suggested changes in v7.

Thanks,
Dave

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

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


-----Original Message-----
From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com]
Sent: Monday, May 05, 2003 3:08 PM
To: 'david.raftus@terayon.com'
Cc: IPCDN (E-mail) (E-mail)
Subject: "Optional" in the description of objects from the rfmibv2

David,

        I was reading the description for the following objects:

docsIfCmtsUpChnlCtrCollCntnMslots             
docsIfCmtsUpChnlCtrTotalCntnReqMslots         
docsIfCmtsUpChnlCtrUsedCntnReqMslots          
docsIfCmtsUpChnlCtrCollCntnReqMslots          
docsIfCmtsUpChnlCtrTotalCntnReqDataMslots     
docsIfCmtsUpChnlCtrUsedCntnReqDataMslots      
docsIfCmtsUpChnlCtrCollCntnReqDataMslots      
docsIfCmtsUpChnlCtrTotalCntnInitMaintMslots   
docsIfCmtsUpChnlCtrUsedCntnInitMaintMslots    
docsIfCmtsUpChnlCtrCollCntnInitMaintMslots    
docsIfCmtsUpChnlCtrExtCollCntnMslots          
docsIfCmtsUpChnlCtrExtTotalCntnReqMslots      
docsIfCmtsUpChnlCtrExtUsedCntnReqMslots       
docsIfCmtsUpChnlCtrExtCollCntnReqMslots       
docsIfCmtsUpChnlCtrExtTotalCntnReqDataMslots  
docsIfCmtsUpChnlCtrExtUsedCntnReqDataMslots   
docsIfCmtsUpChnlCtrExtCollCntnReqDataMslots   
docsIfCmtsUpChnlCtrExtTotalCntnInitMaintMslots
docsIfCmtsUpChnlCtrExtUsedCntnInitMaintMslots 
docsIfCmtsUpChnlCtrExtCollCntnInitMaintMslots

All contain the following description:

"...Support for this object is optional. If the object is not supported, a
value of zero is returned."
Yet in the compliance statement these object belong to the docsIfCmtsGroupV2
Which is described as:
-- conditionally mandatory group
GROUP docsIfCmtsGroupV2 DESCRIPTION "This group is implemented only in Cable
Modem Termination Systems, not in Cable Modems."
This description with the key word "optional" is confusing! If these objects
are truly optional then they need not be implemented by the agent.

rfc2580:
=======================================================================
        3.  Mapping of the OBJECT-GROUP macro

   For conformance purposes, it is useful to define a collection of
   related managed objects.  The OBJECT-GROUP macro is used to define
   each such collection of related objects.  It should be noted that the
   expansion of the OBJECT-GROUP macro is something which conceptually
   happens during implementation and not during run-time.

   To "implement" an object, an agent must return a reasonably accurate
   value for management protocol retrieval operations; similarly, if the
   object is writable, then in response to a management protocol set
   operation, an agent must accordingly be able to reasonably influence
   the underlying managed entity.  If an agent can not implement an
   object, the management protocol provides for it to return an
   exception or error, e.g, noSuchObject [4].  Under no circumstances
<----- NOTE
   shall an agent return a value for objects which it does not implement
<-----
   -- it must always return the appropriate exception or error, as
<------
   described in the protocol specification [4]. 
========================================================================

I believe your intent is for these objects to be implemented by a CMTS
agent, but not mandatory for the agent count these statistics.
I would remove the "optional" comment from the description of each of these
objects and change the text to read "If statistics are not maintained by the
agent, a value of zero is returned for this object."  or something to that
nature.
But what really is need is a change to the description for the
docsIfCmtsGroupV2, the comment above the group should be include in the
description. I would go as far as to say these objects are "mandatory" for a
CMTS agent, even though this is not a mandatory-group.
If I have mis-interrupted that these objects are not mandatory for the CMTS,
then a new optional group is needed for the CMTS, just for these objects.
>From the current descriptions, am just not sure which approach you where
trying to take. Any clarification is greatly appreciated.
Thanks,
Will Murwin



_____________________________
William Murwin
Broadband Communications Sector
Motorola Inc.
Email: W.Murwin@motorola.com
Tel: (508) 851-8385

------_=_NextPart_001_01C3133B.29F339F0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: &quot;Optional&quot; in the description of objects from the =
rfmibv2</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi Will,</FONT>
</P>

<P><FONT SIZE=3D2>Thanks for the note. It's always surprising to see =
how well intentioned words can be seen in another light. As you state, =
the intent is mandatory implementation of the objects, but optional =
counting of the statistics represented by the objects. I will make your =
suggested changes in v7.</FONT></P>

<P><FONT SIZE=3D2>Thanks,</FONT>
<BR><FONT SIZE=3D2>Dave</FONT>
</P>

<P><FONT SIZE=3D2>************************************</FONT>
<BR><FONT SIZE=3D2>David Raftus</FONT>
<BR><FONT SIZE=3D2>Terayon Canada Ltd</FONT>
<BR><FONT SIZE=3D2>340 Terry Fox Drive, Suite 202</FONT>
<BR><FONT SIZE=3D2>Ottawa Canada&nbsp; K2K 3A2</FONT>
</P>

<P><FONT =
SIZE=3D2>david.raftus@terayon.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>613.592.1052&nbsp; ext 222</FONT>
<BR><FONT =
SIZE=3D2>************************************&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Murwin William-LWM008 [<A =
HREF=3D"mailto:W.Murwin@motorola.com">mailto:W.Murwin@motorola.com</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Monday, May 05, 2003 3:08 PM</FONT>
<BR><FONT SIZE=3D2>To: 'david.raftus@terayon.com'</FONT>
<BR><FONT SIZE=3D2>Cc: IPCDN (E-mail) (E-mail)</FONT>
<BR><FONT SIZE=3D2>Subject: &quot;Optional&quot; in the description of =
objects from the rfmibv2</FONT>
</P>

<P><FONT SIZE=3D2>David,</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I was =
reading the description for the following objects:</FONT>
</P>

<P><FONT =
SIZE=3D2>docsIfCmtsUpChnlCtrCollCntnMslots&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>docsIfCmtsUpChnlCtrTotalCntnReqMslots&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>docsIfCmtsUpChnlCtrUsedCntnReqMslots&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>docsIfCmtsUpChnlCtrCollCntnReqMslots&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>docsIfCmtsUpChnlCtrTotalCntnReqDataMslots&nbsp;&nbsp;&nbsp;&nbs=
p; </FONT>
<BR><FONT =
SIZE=3D2>docsIfCmtsUpChnlCtrUsedCntnReqDataMslots&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>docsIfCmtsUpChnlCtrCollCntnReqDataMslots&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>docsIfCmtsUpChnlCtrTotalCntnInitMaintMslots&nbsp;&nbsp; =
</FONT>
<BR><FONT =
SIZE=3D2>docsIfCmtsUpChnlCtrUsedCntnInitMaintMslots&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT =
SIZE=3D2>docsIfCmtsUpChnlCtrCollCntnInitMaintMslots&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT =
SIZE=3D2>docsIfCmtsUpChnlCtrExtCollCntnMslots&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>docsIfCmtsUpChnlCtrExtTotalCntnReqMslots&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>docsIfCmtsUpChnlCtrExtUsedCntnReqMslots&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>docsIfCmtsUpChnlCtrExtCollCntnReqMslots&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>docsIfCmtsUpChnlCtrExtTotalCntnReqDataMslots&nbsp; =
</FONT>
<BR><FONT =
SIZE=3D2>docsIfCmtsUpChnlCtrExtUsedCntnReqDataMslots&nbsp;&nbsp; =
</FONT>
<BR><FONT =
SIZE=3D2>docsIfCmtsUpChnlCtrExtCollCntnReqDataMslots&nbsp;&nbsp; =
</FONT>
<BR><FONT =
SIZE=3D2>docsIfCmtsUpChnlCtrExtTotalCntnInitMaintMslots</FONT>
<BR><FONT SIZE=3D2>docsIfCmtsUpChnlCtrExtUsedCntnInitMaintMslots =
</FONT>
<BR><FONT SIZE=3D2>docsIfCmtsUpChnlCtrExtCollCntnInitMaintMslots</FONT>
</P>

<P><FONT SIZE=3D2>All contain the following description:</FONT>
</P>

<P><FONT SIZE=3D2>&quot;...Support for this object is optional. If the =
object is not supported, a value of zero is returned.&quot;</FONT>
<BR><FONT SIZE=3D2>Yet in the compliance statement these object belong =
to the docsIfCmtsGroupV2</FONT>
<BR><FONT SIZE=3D2>Which is described as:</FONT>
<BR><FONT SIZE=3D2>-- conditionally mandatory group</FONT>
<BR><FONT SIZE=3D2>GROUP docsIfCmtsGroupV2 DESCRIPTION &quot;This group =
is implemented only in Cable Modem Termination Systems, not in Cable =
Modems.&quot;</FONT></P>

<P><FONT SIZE=3D2>This description with the key word =
&quot;optional&quot; is confusing! If these objects are truly optional =
then they need not be implemented by the agent.</FONT></P>

<P><FONT SIZE=3D2>rfc2580:</FONT>
<BR><FONT =
SIZE=3D2>=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=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</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3.&nbsp; =
Mapping of the OBJECT-GROUP macro</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; For conformance purposes, it is useful =
to define a collection of</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; related managed objects.&nbsp; The =
OBJECT-GROUP macro is used to define</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; each such collection of related =
objects.&nbsp; It should be noted that the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; expansion of the OBJECT-GROUP macro is =
something which conceptually</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; happens during implementation and not =
during run-time.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; To &quot;implement&quot; an object, an =
agent must return a reasonably accurate</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; value for management protocol retrieval =
operations; similarly, if the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; object is writable, then in response to =
a management protocol set</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; operation, an agent must accordingly be =
able to reasonably influence</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; the underlying managed entity.&nbsp; If =
an agent can not implement an</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; object, the management protocol =
provides for it to return an</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; exception or error, e.g, noSuchObject =
[4].&nbsp; Under no circumstances</FONT>
<BR><FONT SIZE=3D2>&lt;----- NOTE</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; shall an agent return a value for =
objects which it does not implement</FONT>
<BR><FONT SIZE=3D2>&lt;-----</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; -- it must always return the =
appropriate exception or error, as</FONT>
<BR><FONT SIZE=3D2>&lt;------</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; described in the protocol specification =
[4]. </FONT>
<BR><FONT =
SIZE=3D2>=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=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</FONT>
</P>

<P><FONT SIZE=3D2>I believe your intent is for these objects to be =
implemented by a CMTS agent, but not mandatory for the agent count =
these statistics.</FONT></P>

<P><FONT SIZE=3D2>I would remove the &quot;optional&quot; comment from =
the description of each of these objects and change the text to read =
&quot;If statistics are not maintained by the agent, a value of zero is =
returned for this object.&quot;&nbsp; or something to that =
nature.</FONT></P>

<P><FONT SIZE=3D2>But what really is need is a change to the =
description for the docsIfCmtsGroupV2, the comment above the group =
should be include in the description. I would go as far as to say these =
objects are &quot;mandatory&quot; for a CMTS agent, even though this is =
not a mandatory-group.</FONT></P>

<P><FONT SIZE=3D2>If I have mis-interrupted that these objects are not =
mandatory for the CMTS, then a new optional group is needed for the =
CMTS, just for these objects.</FONT></P>

<P><FONT SIZE=3D2>From the current descriptions, am just not sure which =
approach you where trying to take. Any clarification is greatly =
appreciated.</FONT></P>

<P><FONT SIZE=3D2>Thanks,</FONT>
<BR><FONT SIZE=3D2>Will Murwin</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>_____________________________</FONT>
<BR><FONT SIZE=3D2>William Murwin</FONT>
<BR><FONT SIZE=3D2>Broadband Communications Sector</FONT>
<BR><FONT SIZE=3D2>Motorola Inc.</FONT>
<BR><FONT SIZE=3D2>Email: W.Murwin@motorola.com</FONT>
<BR><FONT SIZE=3D2>Tel: (508) 851-8385</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C3133B.29F339F0--
_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn



From mailnull@www1.ietf.org  Tue May  6 15:21: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 PAA05051
	for <ipcdn-archive@odin.ietf.org>; Tue, 6 May 2003 15:21:03 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h46JTfr20436
	for ipcdn-archive@odin.ietf.org; Tue, 6 May 2003 15:29:41 -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 h46JTG820419;
	Tue, 6 May 2003 15:29:16 -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 h46JSs820371
	for <ipcdn@optimus.ietf.org>; Tue, 6 May 2003 15:28:54 -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 PAA04974
	for <ipcdn@ietf.org>; Tue, 6 May 2003 15:19:46 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19D80e-0001YG-00
	for ipcdn@ietf.org; Tue, 06 May 2003 15:21:52 -0400
Received: from motgate5.mot.com ([144.189.100.105])
	by ietf-mx with esmtp (Exim 4.12)
	id 19D80d-0001YD-00
	for ipcdn@ietf.org; Tue, 06 May 2003 15:21:51 -0400
Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131])
	by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h46JMfsI015146
	for <ipcdn@ietf.org>; Tue, 6 May 2003 12:22:41 -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 h46JMdac030472
	for <ipcdn@ietf.org>; Tue, 6 May 2003 14:22:40 -0500
Received: by ma07exm01.dma.isg.mot.com with Internet Mail Service (5.5.2656.59)
	id <HNFXDS6Z>; Tue, 6 May 2003 15:22:39 -0400
Message-ID: <19CD0E423FC1D611893500508B6F0B9CF39679@ma07exm01.dma.isg.mot.com>
From: Murwin William-LWM008 <W.Murwin@motorola.com>
To: "'Minnie Lu'" <milu@cisco.com>, Richard_Woundy@cable.comcast.com,
        docsis-oss@cablelabs.com, "IPCDN (E-mail) (E-mail)" <ipcdn@ietf.org>
Cc: "Michael W. Patrick (E-mail)" <mpatrick@dma.isg.mot.com>,
        "David Raftus (E-mail)" <david.raftus@imedia.com>
Date: Tue, 6 May 2003 15:22:34 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: [ipcdn] RE: sid counter inconsistent between draft-ietf-ipcdn-qos-mib-08.
 txt and DOCS-IF-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>

Minnie,

	After much consideration, DOCSIS QOS MIB version 9 will remove the text from section Section 2.2.2.1 Interoperation with DOCSIS 1.0:

5.  At the CMTS, the Docsis 1.0 MIB objects
    docsIfCmtsServiceInPackets and docsIfCmtsServiceInOctets for a
    SID assigned to a Docsis 1.1 or Docsis 2.0 modem count only the
    pre-registration packets/bytes of those modems."

This is not an issue for the QOS MIB. 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.

Sincerely,
Will Murwin

-----Original Message-----
From: Minnie Lu [mailto:milu@cisco.com]
Sent: Thursday, March 20, 2003 4:16 PM
To: Richard_Woundy@cable.comcast.com; docsis-oss@cablelabs.com
Cc: milu@cisco.com
Subject: sid counter inconsistent between
draft-ietf-ipcdn-qos-mib-08.txt and DOCS-IF-MIB ?


Hi,

   Since I have not yet got any reason for the sid counter 
inconsistence,  I would like to raise this issue again and hope this time, 
people will reconsider it.

In draft-ietf-ipcdn-qos-mib-08.txt,

1. Section 2.2.2.1 Interoperation with DOCSIS 1.0
        "5.  At the CMTS, the Docsis 1.0 MIB objects
          docsIfCmtsServiceInPackets and docsIfCmtsServiceInOctets for a
          SID assigned to a Docsis 1.1 or Docsis 2.0 modem count only the
          pre-registration packets/bytes of those modems."

          Maybe I miss some discussion before.  If there was some 
discussion before, please excuse me to bring this up again because I really 
don't understand why this is necessary to enforce this rule. SID concept is 
still applicable to DOCSIS1.1 or 2.0.  The MIB objects 
docsIfCmtsServiceInPackets and docsIfCmtsServiceInOctets definitions look 
good to me even for DOCSIS1.1 or 2.0.

    docsIfCmtsServiceInOctets OBJECT-TYPE
             "The cumulative number of Packet Data octets received
              on this Service ID. The count does not include the
              size of the Cable MAC header"

    docsIfCmtsServiceInPackets OBJECT-TYPE
             "The cumulative number of Packet Data packets received
              on this Service ID."

    From the description, it seems to me that they will count all the 
traffic including pre-registration and post-registration received on this 
Service ID no matter that this Service ID associates with DOCSIS1.0 or 
DOCSIS1.1 or DOCSIS2.0 CMs.  So they are consistent for various version of 
CMs mode.

    Also, in the same section, item 3 .
         "The docsIfCmServiceTable row for the DOCSIS 1.1 or DOCSIS 2.0 modem
          continues to exist, and the various statistic objects in that
          row are incremented."

    It sounds to me the item 4 is inconsistent with item 3 above.  For the 
same MIB object, it counts differently in CM and CMTS for the SIDs 
associated with DOCSIS1.1 CMs.   I think it is good to keep CM and CMTS the 
same as described in item 3.

    Also when customer queries the docsIfCmtsServiceTable, the customer 
might wonder why some entries have low count and not aware of they are for 
the SID belongs to CM in DOCSIS1.1 mode.

I noticed this is not in version 4.  From v5, it starts having such statements.

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



From mailnull@www1.ietf.org  Tue May  6 16:51: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 QAA08463
	for <ipcdn-archive@odin.ietf.org>; Tue, 6 May 2003 16:51:50 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h46L0Se28293
	for ipcdn-archive@odin.ietf.org; Tue, 6 May 2003 17:00:28 -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 h46L0C828244;
	Tue, 6 May 2003 17:00:12 -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 h46Kng827260
	for <ipcdn@optimus.ietf.org>; Tue, 6 May 2003 16:49: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 QAA07786
	for <ipcdn@ietf.org>; Tue, 6 May 2003 16:40:34 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19D9Gp-0002Ad-00
	for ipcdn@ietf.org; Tue, 06 May 2003 16:42:39 -0400
Received: from sj-core-1.cisco.com ([171.71.177.237])
	by ietf-mx with esmtp (Exim 4.12)
	id 19D9Go-0002AL-00
	for ipcdn@ietf.org; Tue, 06 May 2003 16:42:38 -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.6/8.12.6) with ESMTP id h46KgjXp007790;
	Tue, 6 May 2003 13:42:47 -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 AGW85919;
	Tue, 6 May 2003 13:42:44 -0700 (PDT)
Message-Id: <4.3.2.7.2.20030506134012.054097b0@mira-sjc5-1.cisco.com>
X-Sender: milu@mira-sjc5-1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 06 May 2003 13:42:43 -0700
To: Murwin William-LWM008 <W.Murwin@motorola.com>
From: Minnie Lu <milu@cisco.com>
Cc: "'Minnie Lu'" <milu@cisco.com>, Richard_Woundy@cable.comcast.com,
        docsis-oss@cablelabs.com, "IPCDN (E-mail) (E-mail)" <ipcdn@ietf.org>,
        "Michael W. Patrick (E-mail)" <mpatrick@dma.isg.mot.com>,
        "David Raftus (E-mail)" <david.raftus@imedia.com>
In-Reply-To: <19CD0E423FC1D611893500508B6F0B9CF39679@ma07exm01.dma.isg.m
 ot.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [ipcdn] RE: sid counter inconsistent between
 draft-ietf-ipcdn-qos-mib-08. txt and DOCS-IF-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>

Hi, Will,

   Thanks a lot ! I also hope that "the issue could be re-discussed and 
whatever conclusion is reached, can be document in the description of those 
objects."

    Appreciate your help !
    Thanks !
    Minnie


At 03:22 PM 5/6/2003 -0400, Murwin William-LWM008 wrote:
>Minnie,
>
>         After much consideration, DOCSIS QOS MIB version 9 will remove 
> the text from section Section 2.2.2.1 Interoperation with DOCSIS 1.0:
>
>5.  At the CMTS, the Docsis 1.0 MIB objects
>     docsIfCmtsServiceInPackets and docsIfCmtsServiceInOctets for a
>     SID assigned to a Docsis 1.1 or Docsis 2.0 modem count only the
>     pre-registration packets/bytes of those modems."
>
>This is not an issue for the QOS MIB. 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.
>
>Sincerely,
>Will Murwin
>
>-----Original Message-----
>From: Minnie Lu [mailto:milu@cisco.com]
>Sent: Thursday, March 20, 2003 4:16 PM
>To: Richard_Woundy@cable.comcast.com; docsis-oss@cablelabs.com
>Cc: milu@cisco.com
>Subject: sid counter inconsistent between
>draft-ietf-ipcdn-qos-mib-08.txt and DOCS-IF-MIB ?
>
>
>Hi,
>
>    Since I have not yet got any reason for the sid counter
>inconsistence,  I would like to raise this issue again and hope this time,
>people will reconsider it.
>
>In draft-ietf-ipcdn-qos-mib-08.txt,
>
>1. Section 2.2.2.1 Interoperation with DOCSIS 1.0
>         "5.  At the CMTS, the Docsis 1.0 MIB objects
>           docsIfCmtsServiceInPackets and docsIfCmtsServiceInOctets for a
>           SID assigned to a Docsis 1.1 or Docsis 2.0 modem count only the
>           pre-registration packets/bytes of those modems."
>
>           Maybe I miss some discussion before.  If there was some
>discussion before, please excuse me to bring this up again because I really
>don't understand why this is necessary to enforce this rule. SID concept is
>still applicable to DOCSIS1.1 or 2.0.  The MIB objects
>docsIfCmtsServiceInPackets and docsIfCmtsServiceInOctets definitions look
>good to me even for DOCSIS1.1 or 2.0.
>
>     docsIfCmtsServiceInOctets OBJECT-TYPE
>              "The cumulative number of Packet Data octets received
>               on this Service ID. The count does not include the
>               size of the Cable MAC header"
>
>     docsIfCmtsServiceInPackets OBJECT-TYPE
>              "The cumulative number of Packet Data packets received
>               on this Service ID."
>
>     From the description, it seems to me that they will count all the
>traffic including pre-registration and post-registration received on this
>Service ID no matter that this Service ID associates with DOCSIS1.0 or
>DOCSIS1.1 or DOCSIS2.0 CMs.  So they are consistent for various version of
>CMs mode.
>
>     Also, in the same section, item 3 .
>          "The docsIfCmServiceTable row for the DOCSIS 1.1 or DOCSIS 2.0 modem
>           continues to exist, and the various statistic objects in that
>           row are incremented."
>
>     It sounds to me the item 4 is inconsistent with item 3 above.  For the
>same MIB object, it counts differently in CM and CMTS for the SIDs
>associated with DOCSIS1.1 CMs.   I think it is good to keep CM and CMTS the
>same as described in item 3.
>
>     Also when customer queries the docsIfCmtsServiceTable, the customer
>might wonder why some entries have low count and not aware of they are for
>the SID belongs to CM in DOCSIS1.1 mode.
>
>I noticed this is not in version 4.  From v5, it starts having such 
>statements.
>
>Thanks !
>Minnie

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



From mailnull@www1.ietf.org  Thu May  8 15:34: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 PAA06069
	for <ipcdn-archive@odin.ietf.org>; Thu, 8 May 2003 15:34:47 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h48JiNW11611
	for ipcdn-archive@odin.ietf.org; Thu, 8 May 2003 15:44: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 h48JiK811603;
	Thu, 8 May 2003 15:44: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 h48Jhw811550
	for <ipcdn@optimus.ietf.org>; Thu, 8 May 2003 15:43:58 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05919;
	Thu, 8 May 2003 15:33:51 -0400 (EDT)
Message-Id: <200305081933.PAA05919@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: Thu, 08 May 2003 15:33:51 -0400
Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-pktc-signaling-01.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		: Network Control Signaling (NCS) Signaling MIB for PacketCable/IPCablecom MTAs
	Author(s)	: G. Beacham, S. Kumar, S. Channabasappa
	Filename	: draft-ietf-ipcdn-pktc-signaling-01.txt
	Pages		: 56
	Date		: 2003-5-8
	
This memo defines the Signaling Management Information Base (MIB)  
for use with network management protocols in the Internet community. 
In particular, it provides a common data and format representation  
for PacketCable/IPCablecom compliant Multimedia Terminal Adapter  
devices.  
This memo specifies a MIB module in a manner that is compliant to  
the SNMP SMIv2 [5][6][7].  The set of objects are 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-pktc-signaling-01.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-pktc-signaling-01.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-pktc-signaling-01.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-5-8105227.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipcdn-pktc-signaling-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ipcdn-pktc-signaling-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--


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



From mailnull@www1.ietf.org  Fri May  9 17:45:38 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 RAA03607
	for <ipcdn-archive@odin.ietf.org>; Fri, 9 May 2003 17:45:38 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h49Ltk217934
	for ipcdn-archive@odin.ietf.org; Fri, 9 May 2003 17:55:46 -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 h49Lte817900;
	Fri, 9 May 2003 17:55:40 -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 h49Lof817556
	for <ipcdn@optimus.ietf.org>; Fri, 9 May 2003 17:50:41 -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 RAA03417
	for <ipcdn@ietf.org>; Fri, 9 May 2003 17:40:03 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19EFcz-0007mb-00
	for ipcdn@ietf.org; Fri, 09 May 2003 17:42:05 -0400
Received: from coral.tci.com ([198.178.8.81] helo=snowmass.tci.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19EFcy-0007mL-00
	for ipcdn@ietf.org; Fri, 09 May 2003 17:42:04 -0400
Received: from mms01-relaya.tci.com (mms01-relaya.broadband.att.com [147.191.90.228])
	by snowmass.tci.com (8.12.9/8.12.9) with ESMTP id h49LgU95003682
	for <ipcdn@ietf.org>; Fri, 9 May 2003 15:42:30 -0600 (MDT)
Received: from 147.191.90.11 by mms01-relaya.tci.com with ESMTP (
 Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Fri, 09 May 2003 15:42:18
 -0600
Received: by entexchimc04.broadband.att.com with Internet Mail Service (
 5.5.2653.19) id <J5CG498M>; Fri, 9 May 2003 15:41:28 -0600
Message-ID: <6732623D2548D61193C90002A5C88DCC05663A69@entmaexch02.broadband.att.com>
From: "Woundy, Richard" <Richard_Woundy@cable.comcast.com>
To: "IPCDN WG (E-mail)" <ipcdn@ietf.org>
Date: Fri, 9 May 2003 15:42:00 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-WSS-ID: 12A2FF304667779-01-01
Content-Type: text/plain;
 charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [ipcdn] Recent updates to the IPCDN website (May 9)
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

Folks,

I made the following updates to the IPCDN website, www.ipcdn.org.

First, I updated the list of internet-drafts, due to the new drafts
submitted for PacketCable/IPCablecom: <http://www.ipcdn.org/ipcdn-ids.html>
<ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-mtamib-01.txt>
<ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-01.txt>
<http://www.ipcdn.org/drafts/draft-ietf-ipcdn-pktc-eventmess-02.txt> (will
be posted on IETF soon)

Second, I updated the IPCDN Hints page to point to the MIB Security
Considerations URL:
<http://www.ipcdn.org/ipcdn-id-hints.html>

Third, I updated the list of meetings to point to San Francisco meeting
material on the IETF website:
<http://www.ipcdn.org/meetings.html>

Fourth, I added CableHome 1.1 information, including the CableHome QoS MIB,
to the charter revision:
<http://www.ipcdn.org/charter-update.html>

-- Richard Woundy, IPCDN Co-Chair

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



From mailnull@www1.ietf.org  Sun May 11 18:50:18 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 SAA15065
	for <ipcdn-archive@odin.ietf.org>; Sun, 11 May 2003 18:50:17 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4BMFXa22727
	for ipcdn-archive@odin.ietf.org; Sun, 11 May 2003 18:15:33 -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 h4BMFLB22715;
	Sun, 11 May 2003 18:15:21 -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 h4BME3B22672
	for <ipcdn@optimus.ietf.org>; Sun, 11 May 2003 18:14:03 -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 SAA15040
	for <ipcdn@ietf.org>; Sun, 11 May 2003 18:48:18 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Eze5-0003LS-00
	for ipcdn@ietf.org; Sun, 11 May 2003 18:50:17 -0400
Received: from ftpbox.mot.com ([129.188.136.101])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Eze3-0003LP-00
	for ipcdn@ietf.org; Sun, 11 May 2003 18:50:15 -0400
Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234])
	by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h4BMpGsb007948
	for <ipcdn@ietf.org>; Sun, 11 May 2003 15:51:17 -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 h4BMpE5i027290
	for <ipcdn@ietf.org>; Sun, 11 May 2003 17:51:15 -0500
Received: by ma07exm01.dma.isg.mot.com with Internet Mail Service (5.5.2656.59)
	id <HNFXD664>; Sun, 11 May 2003 18:51:14 -0400
Message-ID: <19CD0E423FC1D611893500508B6F0B9CAB7263@ma07exm01.dma.isg.mot.com>
From: Patrick Michael-LZZ007 <Michael.Patrick@motorola.com>
To: "'ipcdn@ietf.org'" <ipcdn@ietf.org>
Date: Sun, 11 May 2003 18:51:13 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [ipcdn] FW: DisplayString or SnmpAdminString for an ASCII-only object?
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 group:

Any opinions on whether we should keep the docsQosParamSetServiceClassName object as a 
DisplayString or change it to an SnmpAdminString in order to match the modern conventions for human-readable strings?  

-mike



-----Original Message-----
From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com]
Sent: Thursday, May 08, 2003 6:00 PM
To: Patrick Michael-LZZ007
Cc: Murwin William-LWM008; Woundy, Richard
Subject: RE: DisplayString or SnmpAdminString for an ASCII-only object?


I think we should take this one to the mailing list, with Bert's comments
and your suggestion.

Note that they are using SnmpAdminString for service class names (e.g.
pktcSigServiceClassNameUS) in
<http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-01.txt>
.

-- Rich

-----Original Message-----
From: Patrick Michael-LZZ007 [mailto:Michael.Patrick@motorola.com]
Sent: Thursday, May 08, 2003 10:05 AM
To: Woundy, Richard
Cc: Murwin William-LWM008
Subject: RE: DisplayString or SnmpAdminString for an ASCII-only object?


Let's keep DisplayString, with the references as recommended as Bert.
This object represents an on-the-wire field required by spec to be printable
ascii, and is more than just text for human convenience. 

-mike


-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] 
Sent: Tuesday, May 06, 2003 7:29 PM
To: Woundy, Richard; 'Wijnen, Bert (Bert)'
Cc: Patrick Michael-LZZ007; Murwin William-LWM008
Subject: RE: DisplayString or SnmpAdminString for an ASCII-only object?


Inline

But first... would it not be better to post all this communication/email to
the IPCDN WG list?

> -----Original Message-----
> From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com]
> Sent: woensdag 7 mei 2003 0:00
> To: 'Wijnen, Bert (Bert)'
> Cc: 'Michael Patrick (E-mail)'; 'William Murwin (E-mail)'; 
> Woundy,Richard
> Subject: DisplayString or SnmpAdminString for an ASCII-only object?
> 
> Bert,
> 
> What is the preferred definition for a MIB object that represents a 
> DOCSIS parameter that is limited to the ASCII character set in the 
> DOCSIS specification?
> (a) SYNTAX DisplayString

You realize they are printibale ASCII only, right? It is not just ASCII.
Also, the max size if (0..255).

If the object is indeed limited to that character set in the DOCSIS spec,
then it seems to make sense to use that TC. I would then make a specific
note in the DESCRIPTION clause about such limitation in the DOCSIS spec,
with maybe a REFERENCE clause to the specific documentation.

Now is this object meant for Human consumption?
Is a Human ever expected to change it?
Cause in that case, they may not be happy with the limited character set.

> (b) SYNTAX SnmpAdminString, and object DESCRIPTION text that limits 
> the agent to the ASCII character set
> (c) SYNTAX SnmpAdminstring, and compliance DESCRIPTION text
> that limits the agent to the ASCII character set
> 
If you do one of those latter two, then option C (in my view) might be best.
It allows to extend in the future by creating just a new compliance
statement.

Hope this helps.
Bert
> -- Rich
> 
> P.S. Thanks for checking on the VLAN ID question.
> 
_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn



From mailnull@www1.ietf.org  Mon May 12 07:24:55 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 HAA08609
	for <ipcdn-archive@odin.ietf.org>; Mon, 12 May 2003 07:24:55 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4CAoQ017297
	for ipcdn-archive@odin.ietf.org; Mon, 12 May 2003 06:50: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 h4CAo9B17251;
	Mon, 12 May 2003 06:50: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 h4CAnNB17210
	for <ipcdn@optimus.ietf.org>; Mon, 12 May 2003 06:49:23 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08453;
	Mon, 12 May 2003 07:23:22 -0400 (EDT)
Message-Id: <200305121123.HAA08453@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: Mon, 12 May 2003 07:23:22 -0400
Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-pktc-mtamib-01.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		: Multimedia Terminal Adapter (MTA) Management 
                          Information Base for PacketCable 1.0 compliant devices
	Author(s)	: E. Nechamkin, J. Mule
	Filename	: draft-ietf-ipcdn-pktc-mtamib-01.txt
	Pages		: 41
	Date		: 2003-5-9
	
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 PacketCable/IPCablecom compliant Multimedia 
Terminal Adapter devices.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-mtamib-01.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-pktc-mtamib-01.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-pktc-mtamib-01.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-5-9123920.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipcdn-pktc-mtamib-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ipcdn-pktc-mtamib-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--


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



From mailnull@www1.ietf.org  Mon May 12 10:48:54 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 KAA17275
	for <ipcdn-archive@odin.ietf.org>; Mon, 12 May 2003 10:48:54 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4CEESW01709
	for ipcdn-archive@odin.ietf.org; Mon, 12 May 2003 10:14:28 -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 h4CEEFB01686;
	Mon, 12 May 2003 10:14: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 h4CEDhB01612
	for <ipcdn@optimus.ietf.org>; Mon, 12 May 2003 10:13:43 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17114;
	Mon, 12 May 2003 10:47:39 -0400 (EDT)
Message-Id: <200305121447.KAA17114@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: Mon, 12 May 2003 10:47:38 -0400
Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-pktc-mtamib-01.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		: Multimedia Terminal Adapter (MTA) Management 
                          Information Base for PacketCable 1.0 compliant devices
	Author(s)	: E. Nechamkin, J. Mule
	Filename	: draft-ietf-ipcdn-pktc-mtamib-01.txt
	Pages		: 41
	Date		: 2003-5-9
	
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 PacketCable/IPCablecom compliant Multimedia 
Terminal Adapter devices.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-mtamib-01.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-pktc-mtamib-01.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-pktc-mtamib-01.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-5-9123920.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipcdn-pktc-mtamib-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ipcdn-pktc-mtamib-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--


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



From mailnull@www1.ietf.org  Fri May 23 17:17: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 RAA26471
	for <ipcdn-archive@odin.ietf.org>; Fri, 23 May 2003 17:17:06 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4NLGcQ00942
	for ipcdn-archive@odin.ietf.org; Fri, 23 May 2003 17:16:38 -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 h4NLGYB00935;
	Fri, 23 May 2003 17:16:34 -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 h4NLFUB00887
	for <ipcdn@optimus.ietf.org>; Fri, 23 May 2003 17:15:30 -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 RAA26430
	for <ipcdn@ietf.org>; Fri, 23 May 2003 17:15:28 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19JJrX-0002kK-00
	for ipcdn@ietf.org; Fri, 23 May 2003 17:14:03 -0400
Received: from motgate.mot.com ([129.188.136.100])
	by ietf-mx with esmtp (Exim 4.12)
	id 19JJrW-0002kH-00
	for ipcdn@ietf.org; Fri, 23 May 2003 17:14:03 -0400
Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136])
	by motgate.mot.com (Motorola/Motgate) with ESMTP id h4NLFS32017306
	for <ipcdn@ietf.org>; Fri, 23 May 2003 14:15:28 -0700 (MST)
Received: from ma07exm01.dma.isg.mot.com (ma07exm01.dma.isg.mot.com [150.21.2.102])
	by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id h4NLFQnb013079
	for <ipcdn@ietf.org>; Fri, 23 May 2003 16:15:26 -0500
Received: by ma07exm01.dma.isg.mot.com with Internet Mail Service (5.5.2656.59)
	id <HNFX1VAN>; Fri, 23 May 2003 17:15:25 -0400
Message-ID: <19CD0E423FC1D611893500508B6F0B9CF396B4@ma07exm01.dma.isg.mot.com>
From: Murwin William-LWM008 <W.Murwin@motorola.com>
To: "'Minnie Lu'" <milu@cisco.com>, docsis-oss@cablelabs.com,
        "IPCDN (E-mail) (E-mail)" <ipcdn@ietf.org>
Cc: Richard_Woundy@cable.comcast.com,
        "Michael W. Patrick (E-mail)"
	 <mpatrick@dma.isg.mot.com>,
        "David Raftus (E-mail)"
	 <david.raftus@imedia.com>
Date: Fri, 23 May 2003 17:15:25 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: [ipcdn] CM pkts counts on the CMTS
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>

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. 	 
		  	   


-----Original Message-----
From: Minnie Lu [mailto:milu@cisco.com]
Sent: Tuesday, May 06, 2003 4:43 PM
To: Murwin William-LWM008
Cc: 'Minnie Lu'; Richard_Woundy@cable.comcast.com;
docsis-oss@cablelabs.com; IPCDN (E-mail) (E-mail); Michael W. Patrick
(E-mail); David Raftus (E-mail)
Subject: RE: sid counter inconsistent between
draft-ietf-ipcdn-qos-mib-08. txt and DOCS-IF-MIB ?


Hi, Will,

   Thanks a lot ! I also hope that "the issue could be re-discussed and 
whatever conclusion is reached, can be document in the description of those 
objects."

    Appreciate your help !
    Thanks !
    Minnie


At 03:22 PM 5/6/2003 -0400, Murwin William-LWM008 wrote:
>Minnie,
>
>         After much consideration, DOCSIS QOS MIB version 9 will remove 
> the text from section Section 2.2.2.1 Interoperation with DOCSIS 1.0:
>
>5.  At the CMTS, the Docsis 1.0 MIB objects
>     docsIfCmtsServiceInPackets and docsIfCmtsServiceInOctets for a
>     SID assigned to a Docsis 1.1 or Docsis 2.0 modem count only the
>     pre-registration packets/bytes of those modems."
>
>This is not an issue for the QOS MIB. 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.
>
>Sincerely,
>Will Murwin
>
>-----Original Message-----
>From: Minnie Lu [mailto:milu@cisco.com]
>Sent: Thursday, March 20, 2003 4:16 PM
>To: Richard_Woundy@cable.comcast.com; docsis-oss@cablelabs.com
>Cc: milu@cisco.com
>Subject: sid counter inconsistent between
>draft-ietf-ipcdn-qos-mib-08.txt and DOCS-IF-MIB ?
>
>
>Hi,
>
>    Since I have not yet got any reason for the sid counter
>inconsistence,  I would like to raise this issue again and hope this time,
>people will reconsider it.
>
>In draft-ietf-ipcdn-qos-mib-08.txt,
>
>1. Section 2.2.2.1 Interoperation with DOCSIS 1.0
>         "5.  At the CMTS, the Docsis 1.0 MIB objects
>           docsIfCmtsServiceInPackets and docsIfCmtsServiceInOctets for a
>           SID assigned to a Docsis 1.1 or Docsis 2.0 modem count only the
>           pre-registration packets/bytes of those modems."
>
>           Maybe I miss some discussion before.  If there was some
>discussion before, please excuse me to bring this up again because I really
>don't understand why this is necessary to enforce this rule. SID concept is
>still applicable to DOCSIS1.1 or 2.0.  The MIB objects
>docsIfCmtsServiceInPackets and docsIfCmtsServiceInOctets definitions look
>good to me even for DOCSIS1.1 or 2.0.
>
>     docsIfCmtsServiceInOctets OBJECT-TYPE
>              "The cumulative number of Packet Data octets received
>               on this Service ID. The count does not include the
>               size of the Cable MAC header"
>
>     docsIfCmtsServiceInPackets OBJECT-TYPE
>              "The cumulative number of Packet Data packets received
>               on this Service ID."
>
>     From the description, it seems to me that they will count all the
>traffic including pre-registration and post-registration received on this
>Service ID no matter that this Service ID associates with DOCSIS1.0 or
>DOCSIS1.1 or DOCSIS2.0 CMs.  So they are consistent for various version of
>CMs mode.
>
>     Also, in the same section, item 3 .
>          "The docsIfCmServiceTable row for the DOCSIS 1.1 or DOCSIS 2.0 modem
>           continues to exist, and the various statistic objects in that
>           row are incremented."
>
>     It sounds to me the item 4 is inconsistent with item 3 above.  For the
>same MIB object, it counts differently in CM and CMTS for the SIDs
>associated with DOCSIS1.1 CMs.   I think it is good to keep CM and CMTS the
>same as described in item 3.
>
>     Also when customer queries the docsIfCmtsServiceTable, the customer
>might wonder why some entries have low count and not aware of they are for
>the SID belongs to CM in DOCSIS1.1 mode.
>
>I noticed this is not in version 4.  From v5, it starts having such 
>statements.
>
>Thanks !
>Minnie
_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn



From mailnull@www1.ietf.org  Wed May 28 16:09:56 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 QAA21258
	for <ipcdn-archive@odin.ietf.org>; Wed, 28 May 2003 16:09:56 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4SK9SA06428
	for ipcdn-archive@odin.ietf.org; Wed, 28 May 2003 16:09:28 -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 h4SK9PB06419;
	Wed, 28 May 2003 16:09:25 -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 h4SK8QB06365
	for <ipcdn@optimus.ietf.org>; Wed, 28 May 2003 16:08: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 QAA21185
	for <ipcdn@ietf.org>; Wed, 28 May 2003 16:08:23 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19L7CB-0007AG-00
	for ipcdn@ietf.org; Wed, 28 May 2003 16:06:47 -0400
Received: from coral.tci.com ([198.178.8.81] helo=peacock.tci.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19L7CA-00079p-00
	for ipcdn@ietf.org; Wed, 28 May 2003 16:06:46 -0400
Received: from mms01-relaya.tci.com (mms01-relaya.broadband.att.com [147.191.90.228])
	by peacock.tci.com (8.12.9/8.12.9) with ESMTP id h4SK4Bu3004796;
	Wed, 28 May 2003 14:07:52 -0600 (MDT)
Received: from 147.191.89.201 by mms01-relayb.tci.com with ESMTP (
 Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Wed, 28 May 2003 14:07:44
 -0600
Received: by entexchimc02.broadband.att.com with Internet Mail Service (
 5.5.2653.19) id <J7925R0N>; Wed, 28 May 2003 14:07:45 -0600
Message-ID: <6732623D2548D61193C90002A5C88DCC05663AE4@entmaexch02.broadband.att.com>
From: "Woundy, Richard" <Richard_Woundy@cable.comcast.com>
To: "'Raftus, David'" <david.raftus@imedia.com>,
        "'Murwin William-LWM008'" <W.Murwin@motorola.com>
cc: "IPCDN (E-mail) (E-mail)" <ipcdn@ietf.org>
Subject: RE: [ipcdn] RE: "Optional" in the description of objects from
 the rfmibv2
Date: Wed, 28 May 2003 14:07:41 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-WSS-ID: 12CBC89A5296657-01-01
Content-Type: multipart/alternative;
 boundary="----_=_NextPart_001_01C32554.CB8CF8C0"
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_01C32554.CB8CF8C0
Content-Type: text/plain;
 charset=iso-8859-1
Content-Transfer-Encoding: 7bit

David and William,
 
I've been meaning to ask this for some time, but... what is the management
value of implementing objects if they don't report "valid" statistics?
Instead, why not make the objects completely optional for the CMTS (from a
specification point of view)?
 
If a management station receives a value of 0 for one of these objects as
specified now, it is not clear whether or not the CMTS is keeping track of
the actual value of the object.
 
If a management station receives a 'noSuchObject' indication, then it is
clear that the CMTS is not keeping track of the object's value. ;^)
 
-- Rich

-----Original Message-----
From: Raftus, David [mailto:david.raftus@imedia.com]
Sent: Monday, May 05, 2003 3:19 PM
To: 'Murwin William-LWM008'; Raftus, David
Cc: IPCDN (E-mail) (E-mail)
Subject: [ipcdn] RE: "Optional" in the description of objects from the
rfmibv2



Hi Will, 

Thanks for the note. It's always surprising to see how well intentioned
words can be seen in another light. As you state, the intent is mandatory
implementation of the objects, but optional counting of the statistics
represented by the objects. I will make your suggested changes in v7.

Thanks, 
Dave 

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

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


-----Original Message----- 
From: Murwin William-LWM008 [ mailto:W.Murwin@motorola.com
<mailto:W.Murwin@motorola.com> ] 
Sent: Monday, May 05, 2003 3:08 PM 
To: 'david.raftus@terayon.com' 
Cc: IPCDN (E-mail) (E-mail) 
Subject: "Optional" in the description of objects from the rfmibv2 

David, 

        I was reading the description for the following objects: 

docsIfCmtsUpChnlCtrCollCntnMslots             
docsIfCmtsUpChnlCtrTotalCntnReqMslots         
docsIfCmtsUpChnlCtrUsedCntnReqMslots          
docsIfCmtsUpChnlCtrCollCntnReqMslots          
docsIfCmtsUpChnlCtrTotalCntnReqDataMslots     
docsIfCmtsUpChnlCtrUsedCntnReqDataMslots      
docsIfCmtsUpChnlCtrCollCntnReqDataMslots      
docsIfCmtsUpChnlCtrTotalCntnInitMaintMslots   
docsIfCmtsUpChnlCtrUsedCntnInitMaintMslots    
docsIfCmtsUpChnlCtrCollCntnInitMaintMslots    
docsIfCmtsUpChnlCtrExtCollCntnMslots          
docsIfCmtsUpChnlCtrExtTotalCntnReqMslots      
docsIfCmtsUpChnlCtrExtUsedCntnReqMslots       
docsIfCmtsUpChnlCtrExtCollCntnReqMslots       
docsIfCmtsUpChnlCtrExtTotalCntnReqDataMslots  
docsIfCmtsUpChnlCtrExtUsedCntnReqDataMslots   
docsIfCmtsUpChnlCtrExtCollCntnReqDataMslots   
docsIfCmtsUpChnlCtrExtTotalCntnInitMaintMslots 
docsIfCmtsUpChnlCtrExtUsedCntnInitMaintMslots 
docsIfCmtsUpChnlCtrExtCollCntnInitMaintMslots 

All contain the following description: 

"...Support for this object is optional. If the object is not supported, a
value of zero is returned." 
Yet in the compliance statement these object belong to the docsIfCmtsGroupV2

Which is described as: 
-- conditionally mandatory group 
GROUP docsIfCmtsGroupV2 DESCRIPTION "This group is implemented only in Cable
Modem Termination Systems, not in Cable Modems."

This description with the key word "optional" is confusing! If these objects
are truly optional then they need not be implemented by the agent.

rfc2580: 
======================================================================= 
        3.  Mapping of the OBJECT-GROUP macro 

   For conformance purposes, it is useful to define a collection of 
   related managed objects.  The OBJECT-GROUP macro is used to define 
   each such collection of related objects.  It should be noted that the 
   expansion of the OBJECT-GROUP macro is something which conceptually 
   happens during implementation and not during run-time. 

   To "implement" an object, an agent must return a reasonably accurate 
   value for management protocol retrieval operations; similarly, if the 
   object is writable, then in response to a management protocol set 
   operation, an agent must accordingly be able to reasonably influence 
   the underlying managed entity.  If an agent can not implement an 
   object, the management protocol provides for it to return an 
   exception or error, e.g, noSuchObject [4].  Under no circumstances 
<----- NOTE 
   shall an agent return a value for objects which it does not implement 
<----- 
   -- it must always return the appropriate exception or error, as 
<------ 
   described in the protocol specification [4]. 
======================================================================== 

I believe your intent is for these objects to be implemented by a CMTS
agent, but not mandatory for the agent count these statistics.

I would remove the "optional" comment from the description of each of these
objects and change the text to read "If statistics are not maintained by the
agent, a value of zero is returned for this object."  or something to that
nature.

But what really is need is a change to the description for the
docsIfCmtsGroupV2, the comment above the group should be include in the
description. I would go as far as to say these objects are "mandatory" for a
CMTS agent, even though this is not a mandatory-group.

If I have mis-interrupted that these objects are not mandatory for the CMTS,
then a new optional group is needed for the CMTS, just for these objects.

>From the current descriptions, am just not sure which approach you where
trying to take. Any clarification is greatly appreciated.

Thanks, 
Will Murwin 



_____________________________ 
William Murwin 
Broadband Communications Sector 
Motorola Inc. 
Email: W.Murwin@motorola.com 
Tel: (508) 851-8385 


------_=_NextPart_001_01C32554.CB8CF8C0
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">
<TITLE>RE: "Optional" in the description of objects from the rfmibv2</TITLE>

<META content="MSHTML 6.00.2800.1170" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=681023617-28052003><FONT face=Arial color=#0000ff size=2>David 
and William,</FONT></SPAN></DIV>
<DIV><SPAN class=681023617-28052003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=681023617-28052003><FONT face=Arial color=#0000ff size=2>I've 
been meaning to ask this for some time, but... what is the management value of 
implementing objects if they don't report "valid" statistics? Instead, why not 
make the objects completely optional for the CMTS (from a specification point of 
view)?</FONT></SPAN></DIV>
<DIV><SPAN class=681023617-28052003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=681023617-28052003><FONT face=Arial color=#0000ff size=2>If a 
management station receives a value of 0 for one of these objects as specified 
now, it&nbsp;is not clear&nbsp;whether or not the CMTS is&nbsp;keeping 
track&nbsp;of&nbsp;the actual value of the object.</FONT></SPAN></DIV>
<DIV><SPAN class=681023617-28052003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=681023617-28052003><FONT face=Arial color=#0000ff size=2>If a 
management station receives a 'noSuchObject' indication, then it is clear that 
the CMTS is not keeping track of the object's value. ;^)</FONT></SPAN></DIV>
<DIV><SPAN class=681023617-28052003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=681023617-28052003><FONT face=Arial color=#0000ff size=2>-- 
Rich</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> Raftus, David 
  [mailto:david.raftus@imedia.com]<BR><B>Sent:</B> Monday, May 05, 2003 3:19 
  PM<BR><B>To:</B> 'Murwin William-LWM008'; Raftus, David<BR><B>Cc:</B> IPCDN 
  (E-mail) (E-mail)<BR><B>Subject:</B> [ipcdn] RE: "Optional" in the description 
  of objects from the rfmibv2<BR><BR></FONT></DIV>
  <P><FONT size=2>Hi Will,</FONT> </P>
  <P><FONT size=2>Thanks for the note. It's always surprising to see how well 
  intentioned words can be seen in another light. As you state, the intent is 
  mandatory implementation of the objects, but optional counting of the 
  statistics represented by the objects. I will make your suggested changes in 
  v7.</FONT></P>
  <P><FONT size=2>Thanks,</FONT> <BR><FONT size=2>Dave</FONT> </P>
  <P><FONT size=2>************************************</FONT> <BR><FONT 
  size=2>David Raftus</FONT> <BR><FONT size=2>Terayon Canada Ltd</FONT> 
  <BR><FONT size=2>340 Terry Fox Drive, Suite 202</FONT> <BR><FONT size=2>Ottawa 
  Canada&nbsp; K2K 3A2</FONT> </P>
  <P><FONT 
  size=2>david.raftus@terayon.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </FONT><BR><FONT size=2>613.592.1052&nbsp; ext 222</FONT> <BR><FONT 
  size=2>************************************&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </FONT></P><BR>
  <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: 
  Murwin William-LWM008 [<A 
  href="mailto:W.Murwin@motorola.com">mailto:W.Murwin@motorola.com</A>]</FONT> 
  <BR><FONT size=2>Sent: Monday, May 05, 2003 3:08 PM</FONT> <BR><FONT 
  size=2>To: 'david.raftus@terayon.com'</FONT> <BR><FONT size=2>Cc: IPCDN 
  (E-mail) (E-mail)</FONT> <BR><FONT size=2>Subject: "Optional" in the 
  description of objects from the rfmibv2</FONT> </P>
  <P><FONT size=2>David,</FONT> </P>
  <P><FONT size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I was reading the 
  description for the following objects:</FONT> </P>
  <P><FONT 
  size=2>docsIfCmtsUpChnlCtrCollCntnMslots&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </FONT><BR><FONT 
  size=2>docsIfCmtsUpChnlCtrTotalCntnReqMslots&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </FONT><BR><FONT 
  size=2>docsIfCmtsUpChnlCtrUsedCntnReqMslots&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </FONT><BR><FONT 
  size=2>docsIfCmtsUpChnlCtrCollCntnReqMslots&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </FONT><BR><FONT 
  size=2>docsIfCmtsUpChnlCtrTotalCntnReqDataMslots&nbsp;&nbsp;&nbsp;&nbsp; 
  </FONT><BR><FONT 
  size=2>docsIfCmtsUpChnlCtrUsedCntnReqDataMslots&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </FONT><BR><FONT 
  size=2>docsIfCmtsUpChnlCtrCollCntnReqDataMslots&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </FONT><BR><FONT 
  size=2>docsIfCmtsUpChnlCtrTotalCntnInitMaintMslots&nbsp;&nbsp; 
  </FONT><BR><FONT 
  size=2>docsIfCmtsUpChnlCtrUsedCntnInitMaintMslots&nbsp;&nbsp;&nbsp; 
  </FONT><BR><FONT 
  size=2>docsIfCmtsUpChnlCtrCollCntnInitMaintMslots&nbsp;&nbsp;&nbsp; 
  </FONT><BR><FONT 
  size=2>docsIfCmtsUpChnlCtrExtCollCntnMslots&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </FONT><BR><FONT 
  size=2>docsIfCmtsUpChnlCtrExtTotalCntnReqMslots&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </FONT><BR><FONT 
  size=2>docsIfCmtsUpChnlCtrExtUsedCntnReqMslots&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </FONT><BR><FONT 
  size=2>docsIfCmtsUpChnlCtrExtCollCntnReqMslots&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </FONT><BR><FONT size=2>docsIfCmtsUpChnlCtrExtTotalCntnReqDataMslots&nbsp; 
  </FONT><BR><FONT 
  size=2>docsIfCmtsUpChnlCtrExtUsedCntnReqDataMslots&nbsp;&nbsp; 
  </FONT><BR><FONT 
  size=2>docsIfCmtsUpChnlCtrExtCollCntnReqDataMslots&nbsp;&nbsp; 
  </FONT><BR><FONT size=2>docsIfCmtsUpChnlCtrExtTotalCntnInitMaintMslots</FONT> 
  <BR><FONT size=2>docsIfCmtsUpChnlCtrExtUsedCntnInitMaintMslots 
  </FONT><BR><FONT size=2>docsIfCmtsUpChnlCtrExtCollCntnInitMaintMslots</FONT> 
  </P>
  <P><FONT size=2>All contain the following description:</FONT> </P>
  <P><FONT size=2>"...Support for this object is optional. If the object is not 
  supported, a value of zero is returned."</FONT> <BR><FONT size=2>Yet in the 
  compliance statement these object belong to the docsIfCmtsGroupV2</FONT> 
  <BR><FONT size=2>Which is described as:</FONT> <BR><FONT size=2>-- 
  conditionally mandatory group</FONT> <BR><FONT size=2>GROUP docsIfCmtsGroupV2 
  DESCRIPTION "This group is implemented only in Cable Modem Termination 
  Systems, not in Cable Modems."</FONT></P>
  <P><FONT size=2>This description with the key word "optional" is confusing! If 
  these objects are truly optional then they need not be implemented by the 
  agent.</FONT></P>
  <P><FONT size=2>rfc2580:</FONT> <BR><FONT 
  size=2>=======================================================================</FONT> 
  <BR><FONT size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3.&nbsp; Mapping 
  of the OBJECT-GROUP macro</FONT> </P>
  <P><FONT size=2>&nbsp;&nbsp; For conformance purposes, it is useful to define 
  a collection of</FONT> <BR><FONT size=2>&nbsp;&nbsp; related managed 
  objects.&nbsp; The OBJECT-GROUP macro is used to define</FONT> <BR><FONT 
  size=2>&nbsp;&nbsp; each such collection of related objects.&nbsp; It should 
  be noted that the</FONT> <BR><FONT size=2>&nbsp;&nbsp; expansion of the 
  OBJECT-GROUP macro is something which conceptually</FONT> <BR><FONT 
  size=2>&nbsp;&nbsp; happens during implementation and not during 
  run-time.</FONT> </P>
  <P><FONT size=2>&nbsp;&nbsp; To "implement" an object, an agent must return a 
  reasonably accurate</FONT> <BR><FONT size=2>&nbsp;&nbsp; value for management 
  protocol retrieval operations; similarly, if the</FONT> <BR><FONT 
  size=2>&nbsp;&nbsp; object is writable, then in response to a management 
  protocol set</FONT> <BR><FONT size=2>&nbsp;&nbsp; operation, an agent must 
  accordingly be able to reasonably influence</FONT> <BR><FONT 
  size=2>&nbsp;&nbsp; the underlying managed entity.&nbsp; If an agent can not 
  implement an</FONT> <BR><FONT size=2>&nbsp;&nbsp; object, the management 
  protocol provides for it to return an</FONT> <BR><FONT size=2>&nbsp;&nbsp; 
  exception or error, e.g, noSuchObject [4].&nbsp; Under no circumstances</FONT> 
  <BR><FONT size=2>&lt;----- NOTE</FONT> <BR><FONT size=2>&nbsp;&nbsp; shall an 
  agent return a value for objects which it does not implement</FONT> <BR><FONT 
  size=2>&lt;-----</FONT> <BR><FONT size=2>&nbsp;&nbsp; -- it must always return 
  the appropriate exception or error, as</FONT> <BR><FONT 
  size=2>&lt;------</FONT> <BR><FONT size=2>&nbsp;&nbsp; described in the 
  protocol specification [4]. </FONT><BR><FONT 
  size=2>========================================================================</FONT> 
  </P>
  <P><FONT size=2>I believe your intent is for these objects to be implemented 
  by a CMTS agent, but not mandatory for the agent count these 
  statistics.</FONT></P>
  <P><FONT size=2>I would remove the "optional" comment from the description of 
  each of these objects and change the text to read "If statistics are not 
  maintained by the agent, a value of zero is returned for this object."&nbsp; 
  or something to that nature.</FONT></P>
  <P><FONT size=2>But what really is need is a change to the description for the 
  docsIfCmtsGroupV2, the comment above the group should be include in the 
  description. I would go as far as to say these objects are "mandatory" for a 
  CMTS agent, even though this is not a mandatory-group.</FONT></P>
  <P><FONT size=2>If I have mis-interrupted that these objects are not mandatory 
  for the CMTS, then a new optional group is needed for the CMTS, just for these 
  objects.</FONT></P>
  <P><FONT size=2>From the current descriptions, am just not sure which approach 
  you where trying to take. Any clarification is greatly appreciated.</FONT></P>
  <P><FONT size=2>Thanks,</FONT> <BR><FONT size=2>Will Murwin</FONT> 
</P><BR><BR>
  <P><FONT size=2>_____________________________</FONT> <BR><FONT size=2>William 
  Murwin</FONT> <BR><FONT size=2>Broadband Communications Sector</FONT> 
  <BR><FONT size=2>Motorola Inc.</FONT> <BR><FONT size=2>Email: 
  W.Murwin@motorola.com</FONT> <BR><FONT size=2>Tel: (508) 851-8385</FONT> 
</P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C32554.CB8CF8C0--

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



From mailnull@www1.ietf.org  Wed May 28 16:27: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 QAA22227
	for <ipcdn-archive@odin.ietf.org>; Wed, 28 May 2003 16:27:47 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4SKRKv08659
	for ipcdn-archive@odin.ietf.org; Wed, 28 May 2003 16:27: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 h4SKR4B08650;
	Wed, 28 May 2003 16:27:04 -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 h4SKQ8B08600
	for <ipcdn@optimus.ietf.org>; Wed, 28 May 2003 16:26:08 -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 QAA22157
	for <ipcdn@ietf.org>; Wed, 28 May 2003 16:26:05 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19L7TJ-0007S2-00
	for ipcdn@ietf.org; Wed, 28 May 2003 16:24:29 -0400
Received: from puffin.mail.pas.earthlink.net ([207.217.120.139])
	by ietf-mx with esmtp (Exim 4.12)
	id 19L7TI-0007Ry-00
	for ipcdn@ietf.org; Wed, 28 May 2003 16:24:28 -0400
Received: from pcp802197pcs.nrockv01.md.comcast.net ([68.48.86.43] helo=STJOHNS-LAPTOP2.mindspring.com)
	by puffin.mail.pas.earthlink.net with asmtp (TLSv1:RC4-SHA:128)
	(Exim 3.33 #1)
	id 19L7Uk-0006sA-00; Wed, 28 May 2003 13:25:58 -0700
Message-Id: <5.2.1.1.2.20030528162354.01ae0e58@pop.mindspring.com>
X-Sender: mstjohns@mindspring.com@pop.mindspring.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.1
Date: Wed, 28 May 2003 16:25:55 -0400
To: "Woundy, Richard" <Richard_Woundy@cable.comcast.com>,
        "'Raftus, David'" <david.raftus@imedia.com>,
        "'Murwin William-LWM008'" <W.Murwin@motorola.com>
From: Michael StJohns <mstjohns@mindspring.com>
Subject: RE: [ipcdn] RE: "Optional" in the description of objects from
  the rfmibv2
Cc: "IPCDN (E-mail) (E-mail)" <ipcdn@ietf.org>
In-Reply-To: <6732623D2548D61193C90002A5C88DCC05663AE4@entmaexch02.broad
 band.att.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_18277241==.ALT"
X-ELNK-Trace: 9f6ded143da542dc9c7f779228e2f6aeda0071232e20db4d54319abea2368c6080d02b0b13fb5af8350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
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>

--=====================_18277241==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Rich is exactly correct.  Remove the "...Support for this object is 
optional. If the object is not supported, a value of zero is returned." 
language everywhere it occurs - it won't make it past the mib 
doctors..  Place the objects in the appropriate conformance statement which 
indicates that its optional.  Return noSuchObject if the object isn't 
implemented.

Mike


At 16:07 5/28/2003, Woundy, Richard wrote:
>David and William,
>
>I've been meaning to ask this for some time, but... what is the management 
>value of implementing objects if they don't report "valid" statistics? 
>Instead, why not make the objects completely optional for the CMTS (from a 
>specification point of view)?
>
>If a management station receives a value of 0 for one of these objects as 
>specified now, it is not clear whether or not the CMTS is keeping track of 
>the actual value of the object.
>
>If a management station receives a 'noSuchObject' indication, then it is 
>clear that the CMTS is not keeping track of the object's value. ;^)
>
>-- Rich
>-----Original Message-----
>From: Raftus, David [mailto:david.raftus@imedia.com]
>Sent: Monday, May 05, 2003 3:19 PM
>To: 'Murwin William-LWM008'; Raftus, David
>Cc: IPCDN (E-mail) (E-mail)
>Subject: [ipcdn] RE: "Optional" in the description of objects from the rfmibv2
>
>Hi Will,
>
>Thanks for the note. It's always surprising to see how well intentioned 
>words can be seen in another light. As you state, the intent is mandatory 
>implementation of the objects, but optional counting of the statistics 
>represented by the objects. I will make your suggested changes in v7.
>
>Thanks,
>Dave
>
>************************************
>David Raftus
>Terayon Canada Ltd
>340 Terry Fox Drive, Suite 202
>Ottawa Canada  K2K 3A2
>
>david.raftus@terayon.com
>613.592.1052  ext 222
>************************************
>
>-----Original Message-----
>From: Murwin William-LWM008 
>[<mailto:W.Murwin@motorola.com>mailto:W.Murwin@motorola.com]
>Sent: Monday, May 05, 2003 3:08 PM
>To: 'david.raftus@terayon.com'
>Cc: IPCDN (E-mail) (E-mail)
>Subject: "Optional" in the description of objects from the rfmibv2
>
>David,
>
>         I was reading the description for the following objects:
>
>docsIfCmtsUpChnlCtrCollCntnMslots
>docsIfCmtsUpChnlCtrTotalCntnReqMslots
>docsIfCmtsUpChnlCtrUsedCntnReqMslots
>docsIfCmtsUpChnlCtrCollCntnReqMslots
>docsIfCmtsUpChnlCtrTotalCntnReqDataMslots
>docsIfCmtsUpChnlCtrUsedCntnReqDataMslots
>docsIfCmtsUpChnlCtrCollCntnReqDataMslots
>docsIfCmtsUpChnlCtrTotalCntnInitMaintMslots
>docsIfCmtsUpChnlCtrUsedCntnInitMaintMslots
>docsIfCmtsUpChnlCtrCollCntnInitMaintMslots
>docsIfCmtsUpChnlCtrExtCollCntnMslots
>docsIfCmtsUpChnlCtrExtTotalCntnReqMslots
>docsIfCmtsUpChnlCtrExtUsedCntnReqMslots
>docsIfCmtsUpChnlCtrExtCollCntnReqMslots
>docsIfCmtsUpChnlCtrExtTotalCntnReqDataMslots
>docsIfCmtsUpChnlCtrExtUsedCntnReqDataMslots
>docsIfCmtsUpChnlCtrExtCollCntnReqDataMslots
>docsIfCmtsUpChnlCtrExtTotalCntnInitMaintMslots
>docsIfCmtsUpChnlCtrExtUsedCntnInitMaintMslots
>docsIfCmtsUpChnlCtrExtCollCntnInitMaintMslots
>
>All contain the following description:
>
>"...Support for this object is optional. If the object is not supported, a 
>value of zero is returned."
>Yet in the compliance statement these object belong to the docsIfCmtsGroupV2
>Which is described as:
>-- conditionally mandatory group
>GROUP docsIfCmtsGroupV2 DESCRIPTION "This group is implemented only in 
>Cable Modem Termination Systems, not in Cable Modems."
>
>This description with the key word "optional" is confusing! If these 
>objects are truly optional then they need not be implemented by the agent.
>
>rfc2580:
>=======================================================================
>         3.  Mapping of the OBJECT-GROUP macro
>
>    For conformance purposes, it is useful to define a collection of
>    related managed objects.  The OBJECT-GROUP macro is used to define
>    each such collection of related objects.  It should be noted that the
>    expansion of the OBJECT-GROUP macro is something which conceptually
>    happens during implementation and not during run-time.
>
>    To "implement" an object, an agent must return a reasonably accurate
>    value for management protocol retrieval operations; similarly, if the
>    object is writable, then in response to a management protocol set
>    operation, an agent must accordingly be able to reasonably influence
>    the underlying managed entity.  If an agent can not implement an
>    object, the management protocol provides for it to return an
>    exception or error, e.g, noSuchObject [4].  Under no circumstances
><----- NOTE
>    shall an agent return a value for objects which it does not implement
><-----
>    -- it must always return the appropriate exception or error, as
><------
>    described in the protocol specification [4].
>========================================================================
>
>I believe your intent is for these objects to be implemented by a CMTS 
>agent, but not mandatory for the agent count these statistics.
>
>I would remove the "optional" comment from the description of each of 
>these objects and change the text to read "If statistics are not 
>maintained by the agent, a value of zero is returned for this object."  or 
>something to that nature.
>
>But what really is need is a change to the description for the 
>docsIfCmtsGroupV2, the comment above the group should be include in the 
>description. I would go as far as to say these objects are "mandatory" for 
>a CMTS agent, even though this is not a mandatory-group.
>
>If I have mis-interrupted that these objects are not mandatory for the 
>CMTS, then a new optional group is needed for the CMTS, just for these objects.
>
> From the current descriptions, am just not sure which approach you where 
> trying to take. Any clarification is greatly appreciated.
>
>Thanks,
>Will Murwin
>
>
>_____________________________
>William Murwin
>Broadband Communications Sector
>Motorola Inc.
>Email: W.Murwin@motorola.com
>Tel: (508) 851-8385


--=====================_18277241==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
Rich is exactly correct.&nbsp; Remove the <font size=2>&quot;...Support
for this object is optional. If the object is not supported, a value of
zero is returned.&quot;</font> language everywhere it occurs - it won't
make it past the mib doctors..&nbsp; Place the objects in the appropriate
conformance statement which indicates that its optional.&nbsp; Return
noSuchObject if the object isn't implemented.<br><br>
Mike<br><br>
<br>
At 16:07 5/28/2003, Woundy, Richard wrote:<br>
<blockquote type=cite class=cite cite><font face="arial" size=2 color="#0000FF">David
and William,</font><br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">I've been meaning to ask this
for some time, but... what is the management value of implementing
objects if they don't report &quot;valid&quot; statistics? Instead, why
not make the objects completely optional for the CMTS (from a
specification point of view)?</font><br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">If a management station
receives a value of 0 for one of these objects as specified now, it is
not clear whether or not the CMTS is keeping track of the actual value of
the object.</font><br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">If a management station
receives a 'noSuchObject' indication, then it is clear that the CMTS is
not keeping track of the object's value. ;^)</font><br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">-- Rich</font><br>

<dl>
<dd><font face="tahoma" size=2>-----Original Message-----<br>

<dd>From:</b> Raftus, David
[<a href="mailto:david.raftus@imedia.com" eudora="autourl">mailto:david.raftus@imedia.com</a>]<br>

<dd>Sent:</b> Monday, May 05, 2003 3:19 PM<br>

<dd>To:</b> 'Murwin William-LWM008'; Raftus, David<br>

<dd>Cc:</b> IPCDN (E-mail) (E-mail)<br>

<dd>Subject:</b> [ipcdn] RE: &quot;Optional&quot; in the description of
objects from the rfmibv2<br><br>
</font>
<dd>Hi Will, <br><br>

<dd><font size=2>Thanks for the note. It's always surprising to see how
well intentioned words can be seen in another light. As you state, the
intent is mandatory implementation of the objects, but optional counting
of the statistics represented by the objects. I will make your suggested
changes in v7.<br>
</font><br>

<dd><font size=2>Thanks,</font> <br>

<dd><font size=2>Dave</font> <br><br>

<dd><font size=2>************************************</font> <br>

<dd><font size=2>David Raftus</font> <br>

<dd><font size=2>Terayon Canada Ltd</font> <br>

<dd><font size=2>340 Terry Fox Drive, Suite 202</font> <br>

<dd><font size=2>Ottawa Canada&nbsp; K2K 3A2</font> <br><br>

<dd><font size=2>david.raftus@terayon.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</font><br>

<dd><font size=2>613.592.1052&nbsp; ext 222</font> <br>

<dd><font size=2>************************************&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
</font><br>

<dd><font size=2>-----Original Message-----</font> <br>

<dd><font size=2>From: Murwin William-LWM008
[<a href="mailto:W.Murwin@motorola.com">mailto:W.Murwin@motorola.com</a>]</font>
<br>

<dd><font size=2>Sent: Monday, May 05, 2003 3:08 PM</font> <br>

<dd><font size=2>To: 'david.raftus@terayon.com'</font> <br>

<dd><font size=2>Cc: IPCDN (E-mail) (E-mail)</font> <br>

<dd><font size=2>Subject: &quot;Optional&quot; in the description of
objects from the rfmibv2</font> <br><br>

<dd><font size=2>David,</font> <br><br>

<dd><font size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I was reading
the description for the following objects:</font> <br><br>

<dd><font size=2>docsIfCmtsUpChnlCtrCollCntnMslots&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</font><br>

<dd><font size=2>docsIfCmtsUpChnlCtrTotalCntnReqMslots&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</font><br>

<dd><font size=2>docsIfCmtsUpChnlCtrUsedCntnReqMslots&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</font><br>

<dd><font size=2>docsIfCmtsUpChnlCtrCollCntnReqMslots&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</font><br>

<dd><font size=2>docsIfCmtsUpChnlCtrTotalCntnReqDataMslots&nbsp;&nbsp;&nbsp;&nbsp;
</font><br>

<dd><font size=2>docsIfCmtsUpChnlCtrUsedCntnReqDataMslots&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</font><br>

<dd><font size=2>docsIfCmtsUpChnlCtrCollCntnReqDataMslots&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</font><br>

<dd><font size=2>docsIfCmtsUpChnlCtrTotalCntnInitMaintMslots&nbsp;&nbsp;
</font><br>

<dd><font size=2>docsIfCmtsUpChnlCtrUsedCntnInitMaintMslots&nbsp;&nbsp;&nbsp;
</font><br>

<dd><font size=2>docsIfCmtsUpChnlCtrCollCntnInitMaintMslots&nbsp;&nbsp;&nbsp;
</font><br>

<dd><font size=2>docsIfCmtsUpChnlCtrExtCollCntnMslots&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</font><br>

<dd><font size=2>docsIfCmtsUpChnlCtrExtTotalCntnReqMslots&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</font><br>

<dd><font size=2>docsIfCmtsUpChnlCtrExtUsedCntnReqMslots&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</font><br>

<dd><font size=2>docsIfCmtsUpChnlCtrExtCollCntnReqMslots&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</font><br>

<dd><font size=2>docsIfCmtsUpChnlCtrExtTotalCntnReqDataMslots&nbsp;
</font><br>

<dd><font size=2>docsIfCmtsUpChnlCtrExtUsedCntnReqDataMslots&nbsp;&nbsp;
</font><br>

<dd><font size=2>docsIfCmtsUpChnlCtrExtCollCntnReqDataMslots&nbsp;&nbsp;
</font><br>

<dd><font size=2>docsIfCmtsUpChnlCtrExtTotalCntnInitMaintMslots</font>
<br>

<dd><font size=2>docsIfCmtsUpChnlCtrExtUsedCntnInitMaintMslots </font><br>

<dd><font size=2>docsIfCmtsUpChnlCtrExtCollCntnInitMaintMslots</font> <br><br>

<dd><font size=2>All contain the following description:</font> <br><br>

<dd><font size=2>&quot;...Support for this object is optional. If the object is not supported, a value of zero is returned.&quot;</font> <br>

<dd><font size=2>Yet in the compliance statement these object belong to the docsIfCmtsGroupV2</font> <br>

<dd><font size=2>Which is described as:</font> <br>

<dd><font size=2>-- conditionally mandatory group</font> <br>

<dd><font size=2>GROUP docsIfCmtsGroupV2 DESCRIPTION &quot;This group is implemented only in Cable Modem Termination Systems, not in Cable Modems.&quot;<br>
</font><br>

<dd><font size=2>This description with the key word &quot;optional&quot; is confusing! If these objects are truly optional then they need not be implemented by the agent.<br>
</font><br>

<dd><font size=2>rfc2580:</font> <br>

<dd><font size=2>=======================================================================</font> <br>

<dd><font size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3.&nbsp; Mapping of the OBJECT-GROUP macro</font> <br><br>

<dd><font size=2>&nbsp;&nbsp; For conformance purposes, it is useful to define a collection of</font> <br>

<dd><font size=2>&nbsp;&nbsp; related managed objects.&nbsp; The OBJECT-GROUP macro is used to define</font> <br>

<dd><font size=2>&nbsp;&nbsp; each such collection of related objects.&nbsp; It should be noted that the</font> <br>

<dd><font size=2>&nbsp;&nbsp; expansion of the OBJECT-GROUP macro is something which conceptually</font> <br>

<dd><font size=2>&nbsp;&nbsp; happens during implementation and not during run-time.</font> <br><br>

<dd><font size=2>&nbsp;&nbsp; To &quot;implement&quot; an object, an agent must return a reasonably accurate</font> <br>

<dd><font size=2>&nbsp;&nbsp; value for management protocol retrieval operations; similarly, if the</font> <br>

<dd><font size=2>&nbsp;&nbsp; object is writable, then in response to a management protocol set</font> <br>

<dd><font size=2>&nbsp;&nbsp; operation, an agent must accordingly be able to reasonably influence</font> <br>

<dd><font size=2>&nbsp;&nbsp; the underlying managed entity.&nbsp; If an agent can not implement an</font> <br>

<dd><font size=2>&nbsp;&nbsp; object, the management protocol provides for it to return an</font> <br>

<dd><font size=2>&nbsp;&nbsp; exception or error, e.g, noSuchObject [4].&nbsp; Under no circumstances</font> <br>

<dd><font size=2>&lt;----- NOTE</font> <br>

<dd><font size=2>&nbsp;&nbsp; shall an agent return a value for objects which it does not implement</font> <br>

<dd><font size=2>&lt;-----</font> <br>

<dd><font size=2>&nbsp;&nbsp; -- it must always return the appropriate exception or error, as</font> <br>

<dd><font size=2>&lt;------</font> <br>

<dd><font size=2>&nbsp;&nbsp; described in the protocol specification [4]. </font><br>

<dd><font size=2>========================================================================</font> <br><br>

<dd><font size=2>I believe your intent is for these objects to be implemented by a CMTS agent, but not mandatory for the agent count these statistics.<br>
</font><br>

<dd><font size=2>I would remove the &quot;optional&quot; comment from the description of each of these objects and change the text to read &quot;If statistics are not maintained by the agent, a value of zero is returned for this object.&quot;&nbsp; or something to that nature.<br>
</font><br>

<dd><font size=2>But what really is need is a change to the description for the docsIfCmtsGroupV2, the comment above the group should be include in the description. I would go as far as to say these objects are &quot;mandatory&quot; for a CMTS agent, even though this is not a mandatory-group.<br>
</font><br>

<dd><font size=2>If I have mis-interrupted that these objects are not mandatory for the CMTS, then a new optional group is needed for the CMTS, just for these objects.<br>
</font><br>

<dd><font size=2>From the current descriptions, am just not sure which approach you where trying to take. Any clarification is greatly appreciated.<br>
</font><br>

<dd><font size=2>Thanks,</font> <br>

<dd><font size=2>Will Murwin</font> <br><br>
<br>

<dd><font size=2>_____________________________</font> <br>

<dd><font size=2>William Murwin</font> <br>

<dd><font size=2>Broadband Communications Sector</font> <br>

<dd><font size=2>Motorola Inc.</font> <br>

<dd><font size=2>Email: W.Murwin@motorola.com</font> <br>

<dd><font size=2>Tel: (508) 851-8385</font> <br>

</dl></blockquote></body>
<br>
</html>

--=====================_18277241==.ALT--

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



From mailnull@www1.ietf.org  Wed May 28 16:34:38 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 QAA22495
	for <ipcdn-archive@odin.ietf.org>; Wed, 28 May 2003 16:34:38 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4SKYA909100
	for ipcdn-archive@odin.ietf.org; Wed, 28 May 2003 16:34:10 -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 h4SKY5B09085;
	Wed, 28 May 2003 16:34:05 -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 h4SKXHB09032
	for <ipcdn@optimus.ietf.org>; Wed, 28 May 2003 16:33:17 -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 QAA22449
	for <ipcdn@ietf.org>; Wed, 28 May 2003 16:33:14 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19L7aE-0007VH-00
	for ipcdn@ietf.org; Wed, 28 May 2003 16:31:38 -0400
Received: from motgate.mot.com ([129.188.136.100])
	by ietf-mx with esmtp (Exim 4.12)
	id 19L7aD-0007VC-00
	for ipcdn@ietf.org; Wed, 28 May 2003 16:31:37 -0400
Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136])
	by motgate.mot.com (Motorola/Motgate) with ESMTP id h4SKXE32011282
	for <ipcdn@ietf.org>; Wed, 28 May 2003 13:33:14 -0700 (MST)
Received: from ma07exm01.dma.isg.mot.com (ma07exm01.dma.isg.mot.com [150.21.2.102])
	by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id h4SJX7Z3012628
	for <ipcdn@ietf.org>; Wed, 28 May 2003 14:33:07 -0500
Received: by ma07exm01.dma.isg.mot.com with Internet Mail Service (5.5.2656.59)
	id <HNFX17GY>; Wed, 28 May 2003 16:33:11 -0400
Message-ID: <19CD0E423FC1D611893500508B6F0B9CF396C7@ma07exm01.dma.isg.mot.com>
From: Murwin William-LWM008 <W.Murwin@motorola.com>
To: "'Woundy, Richard'" <Richard_Woundy@cable.comcast.com>,
        "'Raftus, David'" <david.raftus@imedia.com>
Cc: "IPCDN (E-mail) (E-mail)" <ipcdn@ietf.org>
Subject: RE: [ipcdn] RE: "Optional" in the description of objects from the
	 rfmibv2
Date: Wed, 28 May 2003 16:33:11 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C32558.5AFFD4F2"
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_01C32558.5AFFD4F2
Content-Type: text/plain;
	charset="iso-8859-1"

Rich,
 
        You make a great point. 
        
        I was looking at it from a implementer point of view and saw the manadtory group comment in the compliance statement. I.e. the reason for the email.
        But now that I see it from your point of view, I agree if these objects are truely "optional" then why must the agent support these objects. I hinted to that in the earlier email,
        I guess I didn't raise the question because because I truely didn't understand the context of "optional" in the description of these objects.
 
        Can I make a suggestion that a new table be created for the optional objects that aguments the table with the manadtory objects so that 
        as user using an SNMP Manager does not have figure out the hard way that some objects are "optional", if the CMTS does not support the optional objects.
        And in the compliance statement for the CMTS this is clearly explained.
 
Thanks,
Will Murwin
 
       

-----Original Message-----
From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com]
Sent: Wednesday, May 28, 2003 4:08 PM
To: 'Raftus, David'; Murwin William-LWM008
Cc: IPCDN (E-mail) (E-mail)
Subject: RE: [ipcdn] RE: "Optional" in the description of objects from the rfmibv2


David and William,
 
I've been meaning to ask this for some time, but... what is the management value of implementing objects if they don't report "valid" statistics? Instead, why not make the objects completely optional for the CMTS (from a specification point of view)?
 
If a management station receives a value of 0 for one of these objects as specified now, it is not clear whether or not the CMTS is keeping track of the actual value of the object.
 
If a management station receives a 'noSuchObject' indication, then it is clear that the CMTS is not keeping track of the object's value. ;^)
 
-- Rich

-----Original Message-----
From: Raftus, David [mailto:david.raftus@imedia.com]
Sent: Monday, May 05, 2003 3:19 PM
To: 'Murwin William-LWM008'; Raftus, David
Cc: IPCDN (E-mail) (E-mail)
Subject: [ipcdn] RE: "Optional" in the description of objects from the rfmibv2



Hi Will, 

Thanks for the note. It's always surprising to see how well intentioned words can be seen in another light. As you state, the intent is mandatory implementation of the objects, but optional counting of the statistics represented by the objects. I will make your suggested changes in v7.

Thanks, 
Dave 

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

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


-----Original Message----- 
From: Murwin William-LWM008 [ mailto:W.Murwin@motorola.com <mailto:W.Murwin@motorola.com> ] 
Sent: Monday, May 05, 2003 3:08 PM 
To: 'david.raftus@terayon.com' 
Cc: IPCDN (E-mail) (E-mail) 
Subject: "Optional" in the description of objects from the rfmibv2 

David, 

        I was reading the description for the following objects: 

docsIfCmtsUpChnlCtrCollCntnMslots             
docsIfCmtsUpChnlCtrTotalCntnReqMslots         
docsIfCmtsUpChnlCtrUsedCntnReqMslots          
docsIfCmtsUpChnlCtrCollCntnReqMslots          
docsIfCmtsUpChnlCtrTotalCntnReqDataMslots     
docsIfCmtsUpChnlCtrUsedCntnReqDataMslots      
docsIfCmtsUpChnlCtrCollCntnReqDataMslots      
docsIfCmtsUpChnlCtrTotalCntnInitMaintMslots   
docsIfCmtsUpChnlCtrUsedCntnInitMaintMslots    
docsIfCmtsUpChnlCtrCollCntnInitMaintMslots    
docsIfCmtsUpChnlCtrExtCollCntnMslots          
docsIfCmtsUpChnlCtrExtTotalCntnReqMslots      
docsIfCmtsUpChnlCtrExtUsedCntnReqMslots       
docsIfCmtsUpChnlCtrExtCollCntnReqMslots       
docsIfCmtsUpChnlCtrExtTotalCntnReqDataMslots  
docsIfCmtsUpChnlCtrExtUsedCntnReqDataMslots   
docsIfCmtsUpChnlCtrExtCollCntnReqDataMslots   
docsIfCmtsUpChnlCtrExtTotalCntnInitMaintMslots 
docsIfCmtsUpChnlCtrExtUsedCntnInitMaintMslots 
docsIfCmtsUpChnlCtrExtCollCntnInitMaintMslots 

All contain the following description: 

"...Support for this object is optional. If the object is not supported, a value of zero is returned." 
Yet in the compliance statement these object belong to the docsIfCmtsGroupV2 
Which is described as: 
-- conditionally mandatory group 
GROUP docsIfCmtsGroupV2 DESCRIPTION "This group is implemented only in Cable Modem Termination Systems, not in Cable Modems."

This description with the key word "optional" is confusing! If these objects are truly optional then they need not be implemented by the agent.

rfc2580: 
======================================================================= 
        3.  Mapping of the OBJECT-GROUP macro 

   For conformance purposes, it is useful to define a collection of 
   related managed objects.  The OBJECT-GROUP macro is used to define 
   each such collection of related objects.  It should be noted that the 
   expansion of the OBJECT-GROUP macro is something which conceptually 
   happens during implementation and not during run-time. 

   To "implement" an object, an agent must return a reasonably accurate 
   value for management protocol retrieval operations; similarly, if the 
   object is writable, then in response to a management protocol set 
   operation, an agent must accordingly be able to reasonably influence 
   the underlying managed entity.  If an agent can not implement an 
   object, the management protocol provides for it to return an 
   exception or error, e.g, noSuchObject [4].  Under no circumstances 
<----- NOTE 
   shall an agent return a value for objects which it does not implement 
<----- 
   -- it must always return the appropriate exception or error, as 
<------ 
   described in the protocol specification [4]. 
======================================================================== 

I believe your intent is for these objects to be implemented by a CMTS agent, but not mandatory for the agent count these statistics.

I would remove the "optional" comment from the description of each of these objects and change the text to read "If statistics are not maintained by the agent, a value of zero is returned for this object."  or something to that nature.

But what really is need is a change to the description for the docsIfCmtsGroupV2, the comment above the group should be include in the description. I would go as far as to say these objects are "mandatory" for a CMTS agent, even though this is not a mandatory-group.

If I have mis-interrupted that these objects are not mandatory for the CMTS, then a new optional group is needed for the CMTS, just for these objects.

>From the current descriptions, am just not sure which approach you where trying to take. Any clarification is greatly appreciated.

Thanks, 
Will Murwin 



_____________________________ 
William Murwin 
Broadband Communications Sector 
Motorola Inc. 
Email: W.Murwin@motorola.com 
Tel: (508) 851-8385 


------_=_NextPart_001_01C32558.5AFFD4F2
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">
<TITLE>RE: "Optional" in the description of objects from the rfmibv2</TITLE>

<META content="MSHTML 6.00.2800.1141" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=448371220-28052003><FONT face=Arial color=#0000ff 
size=2>Rich,</FONT></SPAN></DIV>
<DIV><SPAN class=448371220-28052003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=448371220-28052003>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
<FONT face=Arial color=#0000ff size=2>You make a great point. 
</FONT></SPAN></DIV>
<DIV><SPAN 
class=448371220-28052003>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<FONT 
face=Arial color=#0000ff size=2>&nbsp;</FONT></SPAN></DIV>
<DIV><SPAN class=448371220-28052003>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
<FONT face=Arial color=#0000ff size=2>I was looking at it from a implementer 
point of view and saw the manadtory group comment in the compliance statement. 
I.e. the reason for the email.</FONT></SPAN></DIV>
<DIV><SPAN 
class=448371220-28052003>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<FONT 
face=Arial color=#0000ff size=2>But now that I see it from your point of view, I 
agree if these objects are truely "optional" then why must the agent support 
these objects.</FONT>&nbsp;<FONT face=Arial color=#0000ff size=2>I hinted to 
that in the earlier email,</FONT></SPAN></DIV>
<DIV><SPAN class=448371220-28052003>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
<FONT face=Arial color=#0000ff size=2>I guess I didn't raise the question 
because because I truely didn't understand the context of "optional" in the 
description of these objects.</FONT></SPAN></DIV>
<DIV><SPAN class=448371220-28052003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=448371220-28052003>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
<FONT face=Arial color=#0000ff size=2>Can I make a suggestion that a new table 
be created for the optional objects that aguments the table with the manadtory 
objects so that </FONT></SPAN></DIV>
<DIV><SPAN class=448371220-28052003>&nbsp;&nbsp;&nbsp;<FONT face=Arial 
color=#0000ff size=2>&nbsp;&nbsp;&nbsp;&nbsp; as user using an SNMP Manager does 
not have figure out the hard way that some objects are "optional", if the CMTS 
does not support the optional objects.</FONT></SPAN></DIV>
<DIV><SPAN class=448371220-28052003><FONT face=Arial color=#0000ff 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; And in the compliance 
statement for the CMTS this is clearly explained.</FONT></SPAN></DIV>
<DIV><SPAN class=448371220-28052003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=448371220-28052003><FONT face=Arial color=#0000ff 
size=2>Thanks,</FONT></SPAN></DIV>
<DIV><SPAN class=448371220-28052003><FONT face=Arial color=#0000ff size=2>Will 
Murwin</FONT></SPAN></DIV>
<DIV><SPAN class=448371220-28052003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN 
class=448371220-28052003>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</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> Woundy, Richard 
  [mailto:Richard_Woundy@cable.comcast.com]<BR><B>Sent:</B> Wednesday, May 28, 
  2003 4:08 PM<BR><B>To:</B> 'Raftus, David'; Murwin 
  William-LWM008<BR><B>Cc:</B> IPCDN (E-mail) (E-mail)<BR><B>Subject:</B> RE: 
  [ipcdn] RE: "Optional" in the description of objects from the 
  rfmibv2<BR><BR></FONT></DIV>
  <DIV><SPAN class=681023617-28052003><FONT face=Arial color=#0000ff 
  size=2>David and William,</FONT></SPAN></DIV>
  <DIV><SPAN class=681023617-28052003><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=681023617-28052003><FONT face=Arial color=#0000ff size=2>I've 
  been meaning to ask this for some time, but... what is the management value of 
  implementing objects if they don't report "valid" statistics? Instead, why not 
  make the objects completely optional for the CMTS (from a specification point 
  of view)?</FONT></SPAN></DIV>
  <DIV><SPAN class=681023617-28052003><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=681023617-28052003><FONT face=Arial color=#0000ff size=2>If a 
  management station receives a value of 0 for one of these objects as specified 
  now, it&nbsp;is not clear&nbsp;whether or not the CMTS is&nbsp;keeping 
  track&nbsp;of&nbsp;the actual value of the object.</FONT></SPAN></DIV>
  <DIV><SPAN class=681023617-28052003><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=681023617-28052003><FONT face=Arial color=#0000ff size=2>If a 
  management station receives a 'noSuchObject' indication, then it is clear that 
  the CMTS is not keeping track of the object's value. ;^)</FONT></SPAN></DIV>
  <DIV><SPAN class=681023617-28052003><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=681023617-28052003><FONT face=Arial color=#0000ff size=2>-- 
  Rich</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> Raftus, David 
    [mailto:david.raftus@imedia.com]<BR><B>Sent:</B> Monday, May 05, 2003 3:19 
    PM<BR><B>To:</B> 'Murwin William-LWM008'; Raftus, David<BR><B>Cc:</B> IPCDN 
    (E-mail) (E-mail)<BR><B>Subject:</B> [ipcdn] RE: "Optional" in the 
    description of objects from the rfmibv2<BR><BR></FONT></DIV>
    <P><FONT size=2>Hi Will,</FONT> </P>
    <P><FONT size=2>Thanks for the note. It's always surprising to see how well 
    intentioned words can be seen in another light. As you state, the intent is 
    mandatory implementation of the objects, but optional counting of the 
    statistics represented by the objects. I will make your suggested changes in 
    v7.</FONT></P>
    <P><FONT size=2>Thanks,</FONT> <BR><FONT size=2>Dave</FONT> </P>
    <P><FONT size=2>************************************</FONT> <BR><FONT 
    size=2>David Raftus</FONT> <BR><FONT size=2>Terayon Canada Ltd</FONT> 
    <BR><FONT size=2>340 Terry Fox Drive, Suite 202</FONT> <BR><FONT 
    size=2>Ottawa Canada&nbsp; K2K 3A2</FONT> </P>
    <P><FONT 
    size=2>david.raftus@terayon.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    </FONT><BR><FONT size=2>613.592.1052&nbsp; ext 222</FONT> <BR><FONT 
    size=2>************************************&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    </FONT></P><BR>
    <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: 
    Murwin William-LWM008 [<A 
    href="mailto:W.Murwin@motorola.com">mailto:W.Murwin@motorola.com</A>]</FONT> 
    <BR><FONT size=2>Sent: Monday, May 05, 2003 3:08 PM</FONT> <BR><FONT 
    size=2>To: 'david.raftus@terayon.com'</FONT> <BR><FONT size=2>Cc: IPCDN 
    (E-mail) (E-mail)</FONT> <BR><FONT size=2>Subject: "Optional" in the 
    description of objects from the rfmibv2</FONT> </P>
    <P><FONT size=2>David,</FONT> </P>
    <P><FONT size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I was reading the 
    description for the following objects:</FONT> </P>
    <P><FONT 
    size=2>docsIfCmtsUpChnlCtrCollCntnMslots&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    </FONT><BR><FONT 
    size=2>docsIfCmtsUpChnlCtrTotalCntnReqMslots&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    </FONT><BR><FONT 
    size=2>docsIfCmtsUpChnlCtrUsedCntnReqMslots&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    </FONT><BR><FONT 
    size=2>docsIfCmtsUpChnlCtrCollCntnReqMslots&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    </FONT><BR><FONT 
    size=2>docsIfCmtsUpChnlCtrTotalCntnReqDataMslots&nbsp;&nbsp;&nbsp;&nbsp; 
    </FONT><BR><FONT 
    size=2>docsIfCmtsUpChnlCtrUsedCntnReqDataMslots&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    </FONT><BR><FONT 
    size=2>docsIfCmtsUpChnlCtrCollCntnReqDataMslots&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    </FONT><BR><FONT 
    size=2>docsIfCmtsUpChnlCtrTotalCntnInitMaintMslots&nbsp;&nbsp; 
    </FONT><BR><FONT 
    size=2>docsIfCmtsUpChnlCtrUsedCntnInitMaintMslots&nbsp;&nbsp;&nbsp; 
    </FONT><BR><FONT 
    size=2>docsIfCmtsUpChnlCtrCollCntnInitMaintMslots&nbsp;&nbsp;&nbsp; 
    </FONT><BR><FONT 
    size=2>docsIfCmtsUpChnlCtrExtCollCntnMslots&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    </FONT><BR><FONT 
    size=2>docsIfCmtsUpChnlCtrExtTotalCntnReqMslots&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    </FONT><BR><FONT 
    size=2>docsIfCmtsUpChnlCtrExtUsedCntnReqMslots&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    </FONT><BR><FONT 
    size=2>docsIfCmtsUpChnlCtrExtCollCntnReqMslots&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    </FONT><BR><FONT size=2>docsIfCmtsUpChnlCtrExtTotalCntnReqDataMslots&nbsp; 
    </FONT><BR><FONT 
    size=2>docsIfCmtsUpChnlCtrExtUsedCntnReqDataMslots&nbsp;&nbsp; 
    </FONT><BR><FONT 
    size=2>docsIfCmtsUpChnlCtrExtCollCntnReqDataMslots&nbsp;&nbsp; 
    </FONT><BR><FONT 
    size=2>docsIfCmtsUpChnlCtrExtTotalCntnInitMaintMslots</FONT> <BR><FONT 
    size=2>docsIfCmtsUpChnlCtrExtUsedCntnInitMaintMslots </FONT><BR><FONT 
    size=2>docsIfCmtsUpChnlCtrExtCollCntnInitMaintMslots</FONT> </P>
    <P><FONT size=2>All contain the following description:</FONT> </P>
    <P><FONT size=2>"...Support for this object is optional. If the object is 
    not supported, a value of zero is returned."</FONT> <BR><FONT size=2>Yet in 
    the compliance statement these object belong to the docsIfCmtsGroupV2</FONT> 
    <BR><FONT size=2>Which is described as:</FONT> <BR><FONT size=2>-- 
    conditionally mandatory group</FONT> <BR><FONT size=2>GROUP 
    docsIfCmtsGroupV2 DESCRIPTION "This group is implemented only in Cable Modem 
    Termination Systems, not in Cable Modems."</FONT></P>
    <P><FONT size=2>This description with the key word "optional" is confusing! 
    If these objects are truly optional then they need not be implemented by the 
    agent.</FONT></P>
    <P><FONT size=2>rfc2580:</FONT> <BR><FONT 
    size=2>=======================================================================</FONT> 
    <BR><FONT size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3.&nbsp; Mapping 
    of the OBJECT-GROUP macro</FONT> </P>
    <P><FONT size=2>&nbsp;&nbsp; For conformance purposes, it is useful to 
    define a collection of</FONT> <BR><FONT size=2>&nbsp;&nbsp; related managed 
    objects.&nbsp; The OBJECT-GROUP macro is used to define</FONT> <BR><FONT 
    size=2>&nbsp;&nbsp; each such collection of related objects.&nbsp; It should 
    be noted that the</FONT> <BR><FONT size=2>&nbsp;&nbsp; expansion of the 
    OBJECT-GROUP macro is something which conceptually</FONT> <BR><FONT 
    size=2>&nbsp;&nbsp; happens during implementation and not during 
    run-time.</FONT> </P>
    <P><FONT size=2>&nbsp;&nbsp; To "implement" an object, an agent must return 
    a reasonably accurate</FONT> <BR><FONT size=2>&nbsp;&nbsp; value for 
    management protocol retrieval operations; similarly, if the</FONT> <BR><FONT 
    size=2>&nbsp;&nbsp; object is writable, then in response to a management 
    protocol set</FONT> <BR><FONT size=2>&nbsp;&nbsp; operation, an agent must 
    accordingly be able to reasonably influence</FONT> <BR><FONT 
    size=2>&nbsp;&nbsp; the underlying managed entity.&nbsp; If an agent can not 
    implement an</FONT> <BR><FONT size=2>&nbsp;&nbsp; object, the management 
    protocol provides for it to return an</FONT> <BR><FONT size=2>&nbsp;&nbsp; 
    exception or error, e.g, noSuchObject [4].&nbsp; Under no 
    circumstances</FONT> <BR><FONT size=2>&lt;----- NOTE</FONT> <BR><FONT 
    size=2>&nbsp;&nbsp; shall an agent return a value for objects which it does 
    not implement</FONT> <BR><FONT size=2>&lt;-----</FONT> <BR><FONT 
    size=2>&nbsp;&nbsp; -- it must always return the appropriate exception or 
    error, as</FONT> <BR><FONT size=2>&lt;------</FONT> <BR><FONT 
    size=2>&nbsp;&nbsp; described in the protocol specification [4]. 
    </FONT><BR><FONT 
    size=2>========================================================================</FONT> 
    </P>
    <P><FONT size=2>I believe your intent is for these objects to be implemented 
    by a CMTS agent, but not mandatory for the agent count these 
    statistics.</FONT></P>
    <P><FONT size=2>I would remove the "optional" comment from the description 
    of each of these objects and change the text to read "If statistics are not 
    maintained by the agent, a value of zero is returned for this object."&nbsp; 
    or something to that nature.</FONT></P>
    <P><FONT size=2>But what really is need is a change to the description for 
    the docsIfCmtsGroupV2, the comment above the group should be include in the 
    description. I would go as far as to say these objects are "mandatory" for a 
    CMTS agent, even though this is not a mandatory-group.</FONT></P>
    <P><FONT size=2>If I have mis-interrupted that these objects are not 
    mandatory for the CMTS, then a new optional group is needed for the CMTS, 
    just for these objects.</FONT></P>
    <P><FONT size=2>From the current descriptions, am just not sure which 
    approach you where trying to take. Any clarification is greatly 
    appreciated.</FONT></P>
    <P><FONT size=2>Thanks,</FONT> <BR><FONT size=2>Will Murwin</FONT> 
    </P><BR><BR>
    <P><FONT size=2>_____________________________</FONT> <BR><FONT 
    size=2>William Murwin</FONT> <BR><FONT size=2>Broadband Communications 
    Sector</FONT> <BR><FONT size=2>Motorola Inc.</FONT> <BR><FONT size=2>Email: 
    W.Murwin@motorola.com</FONT> <BR><FONT size=2>Tel: (508) 851-8385</FONT> 
  </P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C32558.5AFFD4F2--
_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn



From mailnull@www1.ietf.org  Wed May 28 16:57:54 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 QAA23475
	for <ipcdn-archive@odin.ietf.org>; Wed, 28 May 2003 16:57:54 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4SKvS711005
	for ipcdn-archive@odin.ietf.org; Wed, 28 May 2003 16:57:28 -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 h4SKvKB10980;
	Wed, 28 May 2003 16:57: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 h4SKuDB10922
	for <ipcdn@optimus.ietf.org>; Wed, 28 May 2003 16:56: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 QAA23307
	for <ipcdn@ietf.org>; Wed, 28 May 2003 16:56:09 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19L7wP-0007lD-00
	for ipcdn@ietf.org; Wed, 28 May 2003 16:54:33 -0400
Received: from desktop.terayon.com ([63.201.251.10] helo=SCBH02.terayon.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19L7wO-0007ij-00
	for ipcdn@ietf.org; Wed, 28 May 2003 16:54:32 -0400
Received: by scowa.terayon.com with Internet Mail Service (5.5.2656.59)
	id <LP0XSD8S>; Wed, 28 May 2003 13:55:38 -0700
Message-ID: <E54A98375651D511816A00306E06B970C4A37C@OTNOAMEXCH01>
From: "Raftus, David" <david.raftus@Terayon.com>
To: "'Woundy, Richard'" <Richard_Woundy@cable.comcast.com>,
        "'Murwin William-LWM008'" <W.Murwin@motorola.com>
Cc: "'IPCDN (E-mail) (E-mail)'" <ipcdn@ietf.org>,
        "Raftus, David"
	 <david.raftus@Terayon.com>
Subject: RE: [ipcdn] RE: "Optional" in the description of objects from the
	 rfmibv2
Date: Wed, 28 May 2003 13:55:25 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3255B.76790480"
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_01C3255B.76790480
Content-Type: text/plain;
	charset="iso-8859-1"

 
 
 
-----Original Message-----
From: Raftus, David 
Sent: Wednesday, May 28, 2003 4:28 PM
To: 'Woundy, Richard'; Raftus, David; 'Murwin William-LWM008'
Cc: IPCDN (E-mail) (E-mail)
Subject: RE: [ipcdn] RE: "Optional" in the description of objects from the
rfmibv2
 
Rich,
 
It has been my laymen's understanding of snmp that objects in a table must
all be present - ie can't pick and choose individual tabular objects to
appear in a mib walk. Perhaps I am incorrect in this understanding. There
does seem to be precedent for assigning a value of zero to tabular objects
that are present, but not functionally supported.
 
Dave
 
************************************
David Raftus
Terayon Canada Ltd
340 Terry Fox Drive, Suite 202
Ottawa Canada  K2K 3A2
 
david.raftus@terayon.com           
613.592.1052  ext 222
************************************               
 
 
-----Original Message-----
From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com]
Sent: Wednesday, May 28, 2003 4:08 PM
To: 'Raftus, David'; 'Murwin William-LWM008'
Cc: IPCDN (E-mail) (E-mail)
Subject: RE: [ipcdn] RE: "Optional" in the description of objects from the
rfmibv2
 
David and William,
 
I've been meaning to ask this for some time, but... what is the management
value of implementing objects if they don't report "valid" statistics?
Instead, why not make the objects completely optional for the CMTS (from a
specification point of view)?
 
If a management station receives a value of 0 for one of these objects as
specified now, it is not clear whether or not the CMTS is keeping track of
the actual value of the object.
 
If a management station receives a 'noSuchObject' indication, then it is
clear that the CMTS is not keeping track of the object's value. ;^)
 
-- Rich
-----Original Message-----
From: Raftus, David [mailto:david.raftus@imedia.com]
Sent: Monday, May 05, 2003 3:19 PM
To: 'Murwin William-LWM008'; Raftus, David
Cc: IPCDN (E-mail) (E-mail)
Subject: [ipcdn] RE: "Optional" in the description of objects from the
rfmibv2
Hi Will, 
Thanks for the note. It's always surprising to see how well intentioned
words can be seen in another light. As you state, the intent is mandatory
implementation of the objects, but optional counting of the statistics
represented by the objects. I will make your suggested changes in v7.
Thanks, 
Dave 
************************************ 
David Raftus 
Terayon Canada Ltd 
340 Terry Fox Drive, Suite 202 
Ottawa Canada  K2K 3A2 
david.raftus@terayon.com           
613.592.1052  ext 222 
************************************               
 
-----Original Message----- 
From: Murwin William-LWM008 [ mailto:W.Murwin@motorola.com
<mailto:W.Murwin@motorola.com> ] 
Sent: Monday, May 05, 2003 3:08 PM 
To: 'david.raftus@terayon.com' 
Cc: IPCDN (E-mail) (E-mail) 
Subject: "Optional" in the description of objects from the rfmibv2 
David, 
        I was reading the description for the following objects: 
docsIfCmtsUpChnlCtrCollCntnMslots             
docsIfCmtsUpChnlCtrTotalCntnReqMslots         
docsIfCmtsUpChnlCtrUsedCntnReqMslots          
docsIfCmtsUpChnlCtrCollCntnReqMslots          
docsIfCmtsUpChnlCtrTotalCntnReqDataMslots     
docsIfCmtsUpChnlCtrUsedCntnReqDataMslots      
docsIfCmtsUpChnlCtrCollCntnReqDataMslots      
docsIfCmtsUpChnlCtrTotalCntnInitMaintMslots   
docsIfCmtsUpChnlCtrUsedCntnInitMaintMslots    
docsIfCmtsUpChnlCtrCollCntnInitMaintMslots    
docsIfCmtsUpChnlCtrExtCollCntnMslots          
docsIfCmtsUpChnlCtrExtTotalCntnReqMslots      
docsIfCmtsUpChnlCtrExtUsedCntnReqMslots       
docsIfCmtsUpChnlCtrExtCollCntnReqMslots       
docsIfCmtsUpChnlCtrExtTotalCntnReqDataMslots  
docsIfCmtsUpChnlCtrExtUsedCntnReqDataMslots   
docsIfCmtsUpChnlCtrExtCollCntnReqDataMslots   
docsIfCmtsUpChnlCtrExtTotalCntnInitMaintMslots 
docsIfCmtsUpChnlCtrExtUsedCntnInitMaintMslots 
docsIfCmtsUpChnlCtrExtCollCntnInitMaintMslots 
All contain the following description: 
"...Support for this object is optional. If the object is not supported, a
value of zero is returned." 
Yet in the compliance statement these object belong to the docsIfCmtsGroupV2

Which is described as: 
-- conditionally mandatory group 
GROUP docsIfCmtsGroupV2 DESCRIPTION "This group is implemented only in Cable
Modem Termination Systems, not in Cable Modems."
This description with the key word "optional" is confusing! If these objects
are truly optional then they need not be implemented by the agent.
rfc2580: 
======================================================================= 
        3.  Mapping of the OBJECT-GROUP macro 
   For conformance purposes, it is useful to define a collection of 
   related managed objects.  The OBJECT-GROUP macro is used to define 
   each such collection of related objects.  It should be noted that the 
   expansion of the OBJECT-GROUP macro is something which conceptually 
   happens during implementation and not during run-time. 
   To "implement" an object, an agent must return a reasonably accurate 
   value for management protocol retrieval operations; similarly, if the 
   object is writable, then in response to a management protocol set 
   operation, an agent must accordingly be able to reasonably influence 
   the underlying managed entity.  If an agent can not implement an 
   object, the management protocol provides for it to return an 
   exception or error, e.g, noSuchObject [4].  Under no circumstances 
<----- NOTE 
   shall an agent return a value for objects which it does not implement 
<----- 
   -- it must always return the appropriate exception or error, as 
<------ 
   described in the protocol specification [4]. 
======================================================================== 
I believe your intent is for these objects to be implemented by a CMTS
agent, but not mandatory for the agent count these statistics.
I would remove the "optional" comment from the description of each of these
objects and change the text to read "If statistics are not maintained by the
agent, a value of zero is returned for this object."  or something to that
nature.
But what really is need is a change to the description for the
docsIfCmtsGroupV2, the comment above the group should be include in the
description. I would go as far as to say these objects are "mandatory" for a
CMTS agent, even though this is not a mandatory-group.
If I have mis-interrupted that these objects are not mandatory for the CMTS,
then a new optional group is needed for the CMTS, just for these objects.
>From the current descriptions, am just not sure which approach you where
trying to take. Any clarification is greatly appreciated.
Thanks, 
Will Murwin 
 
_____________________________ 
William Murwin 
Broadband Communications Sector 
Motorola Inc. 
Email: W.Murwin@motorola.com 
Tel: (508) 851-8385 

------_=_NextPart_001_01C3255B.76790480
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: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@01C32539.F3E0DEB0">
<title>RE: &quot;Optional&quot; in the description of objects from the =
rfmibv2</title>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
 /* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0pt;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0pt;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p
	{margin-right:0pt;
	mso-margin-top-alt:auto;
	mso-margin-bottom-alt:auto;
	margin-left:0pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
span.EmailStyle19
	{mso-style-type:personal;
	mso-ansi-font-size:10.0pt;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	mso-ansi-font-size:10.0pt;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:#993366;}
@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 link=3Dblue vlink=3Dblue =
style=3D'tab-interval:36.0pt'>

<div class=3DSection1>

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


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


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


<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DTahoma><span =
style=3D'font-size:
10.0pt;font-family:Tahoma;color:black'>-----Original Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Raftus, David <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, May 28, =
2003 4:28
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Woundy, Richard'; =
Raftus,
David; 'Murwin William-LWM008'<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> IPCDN (E-mail) =
(E-mail)<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: [ipcdn] RE:
&quot;Optional&quot; in the description of objects from the =
rfmibv2</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></p>

<p class=3DMsoNormal><span class=3DEmailStyle19><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>R=
ich,<o:p></o:p></span></font></span></p>

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


<p class=3DMsoNormal><span class=3DEmailStyle19><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>I=
t has
been my laymen's understanding of snmp that objects in a table must all =
be
present - ie can't pick and choose individual tabular objects to appear =
in a
mib walk. Perhaps I am incorrect in this understanding. There does seem =
to be precedent
for assigning a value of zero to tabular objects that are present, but =
not
functionally supported.<o:p></o:p></span></font></span></p>

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


<p class=3DMsoNormal><span class=3DEmailStyle19><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>D=
ave<o:p></o:p></span></font></span></p>

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


<p class=3DMsoNormal><!--[if supportFields]><span =
class=3DEmailStyle19><font=20
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial'><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></span></font></span><![end=
if]--><font
size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial;color:blue'>***********************************=
*<o:p></o:p></span></font></p>

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

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

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

<p class=3DMsoNormal><i><font size=3D2 color=3Dblue face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial;co=
lor: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><font size=3D2 color=3Dblue face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial;co=
lor:blue;
font-style:italic'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></i></p>

<p class=3DMsoNormal><i><font size=3D2 color=3Dblue face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial;co=
lor: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><font size=3D2 color=3Dblue face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial;co=
lor: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><font size=3D2 color=3Dblue face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial;co=
lor:blue;
font-style:italic'>************************************<span
style=3D"mso-spacerun: yes">&nbsp; </span></span></font></i><font =
size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;
font-family:Arial;color:navy'><span style=3D"mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;</span></span></font><font
size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial;color:black;mso-color-alt:windowtext'><o:p></o:=
p></span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal><!--[if supportFields]><span =
class=3DEmailStyle19><font=20
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial'><span =
style=3D'mso-element:field-end'></span></span></font></span><![endif]-->=
<span
class=3DEmailStyle19><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DTahoma><span =
style=3D'font-size:
10.0pt;font-family:Tahoma;color:black'>-----Original Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Woundy, Richard
[mailto:Richard_Woundy@cable.comcast.com]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, May 28, =
2003 4:08
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Raftus, David'; =
'Murwin
William-LWM008'<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> IPCDN (E-mail) =
(E-mail)<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: [ipcdn] RE:
&quot;Optional&quot; in the description of objects from the =
rfmibv2</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>David and =
William,</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>&nbsp;</span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>I've been meaning to ask this for =
some time,
but... what is the management value of implementing objects if they =
don't
report &quot;valid&quot; statistics? Instead, why not make the objects
completely optional for the CMTS (from a specification point of =
view)?</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>&nbsp;</span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>If a management station receives a =
value of
0 for one of these objects as specified now, it&nbsp;is not =
clear&nbsp;whether
or not the CMTS is&nbsp;keeping track&nbsp;of&nbsp;the actual value of =
the
object.</span></font><font color=3Dblack><span =
style=3D'color:black;mso-color-alt:
windowtext'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>&nbsp;</span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>If a management station receives a
'noSuchObject' indication, then it is clear that the CMTS is not =
keeping track
of the object's value. ;^)</span></font><font color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>&nbsp;</span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>-- Rich</span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;margin-bottom:12.0pt;
margin-left:36.0pt'><font size=3D2 color=3Dblack face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>-----Original
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Raftus, David
[mailto:david.raftus@imedia.com]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, May 05, =
2003 3:19 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Murwin =
William-LWM008';
Raftus, David<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> IPCDN (E-mail) =
(E-mail)<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> [ipcdn] RE:
&quot;Optional&quot; in the description of objects from the =
rfmibv2</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>Hi Will,</span></font><font =
color=3Dblack><span
style=3D'color:black'> </span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>Thanks for the note. It's always
surprising to see how well intentioned words can be seen in another =
light. As
you state, the intent is mandatory implementation of the objects, but =
optional
counting of the statistics represented by the objects. I will make your
suggested changes in v7.</span></font><font color=3Dblack><span =
style=3D'color:
black;mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>Thanks,</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Dave</span></font><font color=3Dblack><span =
style=3D'color:black'> </span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>*********************************=
***</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>David Raftus</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Terayon Canada Ltd</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>340 Terry Fox Drive, Suite 202</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Ottawa Canada&nbsp; K2K 3A2</span></font><font =
color=3Dblack><span
style=3D'color:black'> </span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>david.raftus@terayon.com&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>613.592.1052&nbsp; ext 222</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>************************************&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font><font color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:36.0pt'><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>-----Original =
Message-----</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>From: Murwin William-LWM008 [<a =
href=3D"mailto:W.Murwin@motorola.com">mailto:W.Murwin@motorola.com</a>]<=
/span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Sent: Monday, May 05, 2003 3:08 PM</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>To: 'david.raftus@terayon.com'</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Cc: IPCDN (E-mail) (E-mail)</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Subject: &quot;Optional&quot; in the description of =
objects from
the rfmibv2</span></font><font color=3Dblack><span =
style=3D'color:black'> </span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>David,</span></font><font =
color=3Dblack><span
style=3D'color:black'> </span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;
I was reading the description for the following =
objects:</span></font><font
color=3Dblack><span style=3D'color:black'> </span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>docsIfCmtsUpChnlCtrCollCntnMslots=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=

</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrTotalCntnReqMslots&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrUsedCntnReqMslots&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrCollCntnReqMslots&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrTotalCntnReqDataMslots&nbsp;&nbsp;&nbsp;=
&nbsp; </span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrUsedCntnReqDataMslots&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrCollCntnReqDataMslots&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrTotalCntnInitMaintMslots&nbsp;&nbsp; =
</span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrUsedCntnInitMaintMslots&nbsp;&nbsp;&nbsp=
; </span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrCollCntnInitMaintMslots&nbsp;&nbsp;&nbsp=
; </span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrExtCollCntnMslots&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrExtTotalCntnReqMslots&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrExtUsedCntnReqMslots&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrExtCollCntnReqMslots&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrExtTotalCntnReqDataMslots&nbsp; =
</span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrExtUsedCntnReqDataMslots&nbsp;&nbsp; =
</span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrExtCollCntnReqDataMslots&nbsp;&nbsp; =
</span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrExtTotalCntnInitMaintMslots</span></font=
><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrExtUsedCntnInitMaintMslots =
</span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrExtCollCntnInitMaintMslots</span></font>=
<font
color=3Dblack><span style=3D'color:black'> </span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>All contain the following =
description:</span></font><font
color=3Dblack><span style=3D'color:black'> </span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>&quot;...Support for this object =
is
optional. If the object is not supported, a value of zero is =
returned.&quot;</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Yet in the compliance statement these object belong to the
docsIfCmtsGroupV2</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Which is described as:</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>-- conditionally mandatory group</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>GROUP docsIfCmtsGroupV2 DESCRIPTION &quot;This group is
implemented only in Cable Modem Termination Systems, not in Cable =
Modems.&quot;</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>This description with the key =
word
&quot;optional&quot; is confusing! If these objects are truly optional =
then
they need not be implemented by the agent.</span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>rfc2580:</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>=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=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</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3.&nbsp; =
Mapping of the
OBJECT-GROUP macro</span></font><font color=3Dblack><span =
style=3D'color:black'> </span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>&nbsp;&nbsp; For conformance =
purposes, it
is useful to define a collection of</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp; related managed objects.&nbsp; The =
OBJECT-GROUP macro
is used to define</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp; each such collection of related =
objects.&nbsp; It
should be noted that the</span></font><font color=3Dblack><span =
style=3D'color:
black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp; expansion of the OBJECT-GROUP macro is =
something
which conceptually</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp; happens during implementation and not during
run-time.</span></font><font color=3Dblack><span style=3D'color:black'> =
</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>&nbsp;&nbsp; To =
&quot;implement&quot; an
object, an agent must return a reasonably accurate</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp; value for management protocol retrieval =
operations; similarly,
if the</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp; object is writable, then in response to a =
management
protocol set</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp; operation, an agent must accordingly be able =
to
reasonably influence</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp; the underlying managed entity.&nbsp; If an =
agent can
not implement an</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp; object, the management protocol provides for =
it to
return an</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp; exception or error, e.g, noSuchObject =
[4].&nbsp;
Under no circumstances</span></font><font color=3Dblack><span =
style=3D'color:black'>
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&lt;----- NOTE</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp; shall an agent return a value for objects =
which it
does not implement</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&lt;-----</span></font><font color=3Dblack><span =
style=3D'color:black'>
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp; -- it must always return the appropriate =
exception or
error, as</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&lt;------</span></font><font color=3Dblack><span =
style=3D'color:black'>
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp; described in the protocol specification [4]. =
</span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>=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=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</span></font><font
color=3Dblack><span style=3D'color:black'> </span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>I believe your intent is for =
these objects
to be implemented by a CMTS agent, but not mandatory for the agent =
count these
statistics.</span></font><font color=3Dblack><span =
style=3D'color:black;mso-color-alt:
windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>I would remove the =
&quot;optional&quot;
comment from the description of each of these objects and change the =
text to
read &quot;If statistics are not maintained by the agent, a value of =
zero is
returned for this object.&quot;&nbsp; or something to that =
nature.</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>But what really is need is a =
change to the
description for the docsIfCmtsGroupV2, the comment above the group =
should be
include in the description. I would go as far as to say these objects =
are
&quot;mandatory&quot; for a CMTS agent, even though this is not a
mandatory-group.</span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>If I have mis-interrupted that =
these
objects are not mandatory for the CMTS, then a new optional group is =
needed for
the CMTS, just for these objects.</span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>From the current descriptions, =
am just not
sure which approach you where trying to take. Any clarification is =
greatly
appreciated.</span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>Thanks,</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Will Murwin</span></font><font color=3Dblack><span =
style=3D'color:
black'> </span></font><font color=3Dblack><span =
style=3D'color:black;mso-color-alt:
windowtext'><o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;margin-bottom:12.0pt;
margin-left:36.0pt'><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>_____________________________</sp=
an></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>William Murwin</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Broadband Communications Sector</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Motorola Inc.</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Email: W.Murwin@motorola.com</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Tel: (508) 851-8385</span></font><font color=3Dblack><span
style=3D'color:black'> </span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C3255B.76790480--
_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn



From mailnull@www1.ietf.org  Wed May 28 18:52: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 SAA28464
	for <ipcdn-archive@odin.ietf.org>; Wed, 28 May 2003 18:52:37 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4SMqDC19622
	for ipcdn-archive@odin.ietf.org; Wed, 28 May 2003 18:52:13 -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 h4SMqBB19609;
	Wed, 28 May 2003 18:52:11 -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 h4S167B06835
	for <ipcdn@optimus.ietf.org>; Tue, 27 May 2003 21:06:07 -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 VAA12587
	for <ipcdn@ietf.org>; Tue, 27 May 2003 21:06:03 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19KpMj-0004Ad-00
	for ipcdn@ietf.org; Tue, 27 May 2003 21:04:29 -0400
Received: from sj-core-1.cisco.com ([171.71.177.237])
	by ietf-mx with esmtp (Exim 4.12)
	id 19KpMi-0004AD-00
	for ipcdn@ietf.org; Tue, 27 May 2003 21:04:29 -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 h4S15NFY001947;
	Tue, 27 May 2003 18:05:25 -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 AHR57499;
	Tue, 27 May 2003 18:05:22 -0700 (PDT)
Message-Id: <4.3.2.7.2.20030527175545.04da1e60@mira-sjc5-1.cisco.com>
X-Sender: milu@mira-sjc5-1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 27 May 2003 18:05:22 -0700
To: Murwin William-LWM008 <W.Murwin@motorola.com>
From: Minnie Lu <milu@cisco.com>
Cc: "'Minnie Lu'" <milu@cisco.com>, docsis-oss@cablelabs.com,
        "IPCDN (E-mail) (E-mail)" <ipcdn@ietf.org>,
        Richard_Woundy@cable.comcast.com,
        "Michael W. Patrick (E-mail)" <mpatrick@dma.isg.mot.com>,
        "David Raftus (E-mail)" <david.raftus@imedia.com>
In-Reply-To: <19CD0E423FC1D611893500508B6F0B9CF396B4@ma07exm01.dma.isg.m
 ot.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [ipcdn] Re: CM pkts counts on the CMTS
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, William,

It will certainly help to have traffic counters per CM for all kinds of CM 
registration DOCSIS mode. From my personal experience, some customers even 
want those counters remain across CM reset (offline/online) and as long as 
the CM is still in CMTS' database, these counters remains though the CM is 
offline.

Thanks !
Minnie


At 05:15 PM 5/23/2003 -0400, Murwin William-LWM008 wrote:
>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.
>
>
>
>-----Original Message-----
>From: Minnie Lu [mailto:milu@cisco.com]
>Sent: Tuesday, May 06, 2003 4:43 PM
>To: Murwin William-LWM008
>Cc: 'Minnie Lu'; Richard_Woundy@cable.comcast.com;
>docsis-oss@cablelabs.com; IPCDN (E-mail) (E-mail); Michael W. Patrick
>(E-mail); David Raftus (E-mail)
>Subject: RE: sid counter inconsistent between
>draft-ietf-ipcdn-qos-mib-08. txt and DOCS-IF-MIB ?
>
>
>Hi, Will,
>
>    Thanks a lot ! I also hope that "the issue could be re-discussed and
>whatever conclusion is reached, can be document in the description of those
>objects."
>
>     Appreciate your help !
>     Thanks !
>     Minnie
>
>
>At 03:22 PM 5/6/2003 -0400, Murwin William-LWM008 wrote:
> >Minnie,
> >
> >         After much consideration, DOCSIS QOS MIB version 9 will remove
> > the text from section Section 2.2.2.1 Interoperation with DOCSIS 1.0:
> >
> >5.  At the CMTS, the Docsis 1.0 MIB objects
> >     docsIfCmtsServiceInPackets and docsIfCmtsServiceInOctets for a
> >     SID assigned to a Docsis 1.1 or Docsis 2.0 modem count only the
> >     pre-registration packets/bytes of those modems."
> >
> >This is not an issue for the QOS MIB. 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.
> >
> >Sincerely,
> >Will Murwin
> >
> >-----Original Message-----
> >From: Minnie Lu [mailto:milu@cisco.com]
> >Sent: Thursday, March 20, 2003 4:16 PM
> >To: Richard_Woundy@cable.comcast.com; docsis-oss@cablelabs.com
> >Cc: milu@cisco.com
> >Subject: sid counter inconsistent between
> >draft-ietf-ipcdn-qos-mib-08.txt and DOCS-IF-MIB ?
> >
> >
> >Hi,
> >
> >    Since I have not yet got any reason for the sid counter
> >inconsistence,  I would like to raise this issue again and hope this time,
> >people will reconsider it.
> >
> >In draft-ietf-ipcdn-qos-mib-08.txt,
> >
> >1. Section 2.2.2.1 Interoperation with DOCSIS 1.0
> >         "5.  At the CMTS, the Docsis 1.0 MIB objects
> >           docsIfCmtsServiceInPackets and docsIfCmtsServiceInOctets for a
> >           SID assigned to a Docsis 1.1 or Docsis 2.0 modem count only the
> >           pre-registration packets/bytes of those modems."
> >
> >           Maybe I miss some discussion before.  If there was some
> >discussion before, please excuse me to bring this up again because I really
> >don't understand why this is necessary to enforce this rule. SID concept is
> >still applicable to DOCSIS1.1 or 2.0.  The MIB objects
> >docsIfCmtsServiceInPackets and docsIfCmtsServiceInOctets definitions look
> >good to me even for DOCSIS1.1 or 2.0.
> >
> >     docsIfCmtsServiceInOctets OBJECT-TYPE
> >              "The cumulative number of Packet Data octets received
> >               on this Service ID. The count does not include the
> >               size of the Cable MAC header"
> >
> >     docsIfCmtsServiceInPackets OBJECT-TYPE
> >              "The cumulative number of Packet Data packets received
> >               on this Service ID."
> >
> >     From the description, it seems to me that they will count all the
> >traffic including pre-registration and post-registration received on this
> >Service ID no matter that this Service ID associates with DOCSIS1.0 or
> >DOCSIS1.1 or DOCSIS2.0 CMs.  So they are consistent for various version of
> >CMs mode.
> >
> >     Also, in the same section, item 3 .
> >          "The docsIfCmServiceTable row for the DOCSIS 1.1 or DOCSIS 2.0 
> modem
> >           continues to exist, and the various statistic objects in that
> >           row are incremented."
> >
> >     It sounds to me the item 4 is inconsistent with item 3 above.  For the
> >same MIB object, it counts differently in CM and CMTS for the SIDs
> >associated with DOCSIS1.1 CMs.   I think it is good to keep CM and CMTS the
> >same as described in item 3.
> >
> >     Also when customer queries the docsIfCmtsServiceTable, the customer
> >might wonder why some entries have low count and not aware of they are for
> >the SID belongs to CM in DOCSIS1.1 mode.
> >
> >I noticed this is not in version 4.  From v5, it starts having such
> >statements.
> >
> >Thanks !
> >Minnie

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



From mailnull@www1.ietf.org  Wed May 28 18:52:45 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 SAA28479
	for <ipcdn-archive@odin.ietf.org>; Wed, 28 May 2003 18:52:45 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4SMqLN19653
	for ipcdn-archive@odin.ietf.org; Wed, 28 May 2003 18:52:21 -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 h4SMqFB19638;
	Wed, 28 May 2003 18:52: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 h4SKSZB08719
	for <ipcdn@optimus.ietf.org>; Wed, 28 May 2003 16:28:35 -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 QAA22277
	for <ipcdn@ietf.org>; Wed, 28 May 2003 16:28:32 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19L7Vf-0007T7-00
	for ipcdn@ietf.org; Wed, 28 May 2003 16:26:55 -0400
Received: from desktop.terayon.com ([63.201.251.10] helo=SCBH02.terayon.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19L7Ve-0007St-00
	for ipcdn@ietf.org; Wed, 28 May 2003 16:26:54 -0400
Received: by scowa.terayon.com with Internet Mail Service (5.5.2656.59)
	id <LP0XSDSL>; Wed, 28 May 2003 13:27:51 -0700
Message-ID: <E54A98375651D511816A00306E06B970C4A377@OTNOAMEXCH01>
From: "Raftus, David" <david.raftus@Terayon.com>
To: "'Woundy, Richard'" <Richard_Woundy@cable.comcast.com>,
        "Raftus, David" <david.raftus@Terayon.com>,
        "'Murwin William-LWM008'"
	 <W.Murwin@motorola.com>
Cc: "IPCDN (E-mail) (E-mail)" <ipcdn@ietf.org>
Subject: RE: [ipcdn] RE: "Optional" in the description of objects from the
	 rfmibv2
Date: Wed, 28 May 2003 13:27:37 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C32557.94684630"
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_01C32557.94684630
Content-Type: text/plain;
	charset="iso-8859-1"

Rich,
 
It has been my laymen's understanding of snmp that objects in a table must
all be present - ie can't pick and choose individual tabular objects to
appear in a mib walk. Perhaps I am incorrect in this understanding. There
does seem to be precedent for assigning a value of zero to tabular objects
that are present, but not functionally supported.
 
Dave
 
************************************
David Raftus
Terayon Canada Ltd
340 Terry Fox Drive, Suite 202
Ottawa Canada  K2K 3A2
 
david.raftus@terayon.com           
613.592.1052  ext 222
************************************               
 
 
-----Original Message-----
From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com]
Sent: Wednesday, May 28, 2003 4:08 PM
To: 'Raftus, David'; 'Murwin William-LWM008'
Cc: IPCDN (E-mail) (E-mail)
Subject: RE: [ipcdn] RE: "Optional" in the description of objects from the
rfmibv2
 
David and William,
 
I've been meaning to ask this for some time, but... what is the management
value of implementing objects if they don't report "valid" statistics?
Instead, why not make the objects completely optional for the CMTS (from a
specification point of view)?
 
If a management station receives a value of 0 for one of these objects as
specified now, it is not clear whether or not the CMTS is keeping track of
the actual value of the object.
 
If a management station receives a 'noSuchObject' indication, then it is
clear that the CMTS is not keeping track of the object's value. ;^)
 
-- Rich
-----Original Message-----
From: Raftus, David [mailto:david.raftus@imedia.com]
Sent: Monday, May 05, 2003 3:19 PM
To: 'Murwin William-LWM008'; Raftus, David
Cc: IPCDN (E-mail) (E-mail)
Subject: [ipcdn] RE: "Optional" in the description of objects from the
rfmibv2
Hi Will, 
Thanks for the note. It's always surprising to see how well intentioned
words can be seen in another light. As you state, the intent is mandatory
implementation of the objects, but optional counting of the statistics
represented by the objects. I will make your suggested changes in v7.
Thanks, 
Dave 
************************************ 
David Raftus 
Terayon Canada Ltd 
340 Terry Fox Drive, Suite 202 
Ottawa Canada  K2K 3A2 
david.raftus@terayon.com           
613.592.1052  ext 222 
************************************               
 
-----Original Message----- 
From: Murwin William-LWM008 [ mailto:W.Murwin@motorola.com
<mailto:W.Murwin@motorola.com> ] 
Sent: Monday, May 05, 2003 3:08 PM 
To: 'david.raftus@terayon.com' 
Cc: IPCDN (E-mail) (E-mail) 
Subject: "Optional" in the description of objects from the rfmibv2 
David, 
        I was reading the description for the following objects: 
docsIfCmtsUpChnlCtrCollCntnMslots             
docsIfCmtsUpChnlCtrTotalCntnReqMslots         
docsIfCmtsUpChnlCtrUsedCntnReqMslots          
docsIfCmtsUpChnlCtrCollCntnReqMslots          
docsIfCmtsUpChnlCtrTotalCntnReqDataMslots     
docsIfCmtsUpChnlCtrUsedCntnReqDataMslots      
docsIfCmtsUpChnlCtrCollCntnReqDataMslots      
docsIfCmtsUpChnlCtrTotalCntnInitMaintMslots   
docsIfCmtsUpChnlCtrUsedCntnInitMaintMslots    
docsIfCmtsUpChnlCtrCollCntnInitMaintMslots    
docsIfCmtsUpChnlCtrExtCollCntnMslots          
docsIfCmtsUpChnlCtrExtTotalCntnReqMslots      
docsIfCmtsUpChnlCtrExtUsedCntnReqMslots       
docsIfCmtsUpChnlCtrExtCollCntnReqMslots       
docsIfCmtsUpChnlCtrExtTotalCntnReqDataMslots  
docsIfCmtsUpChnlCtrExtUsedCntnReqDataMslots   
docsIfCmtsUpChnlCtrExtCollCntnReqDataMslots   
docsIfCmtsUpChnlCtrExtTotalCntnInitMaintMslots 
docsIfCmtsUpChnlCtrExtUsedCntnInitMaintMslots 
docsIfCmtsUpChnlCtrExtCollCntnInitMaintMslots 
All contain the following description: 
"...Support for this object is optional. If the object is not supported, a
value of zero is returned." 
Yet in the compliance statement these object belong to the docsIfCmtsGroupV2

Which is described as: 
-- conditionally mandatory group 
GROUP docsIfCmtsGroupV2 DESCRIPTION "This group is implemented only in Cable
Modem Termination Systems, not in Cable Modems."
This description with the key word "optional" is confusing! If these objects
are truly optional then they need not be implemented by the agent.
rfc2580: 
======================================================================= 
        3.  Mapping of the OBJECT-GROUP macro 
   For conformance purposes, it is useful to define a collection of 
   related managed objects.  The OBJECT-GROUP macro is used to define 
   each such collection of related objects.  It should be noted that the 
   expansion of the OBJECT-GROUP macro is something which conceptually 
   happens during implementation and not during run-time. 
   To "implement" an object, an agent must return a reasonably accurate 
   value for management protocol retrieval operations; similarly, if the 
   object is writable, then in response to a management protocol set 
   operation, an agent must accordingly be able to reasonably influence 
   the underlying managed entity.  If an agent can not implement an 
   object, the management protocol provides for it to return an 
   exception or error, e.g, noSuchObject [4].  Under no circumstances 
<----- NOTE 
   shall an agent return a value for objects which it does not implement 
<----- 
   -- it must always return the appropriate exception or error, as 
<------ 
   described in the protocol specification [4]. 
======================================================================== 
I believe your intent is for these objects to be implemented by a CMTS
agent, but not mandatory for the agent count these statistics.
I would remove the "optional" comment from the description of each of these
objects and change the text to read "If statistics are not maintained by the
agent, a value of zero is returned for this object."  or something to that
nature.
But what really is need is a change to the description for the
docsIfCmtsGroupV2, the comment above the group should be include in the
description. I would go as far as to say these objects are "mandatory" for a
CMTS agent, even though this is not a mandatory-group.
If I have mis-interrupted that these objects are not mandatory for the CMTS,
then a new optional group is needed for the CMTS, just for these objects.
>From the current descriptions, am just not sure which approach you where
trying to take. Any clarification is greatly appreciated.
Thanks, 
Will Murwin 
 
_____________________________ 
William Murwin 
Broadband Communications Sector 
Motorola Inc. 
Email: W.Murwin@motorola.com 
Tel: (508) 851-8385 

------_=_NextPart_001_01C32557.94684630
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: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@01C32536.11DD66D0">
<title>RE: &quot;Optional&quot; in the description of objects from the =
rfmibv2</title>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
 /* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0pt;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0pt;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p
	{margin-right:0pt;
	mso-margin-top-alt:auto;
	mso-margin-bottom-alt:auto;
	margin-left:0pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	mso-ansi-font-size:10.0pt;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
@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 link=3Dblue vlink=3Dblue =
style=3D'tab-interval:36.0pt'>

<div class=3DSection1>

<p class=3DMsoNormal><span class=3DEmailStyle18><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>R=
ich,<o:p></o:p></span></font></span></p>

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


<p class=3DMsoNormal><span class=3DEmailStyle18><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>I=
t has
been my laymen's understanding of snmp that objects in a table must all =
be
present - ie can't pick and choose individual tabular objects to appear =
in a
mib walk. Perhaps I am incorrect in this understanding. There does seem =
to be
precedent for assigning a value of zero to tabular objects that are =
present,
but not functionally supported.<o:p></o:p></span></font></span></p>

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


<p class=3DMsoNormal><span class=3DEmailStyle18><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>D=
ave<o:p></o:p></span></font></span></p>

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


<p class=3DMsoNormal><!--[if supportFields]><span =
class=3DEmailStyle18><font=20
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial'><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></span></font></span><![end=
if]--><font
size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial;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;
font-family:Arial;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;
font-family:Arial;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;
font-family:Arial;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;
font-family:Arial;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;
font-family:Arial;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;
font-family:Arial;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;
font-family:Arial;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;
font-family:Arial;color:blue;font-style:italic'>************************=
************<span
style=3D"mso-spacerun: yes">&nbsp; </span></span></font></i><font =
size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;
font-family:Arial;color:navy'><span style=3D"mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;</span></span></font><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial;color:navy;mso-color-alt:windowtext'><o:p></o:p=
></span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><!--[if supportFields]><span =
class=3DEmailStyle18><font=20
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial'><span =
style=3D'mso-element:field-end'></span></span></font></span><![endif]-->=
<span
class=3DEmailStyle18><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DTahoma><span =
style=3D'font-size:
10.0pt;font-family:Tahoma;color:black'>-----Original Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Woundy, Richard
[mailto:Richard_Woundy@cable.comcast.com]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, May 28, =
2003 4:08
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Raftus, David'; =
'Murwin
William-LWM008'<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> IPCDN (E-mail) =
(E-mail)<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: [ipcdn] RE:
&quot;Optional&quot; in the description of objects from the =
rfmibv2</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>David and =
William,</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>&nbsp;</span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>I've been meaning to ask this for =
some
time, but... what is the management value of implementing objects if =
they don't
report &quot;valid&quot; statistics? Instead, why not make the objects
completely optional for the CMTS (from a specification point of =
view)?</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>&nbsp;</span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>If a management station receives a =
value
of 0 for one of these objects as specified now, it&nbsp;is not
clear&nbsp;whether or not the CMTS is&nbsp;keeping =
track&nbsp;of&nbsp;the
actual value of the object.</span></font><font color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>&nbsp;</span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>If a management station receives a
'noSuchObject' indication, then it is clear that the CMTS is not =
keeping track
of the object's value. ;^)</span></font><font color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>&nbsp;</span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>-- Rich</span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;margin-bottom:12.0=
pt;
margin-left:36.0pt'><font size=3D2 color=3Dblack face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>-----Original
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Raftus, David
[mailto:david.raftus@imedia.com]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, May 05, =
2003 3:19 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Murwin =
William-LWM008';
Raftus, David<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> IPCDN (E-mail) =
(E-mail)<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> [ipcdn] RE:
&quot;Optional&quot; in the description of objects from the =
rfmibv2</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>Hi Will,</span></font><font =
color=3Dblack><span
style=3D'color:black'> </span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>Thanks for the note. It's always
surprising to see how well intentioned words can be seen in another =
light. As
you state, the intent is mandatory implementation of the objects, but =
optional
counting of the statistics represented by the objects. I will make your
suggested changes in v7.</span></font><font color=3Dblack><span =
style=3D'color:
black;mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>Thanks,</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Dave</span></font><font color=3Dblack><span =
style=3D'color:black'> </span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>*********************************=
***</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>David Raftus</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Terayon Canada Ltd</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>340 Terry Fox Drive, Suite 202</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Ottawa Canada&nbsp; K2K 3A2</span></font><font =
color=3Dblack><span
style=3D'color:black'> </span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>david.raftus@terayon.com&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>613.592.1052&nbsp; ext 222</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>************************************&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font><font color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:36.0pt'><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>-----Original =
Message-----</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>From: Murwin William-LWM008 [<a =
href=3D"mailto:W.Murwin@motorola.com">mailto:W.Murwin@motorola.com</a>]<=
/span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Sent: Monday, May 05, 2003 3:08 PM</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>To: 'david.raftus@terayon.com'</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Cc: IPCDN (E-mail) (E-mail)</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Subject: &quot;Optional&quot; in the description of =
objects from
the rfmibv2</span></font><font color=3Dblack><span =
style=3D'color:black'> </span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>David,</span></font><font =
color=3Dblack><span
style=3D'color:black'> </span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;
I was reading the description for the following =
objects:</span></font><font
color=3Dblack><span style=3D'color:black'> </span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>docsIfCmtsUpChnlCtrCollCntnMslots=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=

</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrTotalCntnReqMslots&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrUsedCntnReqMslots&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrCollCntnReqMslots&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrTotalCntnReqDataMslots&nbsp;&nbsp;&nbsp;=
&nbsp; </span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrUsedCntnReqDataMslots&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrCollCntnReqDataMslots&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrTotalCntnInitMaintMslots&nbsp;&nbsp; =
</span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrUsedCntnInitMaintMslots&nbsp;&nbsp;&nbsp=
; </span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrCollCntnInitMaintMslots&nbsp;&nbsp;&nbsp=
; </span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrExtCollCntnMslots&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrExtTotalCntnReqMslots&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrExtUsedCntnReqMslots&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrExtCollCntnReqMslots&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrExtTotalCntnReqDataMslots&nbsp; =
</span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrExtUsedCntnReqDataMslots&nbsp;&nbsp; =
</span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrExtCollCntnReqDataMslots&nbsp;&nbsp; =
</span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrExtTotalCntnInitMaintMslots</span></font=
><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrExtUsedCntnInitMaintMslots =
</span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrExtCollCntnInitMaintMslots</span></font>=
<font
color=3Dblack><span style=3D'color:black'> </span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>All contain the following =
description:</span></font><font
color=3Dblack><span style=3D'color:black'> </span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>&quot;...Support for this object =
is
optional. If the object is not supported, a value of zero is =
returned.&quot;</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Yet in the compliance statement these object belong to the
docsIfCmtsGroupV2</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Which is described as:</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>-- conditionally mandatory group</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>GROUP docsIfCmtsGroupV2 DESCRIPTION &quot;This group is
implemented only in Cable Modem Termination Systems, not in Cable =
Modems.&quot;</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>This description with the key =
word
&quot;optional&quot; is confusing! If these objects are truly optional =
then
they need not be implemented by the agent.</span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>rfc2580:</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>=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=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</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3.&nbsp; =
Mapping of the
OBJECT-GROUP macro</span></font><font color=3Dblack><span =
style=3D'color:black'> </span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>&nbsp;&nbsp; For conformance =
purposes, it
is useful to define a collection of</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp; related managed objects.&nbsp; The =
OBJECT-GROUP macro
is used to define</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp; each such collection of related =
objects.&nbsp; It
should be noted that the</span></font><font color=3Dblack><span =
style=3D'color:
black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp; expansion of the OBJECT-GROUP macro is =
something
which conceptually</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp; happens during implementation and not during
run-time.</span></font><font color=3Dblack><span style=3D'color:black'> =
</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>&nbsp;&nbsp; To =
&quot;implement&quot; an
object, an agent must return a reasonably accurate</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp; value for management protocol retrieval =
operations;
similarly, if the</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp; object is writable, then in response to a =
management
protocol set</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp; operation, an agent must accordingly be able =
to
reasonably influence</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp; the underlying managed entity.&nbsp; If an =
agent can
not implement an</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp; object, the management protocol provides for =
it to
return an</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp; exception or error, e.g, noSuchObject =
[4].&nbsp;
Under no circumstances</span></font><font color=3Dblack><span =
style=3D'color:black'>
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&lt;----- NOTE</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp; shall an agent return a value for objects =
which it
does not implement</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&lt;-----</span></font><font color=3Dblack><span =
style=3D'color:black'>
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp; -- it must always return the appropriate =
exception or
error, as</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&lt;------</span></font><font color=3Dblack><span =
style=3D'color:black'>
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp; described in the protocol specification [4]. =
</span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>=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=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</span></font><font
color=3Dblack><span style=3D'color:black'> </span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>I believe your intent is for =
these objects
to be implemented by a CMTS agent, but not mandatory for the agent =
count these
statistics.</span></font><font color=3Dblack><span =
style=3D'color:black;mso-color-alt:
windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>I would remove the =
&quot;optional&quot;
comment from the description of each of these objects and change the =
text to
read &quot;If statistics are not maintained by the agent, a value of =
zero is
returned for this object.&quot;&nbsp; or something to that =
nature.</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>But what really is need is a =
change to the
description for the docsIfCmtsGroupV2, the comment above the group =
should be
include in the description. I would go as far as to say these objects =
are
&quot;mandatory&quot; for a CMTS agent, even though this is not a
mandatory-group.</span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>If I have mis-interrupted that =
these
objects are not mandatory for the CMTS, then a new optional group is =
needed for
the CMTS, just for these objects.</span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>From the current descriptions, =
am just not
sure which approach you where trying to take. Any clarification is =
greatly
appreciated.</span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>Thanks,</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Will Murwin</span></font><font color=3Dblack><span =
style=3D'color:
black'> </span></font><font color=3Dblack><span =
style=3D'color:black;mso-color-alt:
windowtext'><o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;margin-bottom:12.0pt;
margin-left:36.0pt'><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>_____________________________</sp=
an></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>William Murwin</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Broadband Communications Sector</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Motorola Inc.</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Email: W.Murwin@motorola.com</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Tel: (508) 851-8385</span></font><font color=3Dblack><span
style=3D'color:black'> </span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C32557.94684630--
_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn



From mailnull@www1.ietf.org  Thu May 29 08:23: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 IAA00487
	for <ipcdn-archive@odin.ietf.org>; Thu, 29 May 2003 08:23:49 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4TCNMD16987
	for ipcdn-archive@odin.ietf.org; Thu, 29 May 2003 08:23: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 h4TCNAB16974;
	Thu, 29 May 2003 08:23: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 h4TCM6B16925
	for <ipcdn@optimus.ietf.org>; Thu, 29 May 2003 08:22:06 -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 IAA00436
	for <ipcdn@ietf.org>; Thu, 29 May 2003 08:22:04 -0400 (EDT)
From: Wilson.Sawyer@arrisi.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19LMOQ-0006Vy-00
	for ipcdn@ietf.org; Thu, 29 May 2003 08:20:26 -0400
Received: from pluto.arrisi.com ([63.82.122.6])
	by ietf-mx with esmtp (Exim 4.12)
	id 19LMOP-0006Vv-00
	for ipcdn@ietf.org; Thu, 29 May 2003 08:20:25 -0400
Received: from titan ([10.24.249.1])
          by pluto.arrisi.com (Lotus Domino Release 5.0.12)
          with ESMTP id 2003052908265870:38583 ;
          Thu, 29 May 2003 08:26:58 -0400 
To: ipcdn@ietf.org
Cc: bwijnen@lucent.com
X-Mailer: Lotus Notes Release 5.0.9  November 16, 2001
Message-ID: <OFEA583539.5346742F-ON85256D35.0041DAB4@arrisi.com>
Date: Thu, 29 May 2003 08:22:02 -0400
MIME-Version: 1.0
X-MIMETrack: Serialize by Router on Titan/Arris(Release 5.0.12  |February 13, 2003) at
 05/29/2003 08:22:03 AM,
	Itemize by SMTP Server on Pluto/Antec(Release 5.0.12  |February 13, 2003) at
 05/29/2003 08:26:58 AM,
	Serialize by Router on Pluto/Antec(Release 5.0.12  |February 13, 2003) at
 05/29/2003 08:26:59 AM,
	Serialize complete at 05/29/2003 08:26:59 AM
Content-type: text/plain; charset=us-ascii
Subject: [ipcdn] draft submitted: subscriber management MIB -11
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>

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



From mailnull@www1.ietf.org  Thu May 29 08:36:21 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 IAA00935
	for <ipcdn-archive@odin.ietf.org>; Thu, 29 May 2003 08:36:21 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4TCZrO17706
	for ipcdn-archive@odin.ietf.org; Thu, 29 May 2003 08:35: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 h4TCY8B17602;
	Thu, 29 May 2003 08:34:08 -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 h4TCXVB17526
	for <ipcdn@optimus.ietf.org>; Thu, 29 May 2003 08:33:31 -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 IAA00834
	for <ipcdn@ietf.org>; Thu, 29 May 2003 08:33:28 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19LMZS-0006b0-00
	for ipcdn@ietf.org; Thu, 29 May 2003 08:31:50 -0400
Received: from desktop.terayon.com ([63.201.251.10] helo=SCBH02.terayon.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19LMZR-0006aG-00
	for ipcdn@ietf.org; Thu, 29 May 2003 08:31:49 -0400
Received: by scowa.terayon.com with Internet Mail Service (5.5.2656.59)
	id <LP0XSKRL>; Thu, 29 May 2003 05:32:56 -0700
Message-ID: <E54A98375651D511816A00306E06B970C4A382@OTNOAMEXCH01>
From: "Raftus, David" <david.raftus@Terayon.com>
To: "'Murwin William-LWM008'" <W.Murwin@motorola.com>,
        "'Woundy, Richard'"
	 <Richard_Woundy@cable.comcast.com>,
        "Raftus, David"
	 <david.raftus@Terayon.com>
Cc: "IPCDN (E-mail) (E-mail)" <ipcdn@ietf.org>,
        "Docsis Oss Reflector (E-mail)" <docsis-oss@cablelabs.com>,
        "Greg White (E-mail)" <g.white@cablelabs.com>,
        "Eduardo Cardona (E-mail)"
	 <e.cardona@cablelabs.com>
Subject: RE: [ipcdn] RE: "Optional" in the description of objects from the
	 rfmibv2
Date: Thu, 29 May 2003 05:32:41 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C325DE.65D7E140"
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_01C325DE.65D7E140
Content-Type: text/plain;
	charset="iso-8859-1"

Hi,
 
The suggestions to improve the efficiency and order of this mib are
definitely appreciated. Unfortunately we also need to consider that the
present mib is already supported by existing field Docsis implementations.
Is it really possible to move objects from one table to a new one at this
stage? 
 
It is too bad that folks from the IPCDN list can't review mib structure at
the same time changes are being debated functionally on other lists - in
this case it was Nov/Dec 2002 on the 2.0 and oss lists. I really don't know
how to balance the two views, except to have them done simultaneously. 
 
Very interested to hear opinions both on whether this mib structure can be
adjusted now, and how future mib development can accommodate both
syntactical and functional concerns at once.
 
Thanks,
Dave
 
************************************
David Raftus
Terayon Canada Ltd
340 Terry Fox Drive, Suite 202
Ottawa Canada  K2K 3A2
 
david.raftus@terayon.com           
613.592.1052  ext 222
************************************               
 
 
-----Original Message-----
From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com]
Sent: Wednesday, May 28, 2003 4:33 PM
To: 'Woundy, Richard'; 'Raftus, David'
Cc: IPCDN (E-mail) (E-mail)
Subject: RE: [ipcdn] RE: "Optional" in the description of objects from the
rfmibv2
 
Rich,
 
        You make a great point. 
        
        I was looking at it from a implementer point of view and saw the
manadtory group comment in the compliance statement. I.e. the reason for the
email.
        But now that I see it from your point of view, I agree if these
objects are truely "optional" then why must the agent support these objects.
I hinted to that in the earlier email,
        I guess I didn't raise the question because because I truely didn't
understand the context of "optional" in the description of these objects.
 
        Can I make a suggestion that a new table be created for the optional
objects that aguments the table with the manadtory objects so that 
        as user using an SNMP Manager does not have figure out the hard way
that some objects are "optional", if the CMTS does not support the optional
objects.
        And in the compliance statement for the CMTS this is clearly
explained.
 
Thanks,
Will Murwin
 
       
-----Original Message-----
From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com]
Sent: Wednesday, May 28, 2003 4:08 PM
To: 'Raftus, David'; Murwin William-LWM008
Cc: IPCDN (E-mail) (E-mail)
Subject: RE: [ipcdn] RE: "Optional" in the description of objects from the
rfmibv2
David and William,
 
I've been meaning to ask this for some time, but... what is the management
value of implementing objects if they don't report "valid" statistics?
Instead, why not make the objects completely optional for the CMTS (from a
specification point of view)?
 
If a management station receives a value of 0 for one of these objects as
specified now, it is not clear whether or not the CMTS is keeping track of
the actual value of the object.
 
If a management station receives a 'noSuchObject' indication, then it is
clear that the CMTS is not keeping track of the object's value. ;^)
 
-- Rich
-----Original Message-----
From: Raftus, David [mailto:david.raftus@imedia.com]
Sent: Monday, May 05, 2003 3:19 PM
To: 'Murwin William-LWM008'; Raftus, David
Cc: IPCDN (E-mail) (E-mail)
Subject: [ipcdn] RE: "Optional" in the description of objects from the
rfmibv2
Hi Will, 
Thanks for the note. It's always surprising to see how well intentioned
words can be seen in another light. As you state, the intent is mandatory
implementation of the objects, but optional counting of the statistics
represented by the objects. I will make your suggested changes in v7.
Thanks, 
Dave 
************************************ 
David Raftus 
Terayon Canada Ltd 
340 Terry Fox Drive, Suite 202 
Ottawa Canada  K2K 3A2 
david.raftus@terayon.com           
613.592.1052  ext 222 
************************************               
 
-----Original Message----- 
From: Murwin William-LWM008 [ mailto:W.Murwin@motorola.com
<mailto:W.Murwin@motorola.com> ] 
Sent: Monday, May 05, 2003 3:08 PM 
To: 'david.raftus@terayon.com' 
Cc: IPCDN (E-mail) (E-mail) 
Subject: "Optional" in the description of objects from the rfmibv2 
David, 
        I was reading the description for the following objects: 
docsIfCmtsUpChnlCtrCollCntnMslots             
docsIfCmtsUpChnlCtrTotalCntnReqMslots         
docsIfCmtsUpChnlCtrUsedCntnReqMslots          
docsIfCmtsUpChnlCtrCollCntnReqMslots          
docsIfCmtsUpChnlCtrTotalCntnReqDataMslots     
docsIfCmtsUpChnlCtrUsedCntnReqDataMslots      
docsIfCmtsUpChnlCtrCollCntnReqDataMslots      
docsIfCmtsUpChnlCtrTotalCntnInitMaintMslots   
docsIfCmtsUpChnlCtrUsedCntnInitMaintMslots    
docsIfCmtsUpChnlCtrCollCntnInitMaintMslots    
docsIfCmtsUpChnlCtrExtCollCntnMslots          
docsIfCmtsUpChnlCtrExtTotalCntnReqMslots      
docsIfCmtsUpChnlCtrExtUsedCntnReqMslots       
docsIfCmtsUpChnlCtrExtCollCntnReqMslots       
docsIfCmtsUpChnlCtrExtTotalCntnReqDataMslots  
docsIfCmtsUpChnlCtrExtUsedCntnReqDataMslots   
docsIfCmtsUpChnlCtrExtCollCntnReqDataMslots   
docsIfCmtsUpChnlCtrExtTotalCntnInitMaintMslots 
docsIfCmtsUpChnlCtrExtUsedCntnInitMaintMslots 
docsIfCmtsUpChnlCtrExtCollCntnInitMaintMslots 
All contain the following description: 
"...Support for this object is optional. If the object is not supported, a
value of zero is returned." 
Yet in the compliance statement these object belong to the docsIfCmtsGroupV2

Which is described as: 
-- conditionally mandatory group 
GROUP docsIfCmtsGroupV2 DESCRIPTION "This group is implemented only in Cable
Modem Termination Systems, not in Cable Modems."
This description with the key word "optional" is confusing! If these objects
are truly optional then they need not be implemented by the agent.
rfc2580: 
======================================================================= 
        3.  Mapping of the OBJECT-GROUP macro 
   For conformance purposes, it is useful to define a collection of 
   related managed objects.  The OBJECT-GROUP macro is used to define 
   each such collection of related objects.  It should be noted that the 
   expansion of the OBJECT-GROUP macro is something which conceptually 
   happens during implementation and not during run-time. 
   To "implement" an object, an agent must return a reasonably accurate 
   value for management protocol retrieval operations; similarly, if the 
   object is writable, then in response to a management protocol set 
   operation, an agent must accordingly be able to reasonably influence 
   the underlying managed entity.  If an agent can not implement an 
   object, the management protocol provides for it to return an 
   exception or error, e.g, noSuchObject [4].  Under no circumstances 
<----- NOTE 
   shall an agent return a value for objects which it does not implement 
<----- 
   -- it must always return the appropriate exception or error, as 
<------ 
   described in the protocol specification [4]. 
======================================================================== 
I believe your intent is for these objects to be implemented by a CMTS
agent, but not mandatory for the agent count these statistics.
I would remove the "optional" comment from the description of each of these
objects and change the text to read "If statistics are not maintained by the
agent, a value of zero is returned for this object."  or something to that
nature.
But what really is need is a change to the description for the
docsIfCmtsGroupV2, the comment above the group should be include in the
description. I would go as far as to say these objects are "mandatory" for a
CMTS agent, even though this is not a mandatory-group.
If I have mis-interrupted that these objects are not mandatory for the CMTS,
then a new optional group is needed for the CMTS, just for these objects.
>From the current descriptions, am just not sure which approach you where
trying to take. Any clarification is greatly appreciated.
Thanks, 
Will Murwin 
 
_____________________________ 
William Murwin 
Broadband Communications Sector 
Motorola Inc. 
Email: W.Murwin@motorola.com 
Tel: (508) 851-8385 

------_=_NextPart_001_01C325DE.65D7E140
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: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@01C325BC.E4FDE630">
<title>RE: &quot;Optional&quot; in the description of objects from the =
rfmibv2</title>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
 /* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0pt;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0pt;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p
	{margin-right:0pt;
	mso-margin-top-alt:auto;
	mso-margin-bottom-alt:auto;
	margin-left:0pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	mso-ansi-font-size:10.0pt;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
@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 link=3Dblue vlink=3Dblue =
style=3D'tab-interval:36.0pt'>

<div class=3DSection1>

<p class=3DMsoNormal><span class=3DEmailStyle18><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>H=
i,<o:p></o:p></span></font></span></p>

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


<p class=3DMsoNormal><span class=3DEmailStyle18><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>T=
he
suggestions to improve the efficiency and order of this mib are =
definitely
appreciated. Unfortunately we also need to consider that the present =
mib is
already supported by existing field Docsis implementations. Is it =
really
possible to move objects from one table to a new one at this stage? =
<o:p></o:p></span></font></span></p>

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


<p class=3DMsoNormal><span class=3DEmailStyle18><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>I=
t is too
bad that folks from the IPCDN list can't review mib structure at the =
same time
changes are being debated functionally on other lists - in this case it =
was
Nov/Dec 2002 on the 2.0 and oss lists. I really don't know how to =
balance the
two views, except to have them done simultaneously. =
<o:p></o:p></span></font></span></p>

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


<p class=3DMsoNormal><span class=3DEmailStyle18><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>V=
ery
interested to hear opinions both on whether this mib structure can be =
adjusted
now, and how future mib development can accommodate both syntactical =
and
functional concerns at once.<o:p></o:p></span></font></span></p>

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


<p class=3DMsoNormal><span class=3DEmailStyle18><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>T=
hanks,<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle18><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>D=
ave<o:p></o:p></span></font></span></p>

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


<p class=3DMsoNormal><!--[if supportFields]><span =
class=3DEmailStyle18><font=20
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial'><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></span></font></span><![end=
if]--><font
size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial;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;
font-family:Arial;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;
font-family:Arial;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;
font-family:Arial;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;
font-family:Arial;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;
font-family:Arial;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;
font-family:Arial;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;
font-family:Arial;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;
font-family:Arial;color:blue;font-style:italic'>************************=
************<span
style=3D"mso-spacerun: yes">&nbsp; </span></span></font></i><font =
size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;
font-family:Arial;color:navy'><span style=3D"mso-spacerun:
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;</span></span></font><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial;color:navy;mso-color-alt:windowtext'><o:p></o:p=
></span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><!--[if supportFields]><span =
class=3DEmailStyle18><font=20
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial'><span =
style=3D'mso-element:field-end'></span></span></font></span><![endif]-->=
<span
class=3DEmailStyle18><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DTahoma><span =
style=3D'font-size:
10.0pt;font-family:Tahoma;color:black'>-----Original Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Murwin =
William-LWM008
[mailto:W.Murwin@motorola.com]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, May 28, =
2003 4:33
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Woundy, Richard'; =
'Raftus,
David'<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> IPCDN (E-mail) =
(E-mail)<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: [ipcdn] RE:
&quot;Optional&quot; in the description of objects from the =
rfmibv2</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Rich,</span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>&nbsp;</span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>You make a great point. =
</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;</span></font><font
size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:blue'>&nbsp;</span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>I was looking at it from a implementer =
point of
view and saw the manadtory group comment in the compliance statement. =
I.e. the
reason for the email.</span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;</span></font><font
size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:blue'>But now that I see it from your point of view, I agree if =
these
objects are truely &quot;optional&quot; then why must the agent support =
these
objects.</span></font><font color=3Dblack><span =
style=3D'color:black'>&nbsp;</span></font><font
size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:blue'>I hinted to that in the earlier email,</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>I guess I didn't raise the question =
because
because I truely didn't understand the context of &quot;optional&quot; =
in the
description of these objects.</span></font><font color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>&nbsp;</span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>Can I make a suggestion that a new table =
be
created for the optional objects that aguments the table with the =
manadtory
objects so that </span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>&nbsp;&nbsp;&nbsp;</span></font><=
font
size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:blue'>&nbsp;&nbsp;&nbsp;&nbsp; as user using an SNMP Manager does =
not
have figure out the hard way that some objects are =
&quot;optional&quot;, if the
CMTS does not support the optional objects.</span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;
And in the compliance statement for the CMTS this is clearly =
explained.</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>&nbsp;</span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Thanks,</span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Will Murwin</span></font><font
color=3Dblack><span style=3D'color:black;mso-color-alt:windowtext'><o:p>=
</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>&nbsp;</span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;margin-bottom:12.0pt;
margin-left:36.0pt'><font size=3D2 color=3Dblack face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Woundy, Richard
[mailto:Richard_Woundy@cable.comcast.com]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, May 28, =
2003 4:08
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Raftus, David'; =
Murwin
William-LWM008<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> IPCDN (E-mail) =
(E-mail)<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: [ipcdn] RE:
&quot;Optional&quot; in the description of objects from the =
rfmibv2</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:36.0pt'><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>David and =
William,</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:36.0pt'><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>&nbsp;</span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:36.0pt'><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>I've been meaning to ask this for =
some
time, but... what is the management value of implementing objects if =
they don't
report &quot;valid&quot; statistics? Instead, why not make the objects
completely optional for the CMTS (from a specification point of =
view)?</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:36.0pt'><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>&nbsp;</span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:36.0pt'><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>If a management station receives a =
value
of 0 for one of these objects as specified now, it&nbsp;is not
clear&nbsp;whether or not the CMTS is&nbsp;keeping =
track&nbsp;of&nbsp;the
actual value of the object.</span></font><font color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:36.0pt'><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>&nbsp;</span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:36.0pt'><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>If a management station receives a
'noSuchObject' indication, then it is clear that the CMTS is not =
keeping track
of the object's value. ;^)</span></font><font color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:36.0pt'><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>&nbsp;</span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:36.0pt'><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>-- Rich</span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;margin-bottom:12.0pt;
margin-left:72.0pt'><font size=3D2 color=3Dblack face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>-----Original
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Raftus, David
[mailto:david.raftus@imedia.com]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, May 05, =
2003 3:19 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Murwin =
William-LWM008'; Raftus,
David<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> IPCDN (E-mail) =
(E-mail)<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> [ipcdn] RE:
&quot;Optional&quot; in the description of objects from the =
rfmibv2</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>Hi Will,</span></font><font =
color=3Dblack><span
style=3D'color:black'> </span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>Thanks for the note. It's always
surprising to see how well intentioned words can be seen in another =
light. As
you state, the intent is mandatory implementation of the objects, but =
optional
counting of the statistics represented by the objects. I will make your
suggested changes in v7.</span></font><font color=3Dblack><span =
style=3D'color:
black;mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>Thanks,</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Dave</span></font><font color=3Dblack><span =
style=3D'color:black'> </span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>*********************************=
***</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>David Raftus</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Terayon Canada Ltd</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>340 Terry Fox Drive, Suite 202</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Ottawa Canada&nbsp; K2K 3A2</span></font><font =
color=3Dblack><span
style=3D'color:black'> </span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>david.raftus@terayon.com&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>613.592.1052&nbsp; ext 222</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>************************************&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font><font color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:72.0pt'><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>-----Original =
Message-----</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>From: Murwin William-LWM008 [<a =
href=3D"mailto:W.Murwin@motorola.com">mailto:W.Murwin@motorola.com</a>]<=
/span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Sent: Monday, May 05, 2003 3:08 PM</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>To: 'david.raftus@terayon.com'</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Cc: IPCDN (E-mail) (E-mail)</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Subject: &quot;Optional&quot; in the description of =
objects from
the rfmibv2</span></font><font color=3Dblack><span =
style=3D'color:black'> </span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>David,</span></font><font =
color=3Dblack><span
style=3D'color:black'> </span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;
I was reading the description for the following =
objects:</span></font><font
color=3Dblack><span style=3D'color:black'> </span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>docsIfCmtsUpChnlCtrCollCntnMslots=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=

</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrTotalCntnReqMslots&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrUsedCntnReqMslots&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrCollCntnReqMslots&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrTotalCntnReqDataMslots&nbsp;&nbsp;&nbsp;=
&nbsp; </span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrUsedCntnReqDataMslots&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrCollCntnReqDataMslots&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrTotalCntnInitMaintMslots&nbsp;&nbsp; =
</span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrUsedCntnInitMaintMslots&nbsp;&nbsp;&nbsp=
; </span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrCollCntnInitMaintMslots&nbsp;&nbsp;&nbsp=
; </span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrExtCollCntnMslots&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrExtTotalCntnReqMslots&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrExtUsedCntnReqMslots&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrExtCollCntnReqMslots&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrExtTotalCntnReqDataMslots&nbsp; =
</span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrExtUsedCntnReqDataMslots&nbsp;&nbsp; =
</span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrExtCollCntnReqDataMslots&nbsp;&nbsp; =
</span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrExtTotalCntnInitMaintMslots</span></font=
><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrExtUsedCntnInitMaintMslots =
</span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>docsIfCmtsUpChnlCtrExtCollCntnInitMaintMslots</span></font>=
<font
color=3Dblack><span style=3D'color:black'> </span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>All contain the following =
description:</span></font><font
color=3Dblack><span style=3D'color:black'> </span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>&quot;...Support for this object =
is
optional. If the object is not supported, a value of zero is =
returned.&quot;</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Yet in the compliance statement these object belong to the
docsIfCmtsGroupV2</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Which is described as:</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>-- conditionally mandatory group</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>GROUP docsIfCmtsGroupV2 DESCRIPTION &quot;This group is
implemented only in Cable Modem Termination Systems, not in Cable =
Modems.&quot;</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>This description with the key =
word
&quot;optional&quot; is confusing! If these objects are truly optional =
then they
need not be implemented by the agent.</span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>rfc2580:</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>=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=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</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3.&nbsp; =
Mapping of the
OBJECT-GROUP macro</span></font><font color=3Dblack><span =
style=3D'color:black'> </span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>&nbsp;&nbsp; For conformance =
purposes, it
is useful to define a collection of</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp; related managed objects.&nbsp; The =
OBJECT-GROUP macro
is used to define</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp; each such collection of related =
objects.&nbsp; It
should be noted that the</span></font><font color=3Dblack><span =
style=3D'color:
black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp; expansion of the OBJECT-GROUP macro is =
something
which conceptually</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp; happens during implementation and not during =
run-time.</span></font><font
color=3Dblack><span style=3D'color:black'> </span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>&nbsp;&nbsp; To =
&quot;implement&quot; an
object, an agent must return a reasonably accurate</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp; value for management protocol retrieval =
operations;
similarly, if the</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp; object is writable, then in response to a =
management
protocol set</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp; operation, an agent must accordingly be able =
to
reasonably influence</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp; the underlying managed entity.&nbsp; If an =
agent can
not implement an</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp; object, the management protocol provides for =
it to
return an</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp; exception or error, e.g, noSuchObject =
[4].&nbsp;
Under no circumstances</span></font><font color=3Dblack><span =
style=3D'color:black'>
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&lt;----- NOTE</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp; shall an agent return a value for objects =
which it
does not implement</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&lt;-----</span></font><font color=3Dblack><span =
style=3D'color:black'>
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp; -- it must always return the appropriate =
exception or
error, as</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&lt;------</span></font><font color=3Dblack><span =
style=3D'color:black'>
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp; described in the protocol specification [4]. =
</span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>=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=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</span></font><font
color=3Dblack><span style=3D'color:black'> </span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>I believe your intent is for =
these objects
to be implemented by a CMTS agent, but not mandatory for the agent =
count these
statistics.</span></font><font color=3Dblack><span =
style=3D'color:black;mso-color-alt:
windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>I would remove the =
&quot;optional&quot;
comment from the description of each of these objects and change the =
text to
read &quot;If statistics are not maintained by the agent, a value of =
zero is
returned for this object.&quot;&nbsp; or something to that =
nature.</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>But what really is need is a =
change to the
description for the docsIfCmtsGroupV2, the comment above the group =
should be
include in the description. I would go as far as to say these objects =
are
&quot;mandatory&quot; for a CMTS agent, even though this is not a
mandatory-group.</span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>If I have mis-interrupted that =
these
objects are not mandatory for the CMTS, then a new optional group is =
needed for
the CMTS, just for these objects.</span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>From the current descriptions, =
am just not
sure which approach you where trying to take. Any clarification is =
greatly
appreciated.</span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>Thanks,</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Will Murwin</span></font><font color=3Dblack><span =
style=3D'color:
black'> </span></font><font color=3Dblack><span =
style=3D'color:black;mso-color-alt:
windowtext'><o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;margin-bottom:12.0pt;
margin-left:72.0pt'><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:72.0pt'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>_____________________________</sp=
an></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>William Murwin</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Broadband Communications Sector</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Motorola Inc.</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Email: W.Murwin@motorola.com</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Tel: (508) 851-8385</span></font><font color=3Dblack><span
style=3D'color:black'> </span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C325DE.65D7E140--
_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn



From mailnull@www1.ietf.org  Thu May 29 15:43:17 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 PAA16901
	for <ipcdn-archive@odin.ietf.org>; Thu, 29 May 2003 15:43:17 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4TJgnu16383
	for ipcdn-archive@odin.ietf.org; Thu, 29 May 2003 15:42: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 h4TJgHB16357;
	Thu, 29 May 2003 15:42: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 h4TJf4B16305
	for <ipcdn@optimus.ietf.org>; Thu, 29 May 2003 15:41:04 -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 PAA16828
	for <ipcdn@ietf.org>; Thu, 29 May 2003 15:41:02 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19LTFE-0001rq-00
	for ipcdn@ietf.org; Thu, 29 May 2003 15:39:24 -0400
Received: from ondar.cablelabs.com ([192.160.73.61])
	by ietf-mx with esmtp (Exim 4.12)
	id 19LTFD-0001rh-00
	for ipcdn@ietf.org; Thu, 29 May 2003 15:39:23 -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 h4TJeQnt025480;
	Thu, 29 May 2003 13:40:29 -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"
Subject: RE: [ipcdn] RE: "Optional" in the description of objects from the rfmibv2
Date: Thu, 29 May 2003 13:40:28 -0600
Message-ID: <E63E74E1F5391449BDFCAE1F352EC7DC01314A5D@srvxchg.cablelabs.com>
Thread-Topic: [ipcdn] RE: "Optional" in the description of objects from the rfmibv2
thread-index: AcMl3nExm/9FoxNWTaejBTbrfJtKDgABFCuA
From: "Eduardo Cardona" <e.cardona@CableLabs.com>
To: "Raftus, David" <david.raftus@Terayon.com>,
        "Murwin William-LWM008" <W.Murwin@motorola.com>,
        "Woundy, Richard" <Richard_Woundy@cable.comcast.com>
Cc: "IPCDN (E-mail) (E-mail)" <ipcdn@ietf.org>,
        "DOCSIS OSS Majordomo List" <docsis-oss@CableLabs.com>,
        "Greg White" <g.white@CableLabs.com>
X-Approved: ondar
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4TJf4B16306
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, 

I agree in making this objects truly OPTIONAL, 

The cleanest option I believe is the table extension as AUGMENTS as
William suggested, now two augment tables ? 32 and 64 ? Or just one ?

As today, an NMS should do two checks, Optional counters exists? Then 32
or 64 ?

From
http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines
-01.txt

"
Now that SNMPv3 is an Internet Standard and SNMPv1
is Historic (see http://www.rfc-editor.org/rfcxx00.html for status
and [RFC3410] for rationale) there is no reason to continue enforcing
this restriction.  Henceforth "standard" MIB modules MAY use the
Counter64 type when it makes sense to do so, and MUST use Counter64
if the information being modelled would wrap in less than one hour if
the Counter32 type was used instead.
"

so either, NoSuchObject or "0" are two indications of not support of the
counters for either implementation (truly OPTIONAL or OPTIONAL reporting
zero). The only meaningful information is "> 0"

If is the case of moving the optional counters as an extension table,
would it be OK just to port only the 64 Counters?
 
Probably a question for Rich as IETF co-chair, and MSOs out here to see
if still v1 is the core tool for CMTS operations with no getBulk. 

Either case, leaving the table truly optional (32 or 32/64) or splitting
in basic and extension,  there is no much difference in the snmp
toolkit.

Just my thoughts....

Eduardo 
 
-----Original Message-----
From: Raftus, David [mailto:david.raftus@Terayon.com] 
Sent: Thursday, May 29, 2003 6:33 AM
To: 'Murwin William-LWM008'; 'Woundy, Richard'; Raftus, David
Cc: IPCDN (E-mail) (E-mail); DOCSIS OSS Majordomo List; Greg White;
Eduardo Cardona
Subject: RE: [ipcdn] RE: "Optional" in the description of objects from
the rfmibv2


Hi,
 
The suggestions to improve the efficiency and order of this mib are
definitely appreciated. Unfortunately we also need to consider that the
present mib is already supported by existing field Docsis
implementations. Is it really possible to move objects from one table to
a new one at this stage? 
 
It is too bad that folks from the IPCDN list can't review mib structure
at the same time changes are being debated functionally on other lists -
in this case it was Nov/Dec 2002 on the 2.0 and oss lists. I really
don't know how to balance the two views, except to have them done
simultaneously. 
 
Very interested to hear opinions both on whether this mib structure can
be adjusted now, and how future mib development can accommodate both
syntactical and functional concerns at once.
 
Thanks,
Dave
 
************************************
David Raftus
Terayon Canada Ltd
340 Terry Fox Drive, Suite 202
Ottawa Canada  K2K 3A2
 
david.raftus@terayon.com           
613.592.1052  ext 222
************************************               
 
 
-----Original Message-----
From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com]
Sent: Wednesday, May 28, 2003 4:33 PM
To: 'Woundy, Richard'; 'Raftus, David'
Cc: IPCDN (E-mail) (E-mail)
Subject: RE: [ipcdn] RE: "Optional" in the description of objects from
the rfmibv2
 
Rich,
 
        You make a great point. 
        
        I was looking at it from a implementer point of view and saw the
manadtory group comment in the compliance statement. I.e. the reason for
the email.
        But now that I see it from your point of view, I agree if these
objects are truely "optional" then why must the agent support these
objects. I hinted to that in the earlier email,
        I guess I didn't raise the question because because I truely
didn't understand the context of "optional" in the description of these
objects.
 
        Can I make a suggestion that a new table be created for the
optional objects that aguments the table with the manadtory objects so
that 
        as user using an SNMP Manager does not have figure out the hard
way that some objects are "optional", if the CMTS does not support the
optional objects.
        And in the compliance statement for the CMTS this is clearly
explained.
 
Thanks,
Will Murwin
 
       
-----Original Message-----
From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com]
Sent: Wednesday, May 28, 2003 4:08 PM
To: 'Raftus, David'; Murwin William-LWM008
Cc: IPCDN (E-mail) (E-mail)
Subject: RE: [ipcdn] RE: "Optional" in the description of objects from
the rfmibv2
David and William,
 
I've been meaning to ask this for some time, but... what is the
management value of implementing objects if they don't report "valid"
statistics? Instead, why not make the objects completely optional for
the CMTS (from a specification point of view)?
 
If a management station receives a value of 0 for one of these objects
as specified now, it is not clear whether or not the CMTS is keeping
track of the actual value of the object.
 
If a management station receives a 'noSuchObject' indication, then it is
clear that the CMTS is not keeping track of the object's value. ;^)
 
-- Rich
-----Original Message-----
From: Raftus, David [mailto:david.raftus@imedia.com]
Sent: Monday, May 05, 2003 3:19 PM
To: 'Murwin William-LWM008'; Raftus, David
Cc: IPCDN (E-mail) (E-mail)
Subject: [ipcdn] RE: "Optional" in the description of objects from the
rfmibv2
Hi Will, 
Thanks for the note. It's always surprising to see how well intentioned
words can be seen in another light. As you state, the intent is
mandatory implementation of the objects, but optional counting of the
statistics represented by the objects. I will make your suggested
changes in v7.
Thanks, 
Dave 
************************************ 
David Raftus 
Terayon Canada Ltd 
340 Terry Fox Drive, Suite 202 
Ottawa Canada  K2K 3A2 
david.raftus@terayon.com           
613.592.1052  ext 222 
************************************               
 
-----Original Message----- 
From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com] 
Sent: Monday, May 05, 2003 3:08 PM 
To: 'david.raftus@terayon.com' 
Cc: IPCDN (E-mail) (E-mail) 
Subject: "Optional" in the description of objects from the rfmibv2 
David, 
        I was reading the description for the following objects: 
docsIfCmtsUpChnlCtrCollCntnMslots             
docsIfCmtsUpChnlCtrTotalCntnReqMslots         
docsIfCmtsUpChnlCtrUsedCntnReqMslots          
docsIfCmtsUpChnlCtrCollCntnReqMslots          
docsIfCmtsUpChnlCtrTotalCntnReqDataMslots     
docsIfCmtsUpChnlCtrUsedCntnReqDataMslots      
docsIfCmtsUpChnlCtrCollCntnReqDataMslots      
docsIfCmtsUpChnlCtrTotalCntnInitMaintMslots   
docsIfCmtsUpChnlCtrUsedCntnInitMaintMslots    
docsIfCmtsUpChnlCtrCollCntnInitMaintMslots    
docsIfCmtsUpChnlCtrExtCollCntnMslots          
docsIfCmtsUpChnlCtrExtTotalCntnReqMslots      
docsIfCmtsUpChnlCtrExtUsedCntnReqMslots       
docsIfCmtsUpChnlCtrExtCollCntnReqMslots       
docsIfCmtsUpChnlCtrExtTotalCntnReqDataMslots  
docsIfCmtsUpChnlCtrExtUsedCntnReqDataMslots   
docsIfCmtsUpChnlCtrExtCollCntnReqDataMslots   
docsIfCmtsUpChnlCtrExtTotalCntnInitMaintMslots 
docsIfCmtsUpChnlCtrExtUsedCntnInitMaintMslots 
docsIfCmtsUpChnlCtrExtCollCntnInitMaintMslots 
All contain the following description: 
"...Support for this object is optional. If the object is not supported,
a value of zero is returned." 
Yet in the compliance statement these object belong to the
docsIfCmtsGroupV2 
Which is described as: 
-- conditionally mandatory group 
GROUP docsIfCmtsGroupV2 DESCRIPTION "This group is implemented only in
Cable Modem Termination Systems, not in Cable Modems."
This description with the key word "optional" is confusing! If these
objects are truly optional then they need not be implemented by the
agent.
rfc2580: 
======================================================================= 
        3.  Mapping of the OBJECT-GROUP macro 
   For conformance purposes, it is useful to define a collection of 
   related managed objects.  The OBJECT-GROUP macro is used to define 
   each such collection of related objects.  It should be noted that the

   expansion of the OBJECT-GROUP macro is something which conceptually 
   happens during implementation and not during run-time. 
   To "implement" an object, an agent must return a reasonably accurate 
   value for management protocol retrieval operations; similarly, if the

   object is writable, then in response to a management protocol set 
   operation, an agent must accordingly be able to reasonably influence 
   the underlying managed entity.  If an agent can not implement an 
   object, the management protocol provides for it to return an 
   exception or error, e.g, noSuchObject [4].  Under no circumstances 
<----- NOTE 
   shall an agent return a value for objects which it does not implement

<----- 
   -- it must always return the appropriate exception or error, as 
<------ 
   described in the protocol specification [4]. 
========================================================================

I believe your intent is for these objects to be implemented by a CMTS
agent, but not mandatory for the agent count these statistics.
I would remove the "optional" comment from the description of each of
these objects and change the text to read "If statistics are not
maintained by the agent, a value of zero is returned for this object."
or something to that nature.
But what really is need is a change to the description for the
docsIfCmtsGroupV2, the comment above the group should be include in the
description. I would go as far as to say these objects are "mandatory"
for a CMTS agent, even though this is not a mandatory-group.
If I have mis-interrupted that these objects are not mandatory for the
CMTS, then a new optional group is needed for the CMTS, just for these
objects.
>From the current descriptions, am just not sure which approach you where
trying to take. Any clarification is greatly appreciated.
Thanks, 
Will Murwin 
 
_____________________________ 
William Murwin 
Broadband Communications Sector 
Motorola Inc. 
Email: W.Murwin@motorola.com 
Tel: (508) 851-8385 
_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn



From mailnull@www1.ietf.org  Thu May 29 19:34: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 TAA27377
	for <ipcdn-archive@odin.ietf.org>; Thu, 29 May 2003 19:34:49 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4TNYNj32286
	for ipcdn-archive@odin.ietf.org; Thu, 29 May 2003 19:34: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 h4TNYJB32278;
	Thu, 29 May 2003 19:34:19 -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 h4TIUeB10861
	for <ipcdn@optimus.ietf.org>; Thu, 29 May 2003 14:30:40 -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 OAA13299
	for <ipcdn@ietf.org>; Thu, 29 May 2003 14:30:34 -0400 (EDT)
From: David.White@ARRISI.COM
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19LS92-0001Ob-00
	for ipcdn@ietf.org; Thu, 29 May 2003 14:28:56 -0400
Received: from pluto.arrisi.com ([63.82.122.6])
	by ietf-mx with esmtp (Exim 4.12)
	id 19LS92-0001OY-00
	for ipcdn@ietf.org; Thu, 29 May 2003 14:28:56 -0400
Received: from mars.ARRISI.COM ([10.0.248.10])
          by pluto.arrisi.com (Lotus Domino Release 5.0.12)
          with ESMTP id 2003052914352939:41387 ;
          Thu, 29 May 2003 14:35:29 -0400 
To: Wilson.Sawyer@ARRISI.COM
Cc: bwijnen@lucent.com, ipcdn@ietf.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.12   February 13, 2003
Message-ID: <OFD1EE967F.2E64D917-ON85256D35.0065A509-85256D35.0065AD0B@ARRISI.COM>
Date: Thu, 29 May 2003 14:30:34 -0400
X-MIMETrack: Serialize by Router on Mars/Arris(Release 5.0.11  |July 24, 2002) at 05/29/2003
 02:30:34 PM,
	Serialize complete at 05/29/2003 02:30:34 PM,
	Itemize by SMTP Server on Pluto/Antec(Release 5.0.12  |February 13, 2003) at
 05/29/2003 02:35:29 PM,
	Serialize by Router on Pluto/Antec(Release 5.0.12  |February 13, 2003) at
 05/29/2003 02:35:30 PM,
	Serialize complete at 05/29/2003 02:35:30 PM
Content-Type: multipart/alternative; boundary="=_alternative 0065AD0A85256D35_="
Subject: [ipcdn] Re: draft submitted: subscriber management MIB -11
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 0065AD0A85256D35_=
Content-Type: text/plain; charset="us-ascii"

Where can I find a copy of this ?

Thanks,
David





Wilson Sawyer
05/29/2003 08:22 AM

 
        To:     ipcdn@ietf.org
        cc:     bwijnen@lucent.com, (bcc: David White/Arris)
        Subject:        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


--=_alternative 0065AD0A85256D35_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Where can I find a copy of this ?</font>
<br>
<br><font size=2 face="sans-serif">Thanks,</font>
<br><font size=2 face="sans-serif">David</font>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>Wilson Sawyer</b></font>
<p><font size=1 face="sans-serif">05/29/2003 08:22 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;ipcdn@ietf.org</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;bwijnen@lucent.com, (bcc: David White/Arris)</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;draft submitted: subscriber management MIB -11</font></table>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">Respectfully submitted,</font>
<br><font size=2 face="sans-serif">Wilson Sawyer</font>
<br><font size=2 face="sans-serif">ARRIS</font>
<br>
<br>
--=_alternative 0065AD0A85256D35_=--
_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn



From mailnull@www1.ietf.org  Fri May 30 07:20:35 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 HAA28856
	for <ipcdn-archive@odin.ietf.org>; Fri, 30 May 2003 07:20:35 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4UBK6P25166
	for ipcdn-archive@odin.ietf.org; Fri, 30 May 2003 07:20:06 -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 h4UBJrB25072;
	Fri, 30 May 2003 07:19:53 -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 h4UBEtB24802
	for <ipcdn@optimus.ietf.org>; Fri, 30 May 2003 07:14:55 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28379;
	Fri, 30 May 2003 07:14:52 -0400 (EDT)
Message-Id: <200305301114.HAA28379@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: Fri, 30 May 2003 07:14:51 -0400
Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-subscriber-mib-11.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		: Management Information Base for Data Over Cable 
                          Service Interface Specification (DOCSIS) Cable Modem 
                          Termination Systems for Subscriber Management
	Author(s)	: W. Sawyer
	Filename	: draft-ietf-ipcdn-subscriber-mib-11.txt
	Pages		: 20
	Date		: 2003-5-29
	
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 set of managed objects for SNMP-based
management of Data-over-Cable Service Interface Specification
(DOCSIS)-compliant Cable Modem Termination Systems. These managed
objects facilitate protection of the cable network from misuse by
subscribers.
This memo is a product of the IPCDN working group within the Internet
Engineering Task Force.  Comments are solicited and should be
addressed to the working group's mailing list at ipcdn@ietf.org
and/or the author.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-subscriber-mib-11.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-subscriber-mib-11.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-subscriber-mib-11.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-5-29161638.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipcdn-subscriber-mib-11.txt

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

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

--OtherAccess--

--NextPart--


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



From mailnull@www1.ietf.org  Fri May 30 16:03:05 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 QAA25552
	for <ipcdn-archive@odin.ietf.org>; Fri, 30 May 2003 16:03:05 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4UK2b800360
	for ipcdn-archive@odin.ietf.org; Fri, 30 May 2003 16:02:37 -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 h4UK2AB00330;
	Fri, 30 May 2003 16:02: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 h4UK0bB32668
	for <ipcdn@optimus.ietf.org>; Fri, 30 May 2003 16:00: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 QAA25446
	for <ipcdn@ietf.org>; Fri, 30 May 2003 16:00:35 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Lq1f-0000pO-00
	for ipcdn@ietf.org; Fri, 30 May 2003 15:58:55 -0400
Received: from coral.tci.com ([198.178.8.81] helo=peacock.tci.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Lq1d-0000pK-00
	for ipcdn@ietf.org; Fri, 30 May 2003 15:58:53 -0400
Received: from mms01-relaya.tci.com (mms01-relaya.broadband.att.com [147.191.90.228])
	by peacock.tci.com (8.12.9/8.12.9) with ESMTP id h4UJxbtq013382;
	Fri, 30 May 2003 14:00:02 -0600 (MDT)
Received: from 147.191.89.203 by mms01-relaya.tci.com with ESMTP (
 Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Fri, 30 May 2003 13:59:59
 -0600
Received: by entexchimc01.broadband.att.com with Internet Mail Service (
 5.5.2653.19) id <J5B9XKHR>; Fri, 30 May 2003 13:59:59 -0600
Message-ID: <6732623D2548D61193C90002A5C88DCC05663AF6@entmaexch02.broadband.att.com>
From: "Woundy, Richard" <Richard_Woundy@cable.comcast.com>
To: "'Raftus, David'" <david.raftus@terayon.com>,
        "'Murwin William-LWM008'" <W.Murwin@motorola.com>
cc: "IPCDN (E-mail) (E-mail)" <ipcdn@ietf.org>
Subject: RE: [ipcdn] RE: "Optional" in the description of objects from
 the rfmibv2
Date: Fri, 30 May 2003 13:59:56 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-WSS-ID: 12C967B55375128-01-01
Content-Type: multipart/alternative;
 boundary="----_=_NextPart_001_01C326E6.0ADF8460"
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_01C326E6.0ADF8460
Content-Type: text/plain;
 charset=iso-8859-1
Content-Transfer-Encoding: 7bit

David,
 
Looking at the RFCs, I don't see the same restriction -- that is, i see no
guidance to force an agent to implement all (or none) of the columns of a
conceptual table.
 
In fact, I found a relevant counter-example: ifXTable in the Interfaces
Group MIB (RFC 2863). This table includes ifName and ifHCInOctets, among
other objects. ifName belongs to the ifGeneralInformationGroup conformance
group (which is mandatory to implement in all conforming implementations),
and ifHCInOctets belongs to the ifHCFixedLengthGroup and ifHCPacketGroup
(which are only conditionally mandatory). A conforming agent with only low
speed interfaces must implement the ifName column but not the ifHCInOctets
column.
 
Going further, you might consider the following section from RFC 2863:
 
3.1.18.  All Values Must be Known
 
   There are a number of situations where an agent does not know the
   value of one or more objects for a particular interface.  In all such
   circumstances, an agent MUST NOT instantiate an object with an
   incorrect value; rather, it MUST respond with the appropriate
   error/exception condition (e.g., noSuchInstance or noSuchName).
 
   One example is where an agent is unable to count the occurrences
   defined by one (or more) of the ifTable counters.  In this
   circumstance, the agent MUST NOT instantiate the particular counter
   with a value of, say, zero.  To do so would be to provide mis-
   information to a network management application reading the zero
   value, and thereby assuming that there have been no occurrences of
   the event (e.g., no input errors because ifInErrors is always zero).
 
   Sometimes the lack of knowledge of an object's value is temporary.
   For example, when the MTU of an interface is a configured value and a
   device dynamically learns the configured value through (after)
   exchanging messages over the interface (e.g., ATM LAN-Emulation
   [20]).  In such a case, the value is not known until after the
   ifTable entry has already been created.  In such a case, the ifTable
   entry should be created without an instance of the object whose value
   is unknown; later, when the value becomes known, the missing object
   can then be instantiated (e.g., the instance of ifMtu is only
   instantiated once the interface's MTU becomes known).
 
   As a result of this "known values" rule, management applications MUST
   be able to cope with the responses to retrieving the object instances
   within a conceptual row of the ifTable revealing that some of the
   row's columnar objects are missing/not available.
 
So, wouldn't we only need to change the MIB conformance statements/groups???
 
-- Rich
-----Original Message-----
From: Raftus, David [mailto:david.raftus@terayon.com]
Sent: Wednesday, May 28, 2003 4:28 PM
To: Woundy, Richard; Raftus, David; 'Murwin William-LWM008'
Cc: IPCDN (E-mail) (E-mail)
Subject: RE: [ipcdn] RE: "Optional" in the description of objects from the
rfmibv2


Rich,
 
It has been my laymen's understanding of snmp that objects in a table must
all be present - ie can't pick and choose individual tabular objects to
appear in a mib walk. Perhaps I am incorrect in this understanding. There
does seem to be precedent for assigning a value of zero to tabular objects
that are present, but not functionally supported.
 
Dave
 
************************************
David Raftus
Terayon Canada Ltd
340 Terry Fox Drive, Suite 202
Ottawa Canada  K2K 3A2
 
david.raftus@terayon.com           
613.592.1052  ext 222
************************************               
 
 
-----Original Message-----
From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com]
Sent: Wednesday, May 28, 2003 4:08 PM
To: 'Raftus, David'; 'Murwin William-LWM008'
Cc: IPCDN (E-mail) (E-mail)
Subject: RE: [ipcdn] RE: "Optional" in the description of objects from the
rfmibv2
 
David and William,
 
I've been meaning to ask this for some time, but... what is the management
value of implementing objects if they don't report "valid" statistics?
Instead, why not make the objects completely optional for the CMTS (from a
specification point of view)?
 
If a management station receives a value of 0 for one of these objects as
specified now, it is not clear whether or not the CMTS is keeping track of
the actual value of the object.
 
If a management station receives a 'noSuchObject' indication, then it is
clear that the CMTS is not keeping track of the object's value. ;^)
 
-- Rich
-----Original Message-----
From: Raftus, David [mailto:david.raftus@imedia.com]
Sent: Monday, May 05, 2003 3:19 PM
To: 'Murwin William-LWM008'; Raftus, David
Cc: IPCDN (E-mail) (E-mail)
Subject: [ipcdn] RE: "Optional" in the description of objects from the
rfmibv2
Hi Will, 
Thanks for the note. It's always surprising to see how well intentioned
words can be seen in another light. As you state, the intent is mandatory
implementation of the objects, but optional counting of the statistics
represented by the objects. I will make your suggested changes in v7.
Thanks, 
Dave 
************************************ 
David Raftus 
Terayon Canada Ltd 
340 Terry Fox Drive, Suite 202 
Ottawa Canada  K2K 3A2 
david.raftus@terayon.com           
613.592.1052  ext 222 
************************************               
 
-----Original Message----- 
From: Murwin William-LWM008 [ mailto:W.Murwin@motorola.com
<mailto:W.Murwin@motorola.com> ] 
Sent: Monday, May 05, 2003 3:08 PM 
To: 'david.raftus@terayon.com' 
Cc: IPCDN (E-mail) (E-mail) 
Subject: "Optional" in the description of objects from the rfmibv2 
David, 
        I was reading the description for the following objects: 
docsIfCmtsUpChnlCtrCollCntnMslots             
docsIfCmtsUpChnlCtrTotalCntnReqMslots         
docsIfCmtsUpChnlCtrUsedCntnReqMslots          
docsIfCmtsUpChnlCtrCollCntnReqMslots          
docsIfCmtsUpChnlCtrTotalCntnReqDataMslots     
docsIfCmtsUpChnlCtrUsedCntnReqDataMslots      
docsIfCmtsUpChnlCtrCollCntnReqDataMslots      
docsIfCmtsUpChnlCtrTotalCntnInitMaintMslots   
docsIfCmtsUpChnlCtrUsedCntnInitMaintMslots    
docsIfCmtsUpChnlCtrCollCntnInitMaintMslots    
docsIfCmtsUpChnlCtrExtCollCntnMslots          
docsIfCmtsUpChnlCtrExtTotalCntnReqMslots      
docsIfCmtsUpChnlCtrExtUsedCntnReqMslots       
docsIfCmtsUpChnlCtrExtCollCntnReqMslots       
docsIfCmtsUpChnlCtrExtTotalCntnReqDataMslots  
docsIfCmtsUpChnlCtrExtUsedCntnReqDataMslots   
docsIfCmtsUpChnlCtrExtCollCntnReqDataMslots   
docsIfCmtsUpChnlCtrExtTotalCntnInitMaintMslots 
docsIfCmtsUpChnlCtrExtUsedCntnInitMaintMslots 
docsIfCmtsUpChnlCtrExtCollCntnInitMaintMslots 
All contain the following description: 
"...Support for this object is optional. If the object is not supported, a
value of zero is returned." 
Yet in the compliance statement these object belong to the docsIfCmtsGroupV2

Which is described as: 
-- conditionally mandatory group 
GROUP docsIfCmtsGroupV2 DESCRIPTION "This group is implemented only in Cable
Modem Termination Systems, not in Cable Modems."
This description with the key word "optional" is confusing! If these objects
are truly optional then they need not be implemented by the agent.
rfc2580: 
======================================================================= 
        3.  Mapping of the OBJECT-GROUP macro 
   For conformance purposes, it is useful to define a collection of 
   related managed objects.  The OBJECT-GROUP macro is used to define 
   each such collection of related objects.  It should be noted that the 
   expansion of the OBJECT-GROUP macro is something which conceptually 
   happens during implementation and not during run-time. 
   To "implement" an object, an agent must return a reasonably accurate 
   value for management protocol retrieval operations; similarly, if the 
   object is writable, then in response to a management protocol set 
   operation, an agent must accordingly be able to reasonably influence 
   the underlying managed entity.  If an agent can not implement an 
   object, the management protocol provides for it to return an 
   exception or error, e.g, noSuchObject [4].  Under no circumstances 
<----- NOTE 
   shall an agent return a value for objects which it does not implement 
<----- 
   -- it must always return the appropriate exception or error, as 
<------ 
   described in the protocol specification [4]. 
======================================================================== 
I believe your intent is for these objects to be implemented by a CMTS
agent, but not mandatory for the agent count these statistics.
I would remove the "optional" comment from the description of each of these
objects and change the text to read "If statistics are not maintained by the
agent, a value of zero is returned for this object."  or something to that
nature.
But what really is need is a change to the description for the
docsIfCmtsGroupV2, the comment above the group should be include in the
description. I would go as far as to say these objects are "mandatory" for a
CMTS agent, even though this is not a mandatory-group.
If I have mis-interrupted that these objects are not mandatory for the CMTS,
then a new optional group is needed for the CMTS, just for these objects.
>From the current descriptions, am just not sure which approach you where
trying to take. Any clarification is greatly appreciated.
Thanks, 
Will Murwin 
 
_____________________________ 
William Murwin 
Broadband Communications Sector 
Motorola Inc. 
Email: W.Murwin@motorola.com 
Tel: (508) 851-8385 

------_=_NextPart_001_01C326E6.0ADF8460
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">
<TITLE>RE: "Optional" in the description of objects from the =
rfmibv2</TITLE>

<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@01C32536.11DD66D0" rel=3DFile-List><!--[if gte =
mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<STYLE>@font-face {
	font-family: Tahoma;
}
@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: 12pt; MARGIN: 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
}
A:visited {
	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
}
SPAN.MsoHyperlinkFollowed {
	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
}
P.MsoAutoSig {
	FONT-SIZE: 12pt; MARGIN: 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"
}
LI.MsoAutoSig {
	FONT-SIZE: 12pt; MARGIN: 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"
}
DIV.MsoAutoSig {
	FONT-SIZE: 12pt; MARGIN: 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"
}
P {
	FONT-SIZE: 12pt; MARGIN-LEFT: 0pt; MARGIN-RIGHT: 0pt; FONT-FAMILY: =
"Times New Roman"; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; mso-margin-top-alt: auto; =
mso-margin-bottom-alt: auto
}
SPAN.EmailStyle18 {
	COLOR: navy; mso-style-type: personal-reply; 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" vLink=3Dblue =
link=3Dblue>
<DIV><SPAN class=3D856162211-30052003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>David,</FONT></SPAN></DIV>
<DIV><SPAN class=3D856162211-30052003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D856162211-30052003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Looking at the RFCs, I don't see the same restriction&nbsp;-- =
that=20
is,&nbsp;i see no guidance to&nbsp;force an agent&nbsp;to implement all =
(or=20
none) of the columns of a conceptual table.</FONT></SPAN></DIV>
<DIV><SPAN class=3D856162211-30052003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D856162211-30052003><FONT face=3DArial =
color=3D#0000ff size=3D2>In=20
fact, I found a relevant counter-example: ifXTable in the Interfaces =
Group MIB=20
(RFC 2863). This table includes ifName and ifHCInOctets, among other =
objects.=20
ifName belongs to the ifGeneralInformationGroup conformance group =
(which is=20
mandatory to implement in all conforming implementations), and =
ifHCInOctets=20
belongs to the ifHCFixedLengthGroup and ifHCPacketGroup (which are only =

conditionally mandatory). A conforming agent with only low speed =
interfaces must=20
implement the ifName column but not the ifHCInOctets =
column.</FONT></SPAN></DIV>
<DIV><SPAN class=3D856162211-30052003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D856162211-30052003><FONT face=3DArial =
color=3D#0000ff size=3D2>Going=20
further, you might consider the following section from RFC=20
2863:</FONT></SPAN></DIV>
<DIV><SPAN class=3D856162211-30052003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D856162211-30052003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>3.1.18.&nbsp; All Values Must be Known</FONT></SPAN></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D856162211-30052003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>&nbsp;&nbsp; There are a number of situations where an agent =
does not=20
know the<BR>&nbsp;&nbsp; value of one or more objects for a particular=20
interface.&nbsp; In all such<BR>&nbsp;&nbsp; circumstances, an agent =
MUST NOT=20
instantiate an object with an<BR>&nbsp;&nbsp; incorrect value; rather, =
it MUST=20
respond with the appropriate<BR>&nbsp;&nbsp; error/exception condition =
(e.g.,=20
noSuchInstance or noSuchName).</FONT></SPAN></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D856162211-30052003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>&nbsp;&nbsp; One example is where an agent is unable to count =
the=20
occurrences<BR>&nbsp;&nbsp; defined by one (or more) of the ifTable=20
counters.&nbsp; In this<BR>&nbsp;&nbsp; circumstance, the agent MUST =
NOT=20
instantiate the particular counter<BR>&nbsp;&nbsp; with a value of, =
say,=20
zero.&nbsp; To do so would be to provide mis-<BR>&nbsp;&nbsp; =
information to a=20
network management application reading the zero<BR>&nbsp;&nbsp; value, =
and=20
thereby assuming that there have been no occurrences of<BR>&nbsp;&nbsp; =
the=20
event (e.g., no input errors because ifInErrors is always=20
zero).</FONT></SPAN></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D856162211-30052003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>&nbsp;&nbsp; Sometimes the lack of knowledge of an object's =
value is=20
temporary.<BR>&nbsp;&nbsp; For example, when the MTU of an interface is =
a=20
configured value and a<BR>&nbsp;&nbsp; device dynamically learns the =
configured=20
value through (after)<BR>&nbsp;&nbsp; exchanging messages over the =
interface=20
(e.g., ATM LAN-Emulation<BR>&nbsp;&nbsp; [20]).&nbsp; In such a case, =
the value=20
is not known until after the<BR>&nbsp;&nbsp; ifTable entry has already =
been=20
created.&nbsp; In such a case, the ifTable<BR>&nbsp;&nbsp; entry should =
be=20
created without an instance of the object whose value<BR>&nbsp;&nbsp; =
is=20
unknown; later, when the value becomes known, the missing =
object<BR>&nbsp;&nbsp;=20
can then be instantiated (e.g., the instance of ifMtu is =
only<BR>&nbsp;&nbsp;=20
instantiated once the interface's MTU becomes =
known).</FONT></SPAN></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D856162211-30052003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>&nbsp;&nbsp; As a result of this "known values" rule, =
management=20
applications MUST<BR>&nbsp;&nbsp; be able to cope with the responses to =

retrieving the object instances<BR>&nbsp;&nbsp; within a conceptual row =
of the=20
ifTable revealing that some of the<BR>&nbsp;&nbsp; row's columnar =
objects are=20
missing/not available.</FONT></SPAN></DIV>
<DIV><SPAN class=3D856162211-30052003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D856162211-30052003><FONT face=3DArial =
color=3D#0000ff size=3D2>So,=20
wouldn't we only need to change the MIB conformance=20
statements/groups???</FONT></SPAN></DIV>
<DIV><SPAN class=3D856162211-30052003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D856162211-30052003><FONT face=3DArial =
color=3D#0000ff size=3D2>--=20
Rich</FONT></SPAN></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> Wednesday, May 28, =
2003 4:28=20
  PM<BR><B>To:</B> Woundy, Richard; Raftus, David; 'Murwin=20
  William-LWM008'<BR><B>Cc:</B> IPCDN (E-mail) =
(E-mail)<BR><B>Subject:</B> RE:=20
  [ipcdn] RE: "Optional" in the description of objects from the=20
  rfmibv2<BR><BR></FONT></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><SPAN class=3DEmailStyle18><FONT face=3DArial =
color=3Dnavy=20
  size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-bidi-font-size: =
12.0pt">Rich,<o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=3DMsoNormal><SPAN class=3DEmailStyle18><FONT face=3DArial =
color=3Dnavy=20
  size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-bidi-font-size: =
12.0pt"><![if =
!supportEmptyParas]><![endif]>&nbsp;<o:p></o:p></SPAN></FONT></SPAN></P>=

  <P class=3DMsoNormal><SPAN class=3DEmailStyle18><FONT face=3DArial =
color=3Dnavy=20
  size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-bidi-font-size: =
12.0pt">It has=20
  been my laymen's understanding of snmp that objects in a table must =
all be=20
  present - ie can't pick and choose individual tabular objects to =
appear in a=20
  mib walk. Perhaps I am incorrect in this understanding. There does =
seem to be=20
  precedent for assigning a value of zero to tabular objects that are =
present,=20
  but not functionally supported.<o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=3DMsoNormal><SPAN class=3DEmailStyle18><FONT face=3DArial =
color=3Dnavy=20
  size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-bidi-font-size: =
12.0pt"><![if =
!supportEmptyParas]><![endif]>&nbsp;<o:p></o:p></SPAN></FONT></SPAN></P>=

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

  <P class=3DMsoNormal><!--[if supportFields]><span =
class=3DEmailStyle18><font=20
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial'><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></span></font></span><![end=
if]--><FONT=20
  face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial; =
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; =
FONT-FAMILY: Arial; 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; =
FONT-FAMILY: Arial; 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; =
FONT-FAMILY: Arial; 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; =
FONT-FAMILY: Arial; 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; =
FONT-FAMILY: Arial; 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; =
FONT-FAMILY: Arial; 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; =
FONT-FAMILY: Arial; 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; =
FONT-FAMILY: Arial; mso-bidi-font-size: =
12.0pt">************************************<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN></SPAN></FONT></I><FONT =
face=3DArial=20
  color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial; =
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></SPAN></FONT><FONT=20
  face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial; =
mso-bidi-font-size: 12.0pt; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dnavy =
size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt; COLOR: navy"><![if =
!supportEmptyParas]><![endif]>&nbsp;</SPAN></FONT><FONT=20
  color=3Dnavy><SPAN=20
  style=3D"COLOR: navy; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><!--[if supportFields]><span =
class=3DEmailStyle18><font=20
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial'><span =
style=3D'mso-element:field-end'></span></span></font></span><![endif]-->=
<SPAN=20
  class=3DEmailStyle18><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-bidi-font-size: =
12.0pt"><![if =
!supportEmptyParas]><![endif]>&nbsp;<o:p></o:p></SPAN></FONT></SPAN></P>=

  <P class=3DMsoNormal><FONT face=3DTahoma color=3Dblack size=3D2><SPAN =

  style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: =
Tahoma">-----Original=20
  Message-----<BR><B><SPAN style=3D"FONT-WEIGHT: bold">From:</SPAN></B> =
Woundy,=20
  Richard [mailto:Richard_Woundy@cable.comcast.com]<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Wednesday, May 28, 2003 =
4:08=20
  PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> 'Raftus, =
David';=20
  'Murwin William-LWM008'<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Cc:</SPAN></B>=20
  IPCDN (E-mail) (E-mail)<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> RE: [ipcdn] RE: =
"Optional" in=20
  the description of objects from the rfmibv2</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt"><![if =
!supportEmptyParas]><![endif]>&nbsp;<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">David and=20
  William,</SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt; COLOR: black">&nbsp;</SPAN></FONT><FONT=20
  color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">I've been =
meaning to=20
  ask this for some time, but... what is the management value of =
implementing=20
  objects if they don't report "valid" statistics? Instead, why not =
make the=20
  objects completely optional for the CMTS (from a specification point =
of=20
  view)?</SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt; COLOR: black">&nbsp;</SPAN></FONT><FONT=20
  color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">If a =
management=20
  station receives a value of 0 for one of these objects as specified =
now,=20
  it&nbsp;is not clear&nbsp;whether or not the CMTS is&nbsp;keeping=20
  track&nbsp;of&nbsp;the actual value of the object.</SPAN></FONT><FONT =

  color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt; COLOR: black">&nbsp;</SPAN></FONT><FONT=20
  color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">If a =
management=20
  station receives a 'noSuchObject' indication, then it is clear that =
the CMTS=20
  is not keeping track of the object's value. ;^)</SPAN></FONT><FONT=20
  color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt; COLOR: black">&nbsp;</SPAN></FONT><FONT=20
  color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">--=20
  Rich</SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal=20
  style=3D"MARGIN-BOTTOM: 12pt; MARGIN-LEFT: 36pt; mso-margin-top-alt: =
auto"><FONT=20
  face=3DTahoma color=3Dblack size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: =
Tahoma">-----Original=20
  Message-----<BR><B><SPAN style=3D"FONT-WEIGHT: bold">From:</SPAN></B> =
Raftus,=20
  David [mailto:david.raftus@imedia.com]<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Monday, May 05, 2003 =
3:19=20
  PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> 'Murwin=20
  William-LWM008'; Raftus, David<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Cc:</SPAN></B> IPCDN (E-mail) =
(E-mail)<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> [ipcdn] RE: =
"Optional" in the=20
  description of objects from the rfmibv2</SPAN></FONT><FONT =
color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P style=3D"MARGIN-LEFT: 36pt"><FONT face=3D"Times New Roman" =
color=3Dblack=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: black">Hi =
Will,</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> </SPAN></FONT><FONT =
color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P style=3D"MARGIN-LEFT: 36pt"><FONT face=3D"Times New Roman" =
color=3Dblack=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: black">Thanks for the =
note. It's=20
  always surprising to see how well intentioned words can be seen in =
another=20
  light. As you state, the intent is mandatory implementation of the =
objects,=20
  but optional counting of the statistics represented by the objects. I =
will=20
  make your suggested changes in v7.</SPAN></FONT><FONT =
color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P style=3D"MARGIN-LEFT: 36pt"><FONT face=3D"Times New Roman" =
color=3Dblack=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: =
black">Thanks,</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> <BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: =
black">Dave</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> </SPAN></FONT><FONT =
color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P style=3D"MARGIN-LEFT: 36pt"><FONT face=3D"Times New Roman" =
color=3Dblack=20
  size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: =
black">************************************</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> <BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: black">David=20
  Raftus</SPAN></FONT><FONT color=3Dblack><SPAN style=3D"COLOR: black"> =

  <BR></SPAN></FONT><FONT color=3Dblack size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black">Terayon Canada =
Ltd</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> <BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: black">340 Terry Fox =
Drive, Suite=20
  202</SPAN></FONT><FONT color=3Dblack><SPAN style=3D"COLOR: black">=20
  <BR></SPAN></FONT><FONT color=3Dblack size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black">Ottawa Canada&nbsp; K2K=20
  3A2</SPAN></FONT><FONT color=3Dblack><SPAN style=3D"COLOR: black">=20
  </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P style=3D"MARGIN-LEFT: 36pt"><FONT face=3D"Times New Roman" =
color=3Dblack=20
  size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: =
black">david.raftus@terayon.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black">613.592.1052&nbsp; ext=20
  222</SPAN></FONT><FONT color=3Dblack><SPAN style=3D"COLOR: black">=20
  <BR></SPAN></FONT><FONT color=3Dblack size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: =
black">************************************&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal=20
  style=3D"MARGIN-LEFT: 36pt; mso-margin-top-alt: auto; =
mso-margin-bottom-alt: auto"><FONT=20
  face=3D"Times New Roman" color=3Dblack size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt; COLOR: black"><![if =
!supportEmptyParas]><![endif]>&nbsp;</SPAN></FONT><FONT=20
  color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P style=3D"MARGIN-LEFT: 36pt"><FONT face=3D"Times New Roman" =
color=3Dblack=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: black">-----Original=20
  Message-----</SPAN></FONT><FONT color=3Dblack><SPAN style=3D"COLOR: =
black">=20
  <BR></SPAN></FONT><FONT color=3Dblack size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black">From: Murwin William-LWM008 =
[<A=20
  =
href=3D"mailto:W.Murwin@motorola.com">mailto:W.Murwin@motorola.com</A>]<=
/SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> <BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: black">Sent: Monday, =
May 05, 2003=20
  3:08 PM</SPAN></FONT><FONT color=3Dblack><SPAN style=3D"COLOR: =
black">=20
  <BR></SPAN></FONT><FONT color=3Dblack size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black">To:=20
  'david.raftus@terayon.com'</SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"> <BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black">Cc: IPCDN (E-mail)=20
  (E-mail)</SPAN></FONT><FONT color=3Dblack><SPAN style=3D"COLOR: =
black">=20
  <BR></SPAN></FONT><FONT color=3Dblack size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black">Subject: "Optional" in the =
description=20
  of objects from the rfmibv2</SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"> </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P style=3D"MARGIN-LEFT: 36pt"><FONT face=3D"Times New Roman" =
color=3Dblack=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: =
black">David,</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> </SPAN></FONT><FONT =
color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P style=3D"MARGIN-LEFT: 36pt"><FONT face=3D"Times New Roman" =
color=3Dblack=20
  size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: =
black">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  I was reading the description for the following =
objects:</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> </SPAN></FONT><FONT =
color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P style=3D"MARGIN-LEFT: 36pt"><FONT face=3D"Times New Roman" =
color=3Dblack=20
  size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: =
black">docsIfCmtsUpChnlCtrCollCntnMslots&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: =
black">docsIfCmtsUpChnlCtrTotalCntnReqMslots&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: =
black">docsIfCmtsUpChnlCtrUsedCntnReqMslots&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: =
black">docsIfCmtsUpChnlCtrCollCntnReqMslots&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: =
black">docsIfCmtsUpChnlCtrTotalCntnReqDataMslots&nbsp;&nbsp;&nbsp;&nbsp;=
=20
  </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: =
black">docsIfCmtsUpChnlCtrUsedCntnReqDataMslots&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
  </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: =
black">docsIfCmtsUpChnlCtrCollCntnReqDataMslots&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
  </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: =
black">docsIfCmtsUpChnlCtrTotalCntnInitMaintMslots&nbsp;&nbsp;=20
  </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: =
black">docsIfCmtsUpChnlCtrUsedCntnInitMaintMslots&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: =
black">docsIfCmtsUpChnlCtrCollCntnInitMaintMslots&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: =
black">docsIfCmtsUpChnlCtrExtCollCntnMslots&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: =
black">docsIfCmtsUpChnlCtrExtTotalCntnReqMslots&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
  </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: =
black">docsIfCmtsUpChnlCtrExtUsedCntnReqMslots&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=20
  </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: =
black">docsIfCmtsUpChnlCtrExtCollCntnReqMslots&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=20
  </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: =
black">docsIfCmtsUpChnlCtrExtTotalCntnReqDataMslots&nbsp;=20
  </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: =
black">docsIfCmtsUpChnlCtrExtUsedCntnReqDataMslots&nbsp;&nbsp;=20
  </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: =
black">docsIfCmtsUpChnlCtrExtCollCntnReqDataMslots&nbsp;&nbsp;=20
  </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: =
black">docsIfCmtsUpChnlCtrExtTotalCntnInitMaintMslots</SPAN></FONT><FONT=
=20
  color=3Dblack><SPAN style=3D"COLOR: black"> <BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: =
black">docsIfCmtsUpChnlCtrExtUsedCntnInitMaintMslots=20
  </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: =
black">docsIfCmtsUpChnlCtrExtCollCntnInitMaintMslots</SPAN></FONT><FONT =

  color=3Dblack><SPAN style=3D"COLOR: black"> </SPAN></FONT><FONT =
color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P style=3D"MARGIN-LEFT: 36pt"><FONT face=3D"Times New Roman" =
color=3Dblack=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: black">All contain =
the following=20
  description:</SPAN></FONT><FONT color=3Dblack><SPAN style=3D"COLOR: =
black">=20
  </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P style=3D"MARGIN-LEFT: 36pt"><FONT face=3D"Times New Roman" =
color=3Dblack=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: black">"...Support =
for this object=20
  is optional. If the object is not supported, a value of zero is=20
  returned."</SPAN></FONT><FONT color=3Dblack><SPAN style=3D"COLOR: =
black">=20
  <BR></SPAN></FONT><FONT color=3Dblack size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black">Yet in the compliance =
statement these=20
  object belong to the docsIfCmtsGroupV2</SPAN></FONT><FONT =
color=3Dblack><SPAN=20
  style=3D"COLOR: black"> <BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black">Which is described=20
  as:</SPAN></FONT><FONT color=3Dblack><SPAN style=3D"COLOR: black">=20
  <BR></SPAN></FONT><FONT color=3Dblack size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black">-- conditionally mandatory=20
  group</SPAN></FONT><FONT color=3Dblack><SPAN style=3D"COLOR: black">=20
  <BR></SPAN></FONT><FONT color=3Dblack size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black">GROUP docsIfCmtsGroupV2 =
DESCRIPTION=20
  "This group is implemented only in Cable Modem Termination Systems, =
not in=20
  Cable Modems."</SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P style=3D"MARGIN-LEFT: 36pt"><FONT face=3D"Times New Roman" =
color=3Dblack=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: black">This =
description with the=20
  key word "optional" is confusing! If these objects are truly optional =
then=20
  they need not be implemented by the agent.</SPAN></FONT><FONT=20
  color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P style=3D"MARGIN-LEFT: 36pt"><FONT face=3D"Times New Roman" =
color=3Dblack=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: =
black">rfc2580:</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> <BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: =
black">=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=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</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> <BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: =
black">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  3.&nbsp; Mapping of the OBJECT-GROUP macro</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> </SPAN></FONT><FONT =
color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P style=3D"MARGIN-LEFT: 36pt"><FONT face=3D"Times New Roman" =
color=3Dblack=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: black">&nbsp;&nbsp; =
For=20
  conformance purposes, it is useful to define a collection=20
  of</SPAN></FONT><FONT color=3Dblack><SPAN style=3D"COLOR: black">=20
  <BR></SPAN></FONT><FONT color=3Dblack size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black">&nbsp;&nbsp; related managed=20
  objects.&nbsp; The OBJECT-GROUP macro is used to =
define</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> <BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: black">&nbsp;&nbsp; =
each such=20
  collection of related objects.&nbsp; It should be noted that=20
  the</SPAN></FONT><FONT color=3Dblack><SPAN style=3D"COLOR: black">=20
  <BR></SPAN></FONT><FONT color=3Dblack size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black">&nbsp;&nbsp; expansion of the =

  OBJECT-GROUP macro is something which conceptually</SPAN></FONT><FONT =

  color=3Dblack><SPAN style=3D"COLOR: black"> <BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: black">&nbsp;&nbsp; =
happens during=20
  implementation and not during run-time.</SPAN></FONT><FONT =
color=3Dblack><SPAN=20
  style=3D"COLOR: black"> </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P style=3D"MARGIN-LEFT: 36pt"><FONT face=3D"Times New Roman" =
color=3Dblack=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: black">&nbsp;&nbsp; =
To "implement"=20
  an object, an agent must return a reasonably =
accurate</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> <BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: black">&nbsp;&nbsp; =
value for=20
  management protocol retrieval operations; similarly, if =
the</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> <BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: black">&nbsp;&nbsp; =
object is=20
  writable, then in response to a management protocol =
set</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> <BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: black">&nbsp;&nbsp; =
operation, an=20
  agent must accordingly be able to reasonably =
influence</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> <BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: black">&nbsp;&nbsp; =
the underlying=20
  managed entity.&nbsp; If an agent can not implement =
an</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> <BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: black">&nbsp;&nbsp; =
object, the=20
  management protocol provides for it to return an</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> <BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: black">&nbsp;&nbsp; =
exception or=20
  error, e.g, noSuchObject [4].&nbsp; Under no =
circumstances</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> <BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: black">&lt;-----=20
  NOTE</SPAN></FONT><FONT color=3Dblack><SPAN style=3D"COLOR: black">=20
  <BR></SPAN></FONT><FONT color=3Dblack size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black">&nbsp;&nbsp; shall an agent =
return a=20
  value for objects which it does not implement</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> <BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black">&lt;-----</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> <BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: black">&nbsp;&nbsp; =
-- it must=20
  always return the appropriate exception or error, =
as</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> <BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black">&lt;------</SPAN></FONT><FONT =

  color=3Dblack><SPAN style=3D"COLOR: black"> <BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: black">&nbsp;&nbsp; =
described in=20
  the protocol specification [4]. </SPAN></FONT><FONT =
color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: =
black">=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=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</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> </SPAN></FONT><FONT =
color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P style=3D"MARGIN-LEFT: 36pt"><FONT face=3D"Times New Roman" =
color=3Dblack=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: black">I believe your =
intent is=20
  for these objects to be implemented by a CMTS agent, but not =
mandatory for the=20
  agent count these statistics.</SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P style=3D"MARGIN-LEFT: 36pt"><FONT face=3D"Times New Roman" =
color=3Dblack=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: black">I would remove =
the=20
  "optional" comment from the description of each of these objects and =
change=20
  the text to read "If statistics are not maintained by the agent, a =
value of=20
  zero is returned for this object."&nbsp; or something to that=20
  nature.</SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P style=3D"MARGIN-LEFT: 36pt"><FONT face=3D"Times New Roman" =
color=3Dblack=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: black">But what =
really is need is=20
  a change to the description for the docsIfCmtsGroupV2, the comment =
above the=20
  group should be include in the description. I would go as far as to =
say these=20
  objects are "mandatory" for a CMTS agent, even though this is not a=20
  mandatory-group.</SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P style=3D"MARGIN-LEFT: 36pt"><FONT face=3D"Times New Roman" =
color=3Dblack=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: black">If I have =
mis-interrupted=20
  that these objects are not mandatory for the CMTS, then a new =
optional group=20
  is needed for the CMTS, just for these objects.</SPAN></FONT><FONT=20
  color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P style=3D"MARGIN-LEFT: 36pt"><FONT face=3D"Times New Roman" =
color=3Dblack=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: black">From the =
current=20
  descriptions, am just not sure which approach you where trying to =
take. Any=20
  clarification is greatly appreciated.</SPAN></FONT><FONT =
color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P style=3D"MARGIN-LEFT: 36pt"><FONT face=3D"Times New Roman" =
color=3Dblack=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: =
black">Thanks,</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> <BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: black">Will=20
  Murwin</SPAN></FONT><FONT color=3Dblack><SPAN style=3D"COLOR: black"> =

  </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal=20
  style=3D"MARGIN-BOTTOM: 12pt; MARGIN-LEFT: 36pt; mso-margin-top-alt: =
auto"><FONT=20
  face=3D"Times New Roman" color=3Dblack size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt; COLOR: black"><![if =
!supportEmptyParas]><![endif]>&nbsp;</SPAN></FONT><FONT=20
  color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P style=3D"MARGIN-LEFT: 36pt"><FONT face=3D"Times New Roman" =
color=3Dblack=20
  size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: =
black">_____________________________</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> <BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: black">William=20
  Murwin</SPAN></FONT><FONT color=3Dblack><SPAN style=3D"COLOR: black"> =

  <BR></SPAN></FONT><FONT color=3Dblack size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black">Broadband Communications=20
  Sector</SPAN></FONT><FONT color=3Dblack><SPAN style=3D"COLOR: black"> =

  <BR></SPAN></FONT><FONT color=3Dblack size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black">Motorola =
Inc.</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> <BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: black">Email:=20
  W.Murwin@motorola.com</SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"> <BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black">Tel: (508) =
851-8385</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> </SPAN></FONT><FONT =
color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P></DIV></BLOCKQUOTE></BODY></HTM=
L>

------_=_NextPart_001_01C326E6.0ADF8460--

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



From mailnull@www1.ietf.org  Sat May 31 16: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 QAA09008
	for <ipcdn-archive@odin.ietf.org>; Sat, 31 May 2003 16:29:05 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h4VKScb05830
	for ipcdn-archive@odin.ietf.org; Sat, 31 May 2003 16:28:38 -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 h4VKSVB05816;
	Sat, 31 May 2003 16:28:31 -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 h4VKR7B05770
	for <ipcdn@optimus.ietf.org>; Sat, 31 May 2003 16:27:07 -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 QAA08987
	for <ipcdn@ietf.org>; Sat, 31 May 2003 16:27:04 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19MCuo-00015T-00
	for ipcdn@ietf.org; Sat, 31 May 2003 16:25:22 -0400
Received: from coral.tci.com ([198.178.8.81] helo=snowmass.tci.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19MCun-00015K-00
	for ipcdn@ietf.org; Sat, 31 May 2003 16:25:21 -0400
Received: from mms01-relaya.tci.com (mms01-relaya.broadband.att.com [147.191.90.228])
	by snowmass.tci.com (8.12.9/8.12.9) with ESMTP id h4VKQV4A026826;
	Sat, 31 May 2003 14:26:31 -0600 (MDT)
Received: from 147.191.90.10 by mms01-relaya.tci.com with ESMTP (
 Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Sat, 31 May 2003 14:26:26
 -0600
Received: by entexchimc03.broadband.att.com with Internet Mail Service (
 5.5.2653.19) id <J5CB3S8T>; Sat, 31 May 2003 14:26:26 -0600
Message-ID: <6732623D2548D61193C90002A5C88DCC05663B0A@entmaexch02.broadband.att.com>
From: "Woundy, Richard" <Richard_Woundy@cable.comcast.com>
To: "'David.White@ARRISI.COM'" <David.White@ARRISI.COM>
cc: ipcdn@ietf.org
Subject: RE: [ipcdn] Re: draft submitted: subscriber management MIB -11
Date: Sat, 31 May 2003 14:26:24 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-WSS-ID: 12C7D0785382505-01-01
Content-Type: multipart/alternative;
 boundary="----_=_NextPart_001_01C327B2.E7C7F890"
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_01C327B2.E7C7F890
Content-Type: text/plain;
 charset=iso-8859-1
Content-Transfer-Encoding: 7bit

David,
 
This is now posted on the IETF and IPCDN websites.
<ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-subscriber-mib-11.txt>
 
-- Rich

-----Original Message-----
From: David.White@ARRISI.COM [mailto:David.White@ARRISI.COM]
Sent: Thursday, May 29, 2003 2:31 PM
To: Wilson.Sawyer@ARRISI.COM
Cc: bwijnen@lucent.com; ipcdn@ietf.org
Subject: [ipcdn] Re: draft submitted: subscriber management MIB -11



Where can I find a copy of this ? 

Thanks, 
David 




	Wilson Sawyer 


05/29/2003 08:22 AM 


        
        To:        ipcdn@ietf.org 
        cc:        bwijnen@lucent.com, (bcc: David White/Arris) 
        Subject:        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 




------_=_NextPart_001_01C327B2.E7C7F890
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.1170" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=224592320-31052003><FONT face=Arial color=#0000ff 
size=2>David,</FONT></SPAN></DIV>
<DIV><SPAN class=224592320-31052003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=224592320-31052003><FONT face=Arial color=#0000ff size=2>This 
is now posted on the IETF and IPCDN websites. 
&lt;ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-subscriber-mib-11.txt&gt;</FONT></SPAN></DIV>
<DIV><SPAN class=224592320-31052003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=224592320-31052003><FONT face=Arial color=#0000ff size=2>-- 
Rich</FONT></SPAN></DIV>
<BLOCKQUOTE>
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> David.White@ARRISI.COM 
  [mailto:David.White@ARRISI.COM]<BR><B>Sent:</B> Thursday, May 29, 2003 2:31 
  PM<BR><B>To:</B> Wilson.Sawyer@ARRISI.COM<BR><B>Cc:</B> bwijnen@lucent.com; 
  ipcdn@ietf.org<BR><B>Subject:</B> [ipcdn] Re: draft submitted: subscriber 
  management MIB -11<BR><BR></FONT></DIV><BR><FONT face=sans-serif size=2>Where 
  can I find a copy of this ?</FONT> <BR><BR><FONT face=sans-serif 
  size=2>Thanks,</FONT> <BR><FONT face=sans-serif size=2>David</FONT> 
  <BR><BR><BR><BR>
  <TABLE width="100%">
    <TBODY>
    <TR vAlign=top>
      <TD>
      <TD><FONT face=sans-serif size=1><B>Wilson Sawyer</B></FONT> 
        <P><FONT face=sans-serif size=1>05/29/2003 08:22 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;ipcdn@ietf.org</FONT> <BR><FONT face=sans-serif 
        size=1>&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; 
        &nbsp;bwijnen@lucent.com, (bcc: David White/Arris)</FONT> <BR><FONT 
        face=sans-serif size=1>&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; 
        &nbsp; &nbsp; &nbsp;draft submitted: subscriber management MIB 
    -11</FONT></TR></TBODY></TABLE><BR><BR><FONT face=sans-serif size=2>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.</FONT> <BR><BR><FONT face=sans-serif size=2>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.</FONT> <BR><BR><FONT face=sans-serif size=2>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.</FONT> <BR><BR><FONT face=sans-serif 
  size=2>Respectfully submitted,</FONT> <BR><FONT face=sans-serif size=2>Wilson 
  Sawyer</FONT> <BR><FONT face=sans-serif size=2>ARRIS</FONT> 
<BR><BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C327B2.E7C7F890--

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