From exim@www1.ietf.org Wed May 5 00:05:41 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20343 for ; Wed, 5 May 2004 00:05:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLDdm-00086a-0h for ipcdn-archive@odin.ietf.org; Wed, 05 May 2004 00:04:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4544D3Y031157 for ipcdn-archive@odin.ietf.org; Wed, 5 May 2004 00:04:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLDZk-0006wx-5w; Wed, 05 May 2004 00:00:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLDU1-0005bw-7K for ipcdn@optimus.ietf.org; Tue, 04 May 2004 23:54:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19736 for ; Tue, 4 May 2004 23:54:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLDTy-0006uy-UM for ipcdn@ietf.org; Tue, 04 May 2004 23:54:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLDT7-0006n1-00 for ipcdn@ietf.org; Tue, 04 May 2004 23:53:14 -0400 Received: from mail.stargus.com ([65.193.169.166] helo=xchange.stargus.com) by ietf-mx with smtp (Exim 4.12) id 1BLDSf-0006eC-00 for ipcdn@ietf.org; Tue, 04 May 2004 23:52:45 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43253.A547E726" Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 4 May 2004 23:47:10 -0400 Message-ID: <6FEBB4954538C7408210BEDBE484364209B6A2@xchange.stargus.com> Thread-Topic: [ipcdn] Changes for next RFI v2 MIB (draft 10) Thread-Index: AcQrsZt8v6UYmxuDReKNDKDi8iEftwGiz5bg From: "Dan Rice" To: "Woundy, Richard" , "Lejeune, Andre" Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=HTML_60_70, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 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: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C43253.A547E726 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi I just got around to looking at the latest draft. Quick question. =20 Does the statement "Discontinuities in the value of this counter can occur=20 at reinitialization of the managed system, and at other=20 times as indicated by the value of =20 ifCounterDiscontinuityTime for the associated ifIndex." =20 Really belong in the object=20 =20 docsIfSigQMicroreflections OBJECT-TYPE=20 SYNTAX Integer32 (0..255)=20 UNITS "dBc" =20 -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com]=20 Sent: Monday, April 26, 2004 12:51 PM To: 'Lejeune, Andre' Cc: ipcdn@ietf.org Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10) =20 Andre, =20 My apologies, this email was stuck in a "potential spam" queue for IPCDN for way too long... =20 -- Rich -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@Terayon.com] Sent: Thursday, April 15, 2004 11:32 AM To: Eduardo Cardona; ipcdn@ietf.org; DOCSIS OSS Majordomo List; DOCSIS Macup Majordomo List Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10) I believe this object should have been defined as read-only as there is no advantage in having it read-write. Moreover, the RFI specification, in Annex B, defines a min and max value for it. I do not see how such a timeout can take multiple values. There should have been a unique value for it. Andre=20 -----Original Message-----=20 From: Eduardo Cardona [mailto:e.cardona@cablelabs.com]=20 Sent: Thursday, April 15, 2004 11:07 AM=20 To: ipcdn@ietf.org; DOCSIS OSS Majordomo List; DOCSIS Macup Majordomo=20 List=20 Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10)=20 =20 Hi all,=20 I have some questions regarding the MIB object docsIfCmRangingTimeout=20 Both the RFI MIB and OSSI spec SP-OSSIv2.0-I05-040407 Annex A page 96=20 show docsIfCmRangingTimeout with syntax read-write ( the only CM=20 read-write object in RFI MIB).=20 =20 The questions are=20 Is this object really need to be read-write?=20 particularly if there is any management case where read-write is used.=20 Currently there is no Compliance statement to allow read-only access, is that needed?=20 Is there any instance (in general) when the T3 timer is being adjusted=20 by the CM and retained in Memory after CM reboots ?, or would be ok to=20 explicitly not require persistence without incurring in spec changes?=20 (just a clarification)=20 I am Not planning to deprecate the object but The new revision of RF MIB is being updated to address IETF OPS MIB revision guidelines related to=20 persistence and would be good to precise CM usage of the object.=20 See ipcdn mailing list for current discussion about draft 10 updates=20 http://www1.ietf.org/mail-archive/working-groups/ipcdn/current/threads.h tml=20 I will post OSSI DOCSIS reflector with a second revision of the changes=20 as well as IPCDN list soon=20 Thanks=20 Eduardo=20 =20 PD: In Annex A of OSSI spec the obsolete object above=20 docsIfCmRangingTimeout should be docsIfCmRangingRespTimeout. ( being=20 tracked to include in an Omnibus ECR)=20 ------_=_NextPart_001_01C43253.A547E726 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [ipcdn] Changes for next RFI v2 MIB (draft 10)

Hi

I just got around to looking at the = latest draft. Quick = question.

 

Does the = statement

“Discontinuities in the value = of this counter can occur

       &nbs= p;     at reinitialization of the managed system, and at other =

       &nbs= p;     times as indicated by the value of  =

       &nbs= p;     ifCounterDiscontinuityTime for the associated ifIndex."

 

Really belong in the object =

 

docsIfSigQMicrore= flections OBJECT-TYPE

        SYNTAX      = Integer32 (0..255)

        UNITS       = "dBc"

 

-----Original = Message-----
From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com]
Sent: Monday, April 26, = 2004 12:51 PM
To: 'Lejeune, Andre'
Cc: ipcdn@ietf.org
Subject: RE: [ipcdn] = Changes for next RFI v2 MIB (draft 10)

 

Andre,

 

My apologies, = this email was stuck in a "potential spam" queue for IPCDN for way too = long...

 

-- = Rich

-----Original Message-----
From: Lejeune, Andre = [mailto:andre.lejeune@Terayon.com]
Sent: Thursday, April 15, = 2004 11:32 AM
To: Eduardo Cardona; ipcdn@ietf.org; DOCSIS OSS Majordomo List; DOCSIS Macup Majordomo = List
Subject: RE: [ipcdn] = Changes for next RFI v2 MIB (draft 10)

I believe this object should have been = defined as read-only as there is no advantage in having it read-write. Moreover, = the RFI specification, in Annex B, defines a min and max value for it. I do not = see how such a timeout can take multiple values. There should have been a unique = value for it.

Andre

-----Original Message-----
From: Eduardo Cardona = [mailto:e.cardona@cablelabs.com]
Sent: Thursday, April = 15, 2004 11:07 AM
To: ipcdn@ietf.org; = DOCSIS OSS Majordomo List; DOCSIS Macup Majordomo
List
Subject: RE: [ipcdn] = Changes for next RFI v2 MIB (draft 10)

 

Hi all,

I have some questions regarding the MIB = object docsIfCmRangingTimeout

Both the RFI MIB and OSSI spec = SP-OSSIv2.0-I05-040407 Annex A page 96
show = docsIfCmRangingTimeout  with syntax read-write ( the only CM
read-write object in RFI = MIB).

 

The questions are
Is this object really = need to be read-write?
particularly if there is = any management case where read-write is used.
Currently there is no = Compliance statement to allow read-only access, is
that = needed?

Is there any instance (in general) when the = T3 timer is being adjusted
by the CM and retained = in Memory after CM reboots ?, or would be ok to
explicitly not require = persistence without incurring in spec changes?
(just a = clarification)

I am Not planning to deprecate the object but = The new revision of RF MIB
is being updated to = address IETF OPS MIB revision guidelines related to
persistence and would be = good to precise CM usage of the object.

See ipcdn mailing list for current discussion = about draft 10 updates
http://www1.ietf.org/mail-archive/working-groups/ipcdn/= current/threads.h
tml =

I will post OSSI DOCSIS reflector with a = second revision of the changes
as well as IPCDN list = soon

Thanks

Eduardo

 

PD: In Annex A of OSSI spec the obsolete = object above
docsIfCmRangingTimeout = should be docsIfCmRangingRespTimeout. ( being
tracked to include in an = Omnibus ECR)

------_=_NextPart_001_01C43253.A547E726-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed May 5 02:03:43 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28858 for ; Wed, 5 May 2004 02:03:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLFTq-0005or-Au for ipcdn-archive@odin.ietf.org; Wed, 05 May 2004 02:02:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45626qS022368 for ipcdn-archive@odin.ietf.org; Wed, 5 May 2004 02:02:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLFNz-0003Z4-VX; Wed, 05 May 2004 01:56:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLFLT-0002jI-A0 for ipcdn@optimus.ietf.org; Wed, 05 May 2004 01:53:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24605 for ; Wed, 5 May 2004 01:53:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLFLP-0001sF-W8 for ipcdn@ietf.org; Wed, 05 May 2004 01:53:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLFKP-0001iJ-00 for ipcdn@ietf.org; Wed, 05 May 2004 01:52:22 -0400 Received: from [202.75.205.68] (helo=mail.blr.velankani.com) by ietf-mx with esmtp (Exim 4.12) id 1BLFJh-0001GJ-00 for ipcdn@ietf.org; Wed, 05 May 2004 01:51:37 -0400 Received: from d108 (unknown [10.0.14.19]) by mail.blr.velankani.com (Postfix) with ESMTP id 65C59354ABF for ; Wed, 5 May 2004 11:20:48 +0530 (IST) From: "Prashant Singh" To: Date: Wed, 5 May 2004 11:19:48 +0530 Message-ID: <002801c43264$c6f09330$130e000a@blr.velankani.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0029_01C43292.E0A8CF30" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,DEAR_SOMETHING,HTML_70_80, HTML_MESSAGE autolearn=no version=2.60 Subject: [ipcdn] RFC or Draft on IPCDN 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: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0029_01C43292.E0A8CF30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Sir, Can you pls. let me know the draft or the RFC which defines the functionality of the above technology. I have searched the IETF site and found only the documents defining MIBs. I need the functionality, how does it works in order to prepare the test plan. Best regards Prashant ------=_NextPart_000_0029_01C43292.E0A8CF30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Sir,

 

Can you pls. let me know the draft or the RFC which = defines the functionality of the above technology.

I have searched the IETF site and found only the = documents defining MIBs.

 

I need the functionality, how does it works in order = to prepare the test plan.

 

Best regards

Prashant

 

------=_NextPart_000_0029_01C43292.E0A8CF30-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed May 5 11:35:23 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21315 for ; Wed, 5 May 2004 11:35:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLOFA-0002aC-I7 for ipcdn-archive@odin.ietf.org; Wed, 05 May 2004 11:23:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45FNWh2009929 for ipcdn-archive@odin.ietf.org; Wed, 5 May 2004 11:23:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLO4y-00077w-LE; Wed, 05 May 2004 11:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLNw1-0000yU-Pv for ipcdn@optimus.ietf.org; Wed, 05 May 2004 11:03:45 -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 LAA18687 for ; Wed, 5 May 2004 11:03:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLNvz-0001SB-5n for ipcdn@ietf.org; Wed, 05 May 2004 11:03:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLNv4-0001AA-00 for ipcdn@ietf.org; Wed, 05 May 2004 11:02:47 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BLNu5-0000d9-00 for ipcdn@ietf.org; Wed, 05 May 2004 11:01:45 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id i45F1CGe026820; Wed, 5 May 2004 09:01:13 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C432B1.CE5FBCFC" Subject: RE: [ipcdn] RFC or Draft on IPCDN Date: Wed, 5 May 2004 09:01:12 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46F03E2CB@srvxchg.cablelabs.com> Thread-Topic: [ipcdn] RFC or Draft on IPCDN Thread-Index: AcQyZooHDy1G8chFSKWK+l4lLLxMdgASofog From: "Eduardo Cardona" To: "Prashant Singh" , X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,DEAR_SOMETHING,HTML_60_70, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 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: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C432B1.CE5FBCFC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IPCDN workinging main focus is MIB requirements for Data over Cable related technologies. =20 Please go to www.cablelabs.com/projects to find the area and protocols you are interested, e.g. DOCSIS(R), PacketCable(TM), OpenCable(TM), CableHome(TM) =20 Thanks =20 Eduardo -----Original Message----- From: Prashant Singh [mailto:psingh@velankani.com]=20 Sent: Tuesday, May 04, 2004 11:50 PM To: ipcdn@ietf.org Subject: [ipcdn] RFC or Draft on IPCDN Dear Sir, =20 Can you pls. let me know the draft or the RFC which defines the functionality of the above technology. I have searched the IETF site and found only the documents defining MIBs. =20 I need the functionality, how does it works in order to prepare the test plan. =20 Best regards Prashant=20 =20 ------_=_NextPart_001_01C432B1.CE5FBCFC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
IPCDN=20 workinging main focus is MIB requirements for Data over Cable = related=20 technologies.
 
Please=20 go to www.cablelabs.com/projects= =20 to find the area and protocols you are = interested, e.g.=20  DOCSIS(R), PacketCable(TM), OpenCable(TM),=20 CableHome(TM)
 
Thanks
 
Eduardo
-----Original Message-----
From: = Prashant Singh=20 [mailto:psingh@velankani.com]
Sent: Tuesday, May 04, 2004 = 11:50=20 PM
To: ipcdn@ietf.org
Subject: [ipcdn] RFC or = Draft on=20 IPCDN

Dear = Sir,

 

Can you pls. let me know = the draft=20 or the RFC which defines the functionality of the above=20 technology.

I have searched the IETF = site and=20 found only the documents defining MIBs.

 

I need the = functionality, how does=20 it works in order to prepare the test plan.

 

Best = regards

Prashant =

 

------_=_NextPart_001_01C432B1.CE5FBCFC-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed May 5 11:41:47 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21671 for ; Wed, 5 May 2004 11:41:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLOVP-0000Ym-OW for ipcdn-archive@odin.ietf.org; Wed, 05 May 2004 11:40:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45FeJmi002141 for ipcdn-archive@odin.ietf.org; Wed, 5 May 2004 11:40:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLOFg-0003E1-Ie; Wed, 05 May 2004 11:24:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLO8b-000862-92 for ipcdn@optimus.ietf.org; Wed, 05 May 2004 11:16:45 -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 LAA20244 for ; Wed, 5 May 2004 11:16:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLO8a-0005I3-C3 for ipcdn@ietf.org; Wed, 05 May 2004 11:16:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLO7k-00052m-00 for ipcdn@ietf.org; Wed, 05 May 2004 11:15:53 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BLO6f-0004YZ-00 for ipcdn@ietf.org; Wed, 05 May 2004 11:14:45 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id i45FEBGe029661; Wed, 5 May 2004 09:14:11 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10) Date: Wed, 5 May 2004 09:14:10 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46F03E2CC@srvxchg.cablelabs.com> Thread-Topic: [ipcdn] Changes for next RFI v2 MIB (draft 10) Thread-Index: AcQrsZt8v6UYmxuDReKNDKDi8iEftwGiz5bgAB1j6dA= From: "Eduardo Cardona" To: "Dan Rice @ Stargus" , "Richard Woundy @ Comcast" , "Lejeune, Andre" Cc: X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Dan,=20 Thanks for the note, certainly a good catch, It is certainly a typo, while adding discontinuity statements back In February 2003 if I am not mistaken Draft 06 says : docsIfSigQMicroreflections OBJECT-TYPE SYNTAX Integer32 (0..255) UNITS "dBc" MAX-ACCESS read-only STATUS current DESCRIPTION "Total microreflections including in-channel response as perceived on this interface, measured in dBc below the signal level. This object is not assumed to return an absolutely accurate value, but should give a rough indication of microreflections received on this interface. It is up to the implementer to provide information as accurate as possible." REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-IO2-020617, Tables 4-1 and 4-2" ::=3D { docsIfSignalQualityEntry 6 } and draft 07 updates multiple counter objects like docsIfSigQUnerroreds, docsIfSigQCorrecteds, docsIfSigQCorrecteds, docsIfSigQUncorrectables, docsIfSigQCorrecteds, docsIfSigQUncorrectables, Ext objects, etc. By mistake it was included also in docsIfSigQMicroreflections=20 Perhaps a correction should be done during final editorial revision to remove that statement docsIfSigQMicroreflections OBJECT-TYPE=20 SYNTAX Integer32 (0..255)=20 UNITS "dBc"=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "Total microreflections including in-channel response=20 as perceived on this interface, measured in dBc below=20 the signal level.=20 This object is not assumed to return an absolutely=20 accurate value, but SHOULD give a rough indication=20 of microreflections received on this interface.=20 It is up to the implementer to provide information=20 as accurate as possible."=20 REFERENCE=20 "Data-Over-Cable Service Interface Specifications: Radio=20 Frequency Interface Specification SP-RFIv2.0-I05-040407,=20 Tables 4-1 and 4-2"=20 ::=3D { docsIfSignalQualityEntry 6 }=20 Thanks=20 Eduardo -----Original Message----- From: Dan Rice @ Stargus=20 Sent: Tuesday, May 04, 2004 9:47 PM To: Richard Woundy @ Comcast; Lejeune, Andre Cc: ipcdn@ietf.org Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10) Hi I just got around to looking at the latest draft. Quick question. =20 Does the statement "Discontinuities in the value of this counter can occur=20 at reinitialization of the managed system, and at other=20 times as indicated by the value of =20 ifCounterDiscontinuityTime for the associated ifIndex." =20 Really belong in the object=20 =20 docsIfSigQMicroreflections OBJECT-TYPE=20 SYNTAX Integer32 (0..255)=20 UNITS "dBc" =20 -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com]=20 Sent: Monday, April 26, 2004 12:51 PM To: 'Lejeune, Andre' Cc: ipcdn@ietf.org Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10) =20 Andre, =20 My apologies, this email was stuck in a "potential spam" queue for IPCDN for way too long... =20 -- Rich -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@Terayon.com] Sent: Thursday, April 15, 2004 11:32 AM To: Eduardo Cardona; ipcdn@ietf.org; DOCSIS OSS Majordomo List; DOCSIS Macup Majordomo List Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10) I believe this object should have been defined as read-only as there is no advantage in having it read-write. Moreover, the RFI specification, in Annex B, defines a min and max value for it. I do not see how such a timeout can take multiple values. There should have been a unique value for it. Andre=20 -----Original Message-----=20 From: Eduardo Cardona [mailto:e.cardona@cablelabs.com]=20 Sent: Thursday, April 15, 2004 11:07 AM=20 To: ipcdn@ietf.org; DOCSIS OSS Majordomo List; DOCSIS Macup Majordomo=20 List=20 Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10)=20 =20 Hi all,=20 I have some questions regarding the MIB object docsIfCmRangingTimeout=20 Both the RFI MIB and OSSI spec SP-OSSIv2.0-I05-040407 Annex A page 96=20 show docsIfCmRangingTimeout with syntax read-write ( the only CM=20 read-write object in RFI MIB).=20 =20 The questions are=20 Is this object really need to be read-write?=20 particularly if there is any management case where read-write is used.=20 Currently there is no Compliance statement to allow read-only access, is that needed?=20 Is there any instance (in general) when the T3 timer is being adjusted=20 by the CM and retained in Memory after CM reboots ?, or would be ok to=20 explicitly not require persistence without incurring in spec changes?=20 (just a clarification)=20 I am Not planning to deprecate the object but The new revision of RF MIB is being updated to address IETF OPS MIB revision guidelines related to=20 persistence and would be good to precise CM usage of the object.=20 See ipcdn mailing list for current discussion about draft 10 updates=20 http://www1.ietf.org/mail-archive/working-groups/ipcdn/current/threads.h tml=20 I will post OSSI DOCSIS reflector with a second revision of the changes=20 as well as IPCDN list soon=20 Thanks=20 Eduardo=20 =20 PD: In Annex A of OSSI spec the obsolete object above=20 docsIfCmRangingTimeout should be docsIfCmRangingRespTimeout. ( being=20 tracked to include in an Omnibus ECR)=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue May 11 09:29:38 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25356 for ; Tue, 11 May 2004 09:29:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNXIj-00049c-7f for ipcdn-archive@odin.ietf.org; Tue, 11 May 2004 09:28:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4BDS59F015951 for ipcdn-archive@odin.ietf.org; Tue, 11 May 2004 09:28:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNXCq-0002vo-Jm; Tue, 11 May 2004 09:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNX9u-0002Am-2M for ipcdn@optimus.ietf.org; Tue, 11 May 2004 09:18:58 -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 JAA24755 for ; Tue, 11 May 2004 09:18:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNX9s-0000Lq-Ea for ipcdn@ietf.org; Tue, 11 May 2004 09:18:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNX8v-0007lB-00 for ipcdn@ietf.org; Tue, 11 May 2004 09:17:57 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BNX8T-0007NW-00 for ipcdn@ietf.org; Tue, 11 May 2004 09:17:29 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id i4BDGlGe016226; Tue, 11 May 2004 07:16:48 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] wg review of draft-ietf-ipcdn-docsisevent-mib-03.txt Date: Tue, 11 May 2004 07:16:47 -0600 Message-ID: Thread-Topic: [ipcdn] wg review of draft-ietf-ipcdn-docsisevent-mib-03.txt Thread-Index: AcQuHyoM8H6bM/OrTUGJMYhknhq/wQJOkoFQ From: "Jean-Francois Mule" To: "Ipcdn List (E-mail)" , "Greg Nakanishi (E-mail)" , "Azlina Ahmad (E-mail)" Cc: "Harrie Hazewinkel" , "Raftus, David" X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Folks, Following Dave's comments of draft-ietf-ipcdn-docsisevent-mib-03 = (focusing more on docsis), Harrie has kindly accepted to also review the = ID and send his comments to the list. Is anyone else interested? The intent is to gather wg comments by the end of May 2004 to allow the = authors to release an updated draft shortly after and go to WGLC. Jean-Fran=E7ois=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue May 11 15:03:35 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16781 for ; Tue, 11 May 2004 15:03:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNcTM-0006pY-P2 for ipcdn-archive@odin.ietf.org; Tue, 11 May 2004 14:59:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4BIxOYU026256 for ipcdn-archive@odin.ietf.org; Tue, 11 May 2004 14:59:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNcIP-00058c-6p; Tue, 11 May 2004 14:48:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNcBf-0002F7-7N for ipcdn@optimus.ietf.org; Tue, 11 May 2004 14:41: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 OAA15142 for ; Tue, 11 May 2004 14:41:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNcBc-00044b-E8 for ipcdn@ietf.org; Tue, 11 May 2004 14:41:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNcAd-0003dl-00 for ipcdn@ietf.org; Tue, 11 May 2004 14:40:04 -0400 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 1BNc9c-0003Bb-00 for ipcdn@ietf.org; Tue, 11 May 2004 14:39:00 -0400 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id i4BIcx4k008144 for ; Tue, 11 May 2004 11:38:59 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i4BIcvZ4013135 for ; Tue, 11 May 2004 13:38:57 -0500 Received: by ca25exm01 with Internet Mail Service (5.5.2657.2) id ; Tue, 11 May 2004 11:38:57 -0700 Message-ID: From: Nakanishi Greg-MGI8179 To: "'Raftus, David'" , "Ipcdn List (E-mail)" Subject: RE: [ipcdn] wg review of draft-ietf-ipcdn-docsisevent-mib-03.txt Date: Tue, 11 May 2004 11:37:26 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable hi Dave, Thanks for reviewing the draft. Sorry for the delayed response. My = responses are inline. > 1) Not sure if the default value of NULL is appropriate for=20 > the BITs defval for object docsDevCmTrapControl. This doesn't=20 > give any real guidance as to whether the traps should be=20 > enabled or disabled. The original value of 0x00, while=20 > perhaps not strictly conforming to the octet string nature of=20 > BITs, did signal that all traps default to off.=20 >=20 I think some input from a MIB expert would be useful here. However, = from the example given in RFC2578, I think a NULL value indicates that = all the bits are set to zero. The following snippet is from section = 7.9 of RFC 2578. BITS DEFVAL { { primary, secondary } } -- enumerated values that are set BITS DEFVAL { { } } -- no enumerated values are set > 2) The intention of keeping the deprecated mib objects within=20 > the trap definitions was to maintain back-compatibility with=20 > existing 1.1 applications that implemented the trap defs=20 > using the original docs-if ext mib. With the deprecated=20 > objects removed, it is possible that these pre-rf mib v2=20 > draft 1.1 applications may not be compatible with the new trap defs.=20 >=20 This MIB isn't going to be backward compatible anyway since the MIB = root is going to change. The docs-if ext mib is rooted under docsdev = while this mib will be rooted under mib-2. So, implementations will = have to change regardless. > 3) The event mib is not in sync with the MTA event mgmt mib.=20 > It is not really fair to compare them. The MTA event mgmt mib=20 > uses a generic definition for all informs and traps=20 > pertaining to MTA events. The Docsis event mib creates=20 > individual trap defs for each event. It may be a nice idea to=20 > add inform defs in the Docsis event mib though.=20 I think that the notifications defined in this MIB can be sent as a = Trap or an Inform. Although, the notification object all end with the = term 'trap' which would seems to imply that they should be sent as a = trap. Whether a notification is sent as a Trap or Inform should be = defined outside of the MIB itself, I think. For example, the = Notification MIB (RFC 3413) supports the ability to do this. Thanks again for reviewing. greg -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org] On Behalf Of = Raftus, David Sent: Thursday, April 29, 2004 11:15 AM To: Ipcdn List (E-mail) Subject: FW: [ipcdn] wg review of = draft-ietf-ipcdn-docsisevent-mib-03.txt Hi,=20 Forwarding event mib review comments to the list.=20 Thanks,=20 Dave=20 -----Original Message-----=20 From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 Sent: Thursday, April 29, 2004 12:24 PM=20 To: Raftus, David=20 Cc: Greg Nakanishi (E-mail); Azlina Ahmad (E-mail)=20 Subject: RE: [ipcdn] wg review of = draft-ietf-ipcdn-docsisevent-mib-03.txt=20 Hi David,=20 Thank for your DOCSIS review, this is the most important. Can you still = send your DOCSIS review comments to the list? This was requested by = Bert as it is standard ietf process... Thanks again,=20 Jean-Fran=E7ois=20 > -----Original Message-----=20 > From: Raftus, David [mailto:david.raftus@Terayon.com]=20 > Sent: Thursday, April 29, 2004 8:30 AM=20 > To: Jean-Francois Mule=20 > Cc: Greg Nakanishi (E-mail); Azlina Ahmad (E-mail); Raftus, David=20 > Subject: RE: [ipcdn] wg review of=20 > draft-ietf-ipcdn-docsisevent-mib-03.txt=20 >=20 >=20 > Hi Jean-Francois,=20 >=20 > This event mib draft is actually not too different from the=20 > v2 version created in Jan/03.=20 >=20 > I'm afraid I don't have the necessary background to evaluate=20 > the mib according to compliance with the mib guidelines and=20 > conformance with ID-nits. Sorry for that. Therefore, I didn't=20 > CC my comments to the IPCDN list. >=20 > I did examine the mib from a Docsis perspective though, and=20 > have the following comments:=20 >=20 > 1) Not sure if the default value of NULL is appropriate for=20 > the BITs defval for object docsDevCmTrapControl. This doesn't=20 > give any real guidance as to whether the traps should be=20 > enabled or disabled. The original value of 0x00, while=20 > perhaps not strictly conforming to the octet string nature of=20 > BITs, did signal that all traps default to off.=20 >=20 > 2) The intention of keeping the deprecated mib objects within=20 > the trap definitions was to maintain back-compatibility with=20 > existing 1.1 applications that implemented the trap defs=20 > using the original docs-if ext mib. With the deprecated=20 > objects removed, it is possible that these pre-rf mib v2=20 > draft 1.1 applications may not be compatible with the new trap defs.=20 >=20 > 3) The event mib is not in sync with the MTA event mgmt mib.=20 > It is not really fair to compare them. The MTA event mgmt mib=20 > uses a generic definition for all informs and traps=20 > pertaining to MTA events. The Docsis event mib creates=20 > individual trap defs for each event. It may be a nice idea to=20 > add inform defs in the Docsis event mib though.=20 >=20 > Again, sorry for not commenting on mib guidelines, etc.=20 >=20 > Regards,=20 > Dave=20 >=20 >=20 > -----Original Message-----=20 > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 > Sent: Thursday, April 08, 2004 1:05 PM=20 > To: Raftus, David=20 > Cc: Richard Woundy @ Comcast=20 > Subject: RE: [ipcdn] wg review of=20 > draft-ietf-ipcdn-docsisevent-mib-03.txt=20 >=20 > Dave,=20 >=20 > Thanks a lot.=20 > For your review, please consider the following:=20 > - compliance with mib guidelines check-list=20 > - conformance with ID-nits,=20 > - is this MIB in sync with the other ipcdn ID on event mgmt=20 > for MTAs:=20 > =20 > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-event=20 > mess-03.txt=20 > - etc.=20 >=20 > Also, please send your comments to the ipcdn list.=20 > thx,=20 > jean-francois.=20 =20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue May 11 17:02:20 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25169 for ; Tue, 11 May 2004 17:02:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNe6M-0008T3-Bv for ipcdn-archive@odin.ietf.org; Tue, 11 May 2004 16:43:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4BKhkep032549 for ipcdn-archive@odin.ietf.org; Tue, 11 May 2004 16:43:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNe2j-0006mU-Uh; Tue, 11 May 2004 16:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNdcm-0007QD-Mo for ipcdn@optimus.ietf.org; Tue, 11 May 2004 16:13:12 -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 QAA22091 for ; Tue, 11 May 2004 16:13:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNdck-0005U2-SR for ipcdn@ietf.org; Tue, 11 May 2004 16:13:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNdbp-00053r-00 for ipcdn@ietf.org; Tue, 11 May 2004 16:12:14 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BNdbA-0004al-00 for ipcdn@ietf.org; Tue, 11 May 2004 16:11:33 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id i4BKB1Ge009112; Tue, 11 May 2004 14:11:01 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] wg review of draft-ietf-ipcdn-docsisevent-mib-03.txt Date: Tue, 11 May 2004 14:11:00 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46F03E332@srvxchg.cablelabs.com> Thread-Topic: [ipcdn] wg review of draft-ietf-ipcdn-docsisevent-mib-03.txt Thread-Index: AcQ3iisGP9WoheJkQwi5neHLqjPjvAACMCHA From: "Eduardo Cardona" To: "Nakanishi Greg-MGI8179" , "Raftus, David" , "Ipcdn List (E-mail)" X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Greg,=20 You are right to point the RFC3413 filtering mechanism and trap/inform = dispatch. The discussion of Notification vs Trap in the object names was handled = before (draft01-02 transition I guess) under the assumption of not = re-rooting, (to avoid deprecation and too much unnecesary work). If it is going to be rerooted, I believe a 'Notification'/'Notify' = rather than 'Trap' would be precise as IETF might concern or stay as it = is right now if that is ok for MIB doctors to keep the terminology as = 'Trap's. Eduardo -----Original Message----- From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com]=20 Sent: Tuesday, May 11, 2004 12:37 PM To: 'Raftus, David'; Ipcdn List (E-mail) Subject: RE: [ipcdn] wg review of = draft-ietf-ipcdn-docsisevent-mib-03.txt hi Dave, Thanks for reviewing the draft. Sorry for the delayed response. My = responses are inline. > 1) Not sure if the default value of NULL is appropriate for > the BITs defval for object docsDevCmTrapControl. This doesn't=20 > give any real guidance as to whether the traps should be=20 > enabled or disabled. The original value of 0x00, while=20 > perhaps not strictly conforming to the octet string nature of=20 > BITs, did signal that all traps default to off.=20 >=20 I think some input from a MIB expert would be useful here. However, = from the example given in RFC2578, I think a NULL value indicates that = all the bits are set to zero. The following snippet is from section 7.9 = of RFC 2578. BITS DEFVAL { { primary, secondary } } -- enumerated values that are set BITS DEFVAL { { } } -- no enumerated values are set > 2) The intention of keeping the deprecated mib objects within=20 > the trap definitions was to maintain back-compatibility with=20 > existing 1.1 applications that implemented the trap defs=20 > using the original docs-if ext mib. With the deprecated=20 > objects removed, it is possible that these pre-rf mib v2=20 > draft 1.1 applications may not be compatible with the new trap defs.=20 >=20 This MIB isn't going to be backward compatible anyway since the MIB root = is going to change. The docs-if ext mib is rooted under docsdev while = this mib will be rooted under mib-2. So, implementations will have to = change regardless. > 3) The event mib is not in sync with the MTA event mgmt mib.=20 > It is not really fair to compare them. The MTA event mgmt mib=20 > uses a generic definition for all informs and traps=20 > pertaining to MTA events. The Docsis event mib creates=20 > individual trap defs for each event. It may be a nice idea to=20 > add inform defs in the Docsis event mib though.=20 I think that the notifications defined in this MIB can be sent as a Trap = or an Inform. Although, the notification object all end with the term = 'trap' which would seems to imply that they should be sent as a trap. = Whether a notification is sent as a Trap or Inform should be defined = outside of the MIB itself, I think. For example, the Notification MIB = (RFC 3413) supports the ability to do this. Thanks again for reviewing. greg -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org] On Behalf Of = Raftus, David Sent: Thursday, April 29, 2004 11:15 AM To: Ipcdn List (E-mail) Subject: FW: [ipcdn] wg review of = draft-ietf-ipcdn-docsisevent-mib-03.txt Hi,=20 Forwarding event mib review comments to the list.=20 Thanks,=20 Dave=20 -----Original Message-----=20 From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 Sent: Thursday, April 29, 2004 12:24 PM=20 To: Raftus, David=20 Cc: Greg Nakanishi (E-mail); Azlina Ahmad (E-mail)=20 Subject: RE: [ipcdn] wg review of = draft-ietf-ipcdn-docsisevent-mib-03.txt=20 Hi David,=20 Thank for your DOCSIS review, this is the most important. Can you still = send your DOCSIS review comments to the list? This was requested by Bert = as it is standard ietf process... Thanks again,=20 Jean-Fran=E7ois=20 > -----Original Message-----=20 > From: Raftus, David [mailto:david.raftus@Terayon.com]=20 > Sent: Thursday, April 29, 2004 8:30 AM=20 > To: Jean-Francois Mule=20 > Cc: Greg Nakanishi (E-mail); Azlina Ahmad (E-mail); Raftus, David=20 > Subject: RE: [ipcdn] wg review of=20 > draft-ietf-ipcdn-docsisevent-mib-03.txt=20 >=20 >=20 > Hi Jean-Francois,=20 >=20 > This event mib draft is actually not too different from the=20 > v2 version created in Jan/03.=20 >=20 > I'm afraid I don't have the necessary background to evaluate=20 > the mib according to compliance with the mib guidelines and=20 > conformance with ID-nits. Sorry for that. Therefore, I didn't=20 > CC my comments to the IPCDN list.=20 >=20 > I did examine the mib from a Docsis perspective though, and=20 > have the following comments:=20 >=20 > 1) Not sure if the default value of NULL is appropriate for=20 > the BITs defval for object docsDevCmTrapControl. This doesn't=20 > give any real guidance as to whether the traps should be=20 > enabled or disabled. The original value of 0x00, while=20 > perhaps not strictly conforming to the octet string nature of=20 > BITs, did signal that all traps default to off.=20 >=20 > 2) The intention of keeping the deprecated mib objects within=20 > the trap definitions was to maintain back-compatibility with=20 > existing 1.1 applications that implemented the trap defs=20 > using the original docs-if ext mib. With the deprecated=20 > objects removed, it is possible that these pre-rf mib v2=20 > draft 1.1 applications may not be compatible with the new trap defs.=20 >=20 > 3) The event mib is not in sync with the MTA event mgmt mib.=20 > It is not really fair to compare them. The MTA event mgmt mib=20 > uses a generic definition for all informs and traps=20 > pertaining to MTA events. The Docsis event mib creates=20 > individual trap defs for each event. It may be a nice idea to=20 > add inform defs in the Docsis event mib though.=20 >=20 > Again, sorry for not commenting on mib guidelines, etc.=20 >=20 > Regards,=20 > Dave=20 >=20 >=20 > -----Original Message-----=20 > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 > Sent: Thursday, April 08, 2004 1:05 PM=20 > To: Raftus, David=20 > Cc: Richard Woundy @ Comcast=20 > Subject: RE: [ipcdn] wg review of=20 > draft-ietf-ipcdn-docsisevent-mib-03.txt=20 >=20 > Dave,=20 >=20 > Thanks a lot.=20 > For your review, please consider the following:=20 > - compliance with mib guidelines check-list=20 > - conformance with ID-nits,=20 > - is this MIB in sync with the other ipcdn ID on event mgmt=20 > for MTAs:=20 > =20 > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-event=20 > mess-03.txt=20 > - etc.=20 >=20 > Also, please send your comments to the ipcdn list.=20 > thx,=20 > jean-francois.=20 =20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue May 11 21:26:32 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12308 for ; Tue, 11 May 2004 21:26:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNiSI-00062z-SE for ipcdn-archive@odin.ietf.org; Tue, 11 May 2004 21:22:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4C1Mga4023223 for ipcdn-archive@odin.ietf.org; Tue, 11 May 2004 21:22:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNiLo-0004np-O1; Tue, 11 May 2004 21:16:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNiIJ-0003x7-IJ for ipcdn@optimus.ietf.org; Tue, 11 May 2004 21:12:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11604 for ; Tue, 11 May 2004 21:12:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNiIH-0006O7-07 for ipcdn@ietf.org; Tue, 11 May 2004 21:12:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNiHN-0005xR-00 for ipcdn@ietf.org; Tue, 11 May 2004 21:11:26 -0400 Received: from pintail.mail.pas.earthlink.net ([207.217.120.122]) by ietf-mx with esmtp (Exim 4.12) id 1BNiGU-0005Xg-00 for ipcdn@ietf.org; Tue, 11 May 2004 21:10:30 -0400 Received: from h-68-164-91-171.snvacaid.dynamic.covad.net ([68.164.91.171] helo=oemcomputer) by pintail.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BNiGS-0000sU-00 for ipcdn@ietf.org; Tue, 11 May 2004 18:10:28 -0700 Message-ID: <002c01c437be$89430040$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Ipcdn List \(E-mail\)" References: Subject: Re: [ipcdn] wg review of draft-ietf-ipcdn-docsisevent-mib-03.txt Date: Tue, 11 May 2004 18:14:55 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Hi - > From: "Nakanishi Greg-MGI8179" > To: "'Raftus, David'" ; "Ipcdn List (E-mail)" > Sent: Tuesday, May 11, 2004 11:37 AM > Subject: RE: [ipcdn] wg review of draft-ietf-ipcdn-docsisevent-mib-03.txt ... > > 1) Not sure if the default value of NULL is appropriate for > > the BITs defval for object docsDevCmTrapControl. This doesn't > > give any real guidance as to whether the traps should be > > enabled or disabled. The original value of 0x00, while > > perhaps not strictly conforming to the octet string nature of > > BITs, did signal that all traps default to off. > > > > I think some input from a MIB expert would be useful here. However, > from the example given in RFC2578, I think a NULL value indicates > that all the bits are set to zero. The following snippet is from section > 7.9 of RFC 2578. > > BITS DEFVAL { { primary, secondary } } > -- enumerated values that are set > BITS DEFVAL { { } } > -- no enumerated values are set ... Having a DEFVAL in which no bits are set is prefectly reasonable, and specifying "DEFVAL {{}}" is the correct way to do it, but *please* don't call it "NULL". That is a distinct ASN.1 type, and I'd strongly recommend not using that term for this purpose. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri May 14 18:11:04 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02255 for ; Fri, 14 May 2004 18:11:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOkp0-0006TO-Ua for ipcdn-archive@odin.ietf.org; Fri, 14 May 2004 18:06:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4EM6QP3024882 for ipcdn-archive@odin.ietf.org; Fri, 14 May 2004 18:06:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOkht-0002AN-Iw; Fri, 14 May 2004 17:59:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOkdM-0001Ca-N2 for ipcdn@optimus.ietf.org; Fri, 14 May 2004 17:54:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00825 for ; Fri, 14 May 2004 17:54:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOkdK-0001Dr-22 for ipcdn@ietf.org; Fri, 14 May 2004 17:54:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOkcL-0000j9-00 for ipcdn@ietf.org; Fri, 14 May 2004 17:53:22 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1BOkbT-0000Da-00 for ipcdn@ietf.org; Fri, 14 May 2004 17:52:27 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i4ELqqGv022260 for ; Fri, 14 May 2004 14:52:52 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id i4ELpEA2002986 for ; Fri, 14 May 2004 16:51:15 -0500 Received: by ca25exm01 with Internet Mail Service (5.5.2657.2) id ; Fri, 14 May 2004 14:52:25 -0700 Message-ID: From: Nakanishi Greg-MGI8179 To: "'Eduardo Cardona'" , "Raftus, David" , "Ipcdn List (E-mail)" Subject: RE: [ipcdn] wg review of draft-ietf-ipcdn-docsisevent-mib-03.txt Date: Fri, 14 May 2004 14:52:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by motgate8.mot.com id i4ELqqGv022260 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Eduardo, Thanks for the feedback. Let's wait to hear what the MIB doctors say about the object name. I'm O= K with changing the name, if that's the recommendation. greg -----Original Message----- From: Eduardo Cardona [mailto:e.cardona@CableLabs.com]=20 Sent: Tuesday, May 11, 2004 1:11 PM To: Nakanishi Greg-MGI8179; Raftus, David; Ipcdn List (E-mail) Subject: RE: [ipcdn] wg review of draft-ietf-ipcdn-docsisevent-mib-03.txt Greg,=20 You are right to point the RFC3413 filtering mechanism and trap/inform di= spatch. The discussion of Notification vs Trap in the object names was handled be= fore (draft01-02 transition I guess) under the assumption of not re-rooti= ng, (to avoid deprecation and too much unnecesary work). If it is going t= o be rerooted, I believe a 'Notification'/'Notify' rather than 'Trap' wou= ld be precise as IETF might concern or stay as it is right now if that is= ok for MIB doctors to keep the terminology as 'Trap's. Eduardo -----Original Message----- From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com]=20 Sent: Tuesday, May 11, 2004 12:37 PM To: 'Raftus, David'; Ipcdn List (E-mail) Subject: RE: [ipcdn] wg review of draft-ietf-ipcdn-docsisevent-mib-03.txt hi Dave, Thanks for reviewing the draft. Sorry for the delayed response. My respo= nses are inline. > 1) Not sure if the default value of NULL is appropriate for the BITs=20 > defval for object docsDevCmTrapControl. This doesn't give any real=20 > guidance as to whether the traps should be enabled or disabled. The=20 > original value of 0x00, while perhaps not strictly conforming to the=20 > octet string nature of BITs, did signal that all traps default to off. >=20 I think some input from a MIB expert would be useful here. However, from= the example given in RFC2578, I think a NULL value indicates that all th= e bits are set to zero. The following snippet is from section 7.9 of RFC= 2578. BITS DEFVAL { { primary, secondary } } -- enumerated values that are set BITS DEFVAL { { } } -- no enumerated values are set > 2) The intention of keeping the deprecated mib objects within > the trap definitions was to maintain back-compatibility with=20 > existing 1.1 applications that implemented the trap defs=20 > using the original docs-if ext mib. With the deprecated=20 > objects removed, it is possible that these pre-rf mib v2=20 > draft 1.1 applications may not be compatible with the new trap defs.=20 >=20 This MIB isn't going to be backward compatible anyway since the MIB root = is going to change. The docs-if ext mib is rooted under docsdev while th= is mib will be rooted under mib-2. So, implementations will have to chan= ge regardless. > 3) The event mib is not in sync with the MTA event mgmt mib. > It is not really fair to compare them. The MTA event mgmt mib=20 > uses a generic definition for all informs and traps=20 > pertaining to MTA events. The Docsis event mib creates=20 > individual trap defs for each event. It may be a nice idea to=20 > add inform defs in the Docsis event mib though.=20 I think that the notifications defined in this MIB can be sent as a Trap = or an Inform. Although, the notification object all end with the term 't= rap' which would seems to imply that they should be sent as a trap. Whet= her a notification is sent as a Trap or Inform should be defined outside = of the MIB itself, I think. For example, the Notification MIB (RFC 3413)= supports the ability to do this. Thanks again for reviewing. greg -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org] On Behalf Of Raf= tus, David Sent: Thursday, April 29, 2004 11:15 AM To: Ipcdn List (E-mail) Subject: FW: [ipcdn] wg review of draft-ietf-ipcdn-docsisevent-mib-03.txt Hi,=20 Forwarding event mib review comments to the list.=20 Thanks,=20 Dave=20 -----Original Message-----=20 From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 Sent: Thursday, April 29, 2004 12:24 PM=20 To: Raftus, David=20 Cc: Greg Nakanishi (E-mail); Azlina Ahmad (E-mail)=20 Subject: RE: [ipcdn] wg review of draft-ietf-ipcdn-docsisevent-mib-03.txt= =20 Hi David,=20 Thank for your DOCSIS review, this is the most important. Can you still s= end your DOCSIS review comments to the list? This was requested by Bert a= s it is standard ietf process... Thanks again,=20 Jean-Fran=E7ois=20 > -----Original Message----- > From: Raftus, David [mailto:david.raftus@Terayon.com]=20 > Sent: Thursday, April 29, 2004 8:30 AM=20 > To: Jean-Francois Mule=20 > Cc: Greg Nakanishi (E-mail); Azlina Ahmad (E-mail); Raftus, David=20 > Subject: RE: [ipcdn] wg review of=20 > draft-ietf-ipcdn-docsisevent-mib-03.txt=20 >=20 >=20 > Hi Jean-Francois, >=20 > This event mib draft is actually not too different from the > v2 version created in Jan/03.=20 >=20 > I'm afraid I don't have the necessary background to evaluate > the mib according to compliance with the mib guidelines and=20 > conformance with ID-nits. Sorry for that. Therefore, I didn't=20 > CC my comments to the IPCDN list.=20 >=20 > I did examine the mib from a Docsis perspective though, and > have the following comments:=20 >=20 > 1) Not sure if the default value of NULL is appropriate for > the BITs defval for object docsDevCmTrapControl. This doesn't=20 > give any real guidance as to whether the traps should be=20 > enabled or disabled. The original value of 0x00, while=20 > perhaps not strictly conforming to the octet string nature of=20 > BITs, did signal that all traps default to off.=20 >=20 > 2) The intention of keeping the deprecated mib objects within > the trap definitions was to maintain back-compatibility with=20 > existing 1.1 applications that implemented the trap defs=20 > using the original docs-if ext mib. With the deprecated=20 > objects removed, it is possible that these pre-rf mib v2=20 > draft 1.1 applications may not be compatible with the new trap defs.=20 >=20 > 3) The event mib is not in sync with the MTA event mgmt mib. > It is not really fair to compare them. The MTA event mgmt mib=20 > uses a generic definition for all informs and traps=20 > pertaining to MTA events. The Docsis event mib creates=20 > individual trap defs for each event. It may be a nice idea to=20 > add inform defs in the Docsis event mib though.=20 >=20 > Again, sorry for not commenting on mib guidelines, etc. >=20 > Regards, > Dave=20 >=20 >=20 > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 > Sent: Thursday, April 08, 2004 1:05 PM=20 > To: Raftus, David=20 > Cc: Richard Woundy @ Comcast=20 > Subject: RE: [ipcdn] wg review of=20 > draft-ietf-ipcdn-docsisevent-mib-03.txt=20 >=20 > Dave, >=20 > Thanks a lot. > For your review, please consider the following:=20 > - compliance with mib guidelines check-list=20 > - conformance with ID-nits,=20 > - is this MIB in sync with the other ipcdn ID on event mgmt=20 > for MTAs:=20 > =20 > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-event > mess-03.txt=20 > - etc.=20 >=20 > Also, please send your comments to the ipcdn list. > thx,=20 > jean-francois.=20 =20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Sat May 15 13:24:39 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00938 for ; Sat, 15 May 2004 13:24:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BP2mf-0001Ri-7B for ipcdn-archive@odin.ietf.org; Sat, 15 May 2004 13:17:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4FHHDQC005536 for ipcdn-archive@odin.ietf.org; Sat, 15 May 2004 13:17:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BP2hd-0000rF-TY; Sat, 15 May 2004 13:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BP2ay-00087i-FA for ipcdn@optimus.ietf.org; Sat, 15 May 2004 13:05: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 NAA00301 for ; Sat, 15 May 2004 13:05:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BP2aw-0002Do-Ip for ipcdn@ietf.org; Sat, 15 May 2004 13:05:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BP2Zx-0001nY-00 for ipcdn@ietf.org; Sat, 15 May 2004 13:04:05 -0400 Received: from harrier.mail.pas.earthlink.net ([207.217.120.12]) by ietf-mx with esmtp (Exim 4.12) id 1BP2Yp-00011H-00 for ipcdn@ietf.org; Sat, 15 May 2004 13:02:55 -0400 Received: from h-68-164-80-226.snvacaid.dynamic.covad.net ([68.164.80.226] helo=oemcomputer) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BP2Yo-0006Gg-00 for ipcdn@ietf.org; Sat, 15 May 2004 10:02:54 -0700 Message-ID: <001501c43a9f$1bc01240$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Ipcdn List \(E-mail\)" References: Subject: Re: [ipcdn] wg review of draft-ietf-ipcdn-docsisevent-mib-03.txt Date: Sat, 15 May 2004 10:07:30 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Hi - > From: "Nakanishi Greg-MGI8179" > To: "'Eduardo Cardona'" ; "Raftus, David" ; "Ipcdn List (E-mail)" > Sent: Friday, May 14, 2004 2:52 PM > Subject: RE: [ipcdn] wg review of draft-ietf-ipcdn-docsisevent-mib-03.txt ... > Let's wait to hear what the MIB doctors say about the object name. > I'm OK with changing the name, if that's the recommendation. ... I agree that there don't seem to be any advantages to retaining the old name. Current practice strongly favors referring to these things as notifications. Not only can RFC 3413 dynamically control whether these things show up on the wire as informs or traps, but there's also the possibility that they may end up being logged (locally or remotely) using, for example, RFC 3014. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon May 17 18:00:26 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06184 for ; Mon, 17 May 2004 18:00:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPpze-0003SX-6j for ipcdn-archive@odin.ietf.org; Mon, 17 May 2004 17:49:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HLns3b013296 for ipcdn-archive@odin.ietf.org; Mon, 17 May 2004 17:49:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPpjs-0002jF-3A; Mon, 17 May 2004 17:33:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPp62-0000GV-F5 for ipcdn@optimus.ietf.org; Mon, 17 May 2004 16:52: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 QAA26090 for ; Mon, 17 May 2004 16:52:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPp60-00000Y-DE for ipcdn@ietf.org; Mon, 17 May 2004 16:52:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPp1G-0006br-00 for ipcdn@ietf.org; Mon, 17 May 2004 16:47:30 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1BPowY-0005S5-00 for ipcdn@ietf.org; Mon, 17 May 2004 16:42:38 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i4HKh3Gv005957 for ; Mon, 17 May 2004 13:43:03 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id i4HKfPA2006362 for ; Mon, 17 May 2004 15:41:26 -0500 Received: by ca25exm01 with Internet Mail Service (5.5.2657.2) id ; Mon, 17 May 2004 13:42:35 -0700 Message-ID: From: Nakanishi Greg-MGI8179 To: "'Randy Presuhn'" , "Ipcdn List \\(E-mail\\)" Subject: RE: [ipcdn] wg review of draft-ietf-ipcdn-docsisevent-mib-03.txt Date: Mon, 17 May 2004 13:42:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , OK, will change the object names to end in 'Notification' in the next rev of the draft. Thanks, greg -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org] On Behalf Of Randy Presuhn Sent: Saturday, May 15, 2004 10:08 AM To: Ipcdn List \(E-mail\) Subject: Re: [ipcdn] wg review of draft-ietf-ipcdn-docsisevent-mib-03.txt Hi - > From: "Nakanishi Greg-MGI8179" > To: "'Eduardo Cardona'" ; "Raftus, David" > ; "Ipcdn List (E-mail)" > Sent: Friday, May 14, 2004 2:52 PM > Subject: RE: [ipcdn] wg review of > draft-ietf-ipcdn-docsisevent-mib-03.txt ... > Let's wait to hear what the MIB doctors say about the object name. I'm > OK with changing the name, if that's the recommendation. ... I agree that there don't seem to be any advantages to retaining the old name. Current practice strongly favors referring to these things as notifications. Not only can RFC 3413 dynamically control whether these things show up on the wire as informs or traps, but there's also the possibility that they may end up being logged (locally or remotely) using, for example, RFC 3014. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue May 18 00:34:15 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28918 for ; Tue, 18 May 2004 00:34:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPwHX-0007HY-7V for ipcdn-archive@odin.ietf.org; Tue, 18 May 2004 00:32:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I4WlDB027993 for ipcdn-archive@odin.ietf.org; Tue, 18 May 2004 00:32:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPwFr-0006mm-RU; Tue, 18 May 2004 00:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPwBs-0005Br-Jl for ipcdn@optimus.ietf.org; Tue, 18 May 2004 00:26:57 -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 AAA28606 for ; Tue, 18 May 2004 00:26:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPwBh-0004fg-1f for ipcdn@ietf.org; Tue, 18 May 2004 00:26:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPwAh-0004Ib-00 for ipcdn@ietf.org; Tue, 18 May 2004 00:25:43 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BPw9u-0003am-00 for ipcdn@ietf.org; Tue, 18 May 2004 00:24:54 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id i4I4OLGe021096; Mon, 17 May 2004 22:24:21 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] Sig MIB, NCS SF Objects -1: CM or MTA config? Date: Mon, 17 May 2004 22:24:20 -0600 Message-ID: Thread-Topic: [ipcdn] Sig MIB, NCS SF Objects -1: CM or MTA config? Thread-Index: AcQoa4fbd5V1ZomvTKCScYzP0A5aTwFvlUvQA5isAOA= From: "Jean-Francois Mule" To: Cc: "Thomas Anders" X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I was hoping for more comments on the issue summary but since everyone = seems to agree, let's start separate threads. > 1/ Should the MTA MIB provide means to create dynamic DOCSIS=20 > SFs for NCS Signaling, or should it simply be left to the CM=20 > config file? I have polled a couple of MSOs deploying PacketCable voip service. = Everyone seems to be using static docsis SF in the CM config file to set = up special flows for NCS traffic.=20 If these MTA sig mib objects are not used today, do we need them at all? = If not, we can simply delete them and the issues raised by some of you = are closed as far as the SigMIB is concerned. Setting up NCS SF in the CM config - pros: o used by operators, proven and operationally preferred=20 o no security risks due to SCN name authorization o all special SF settings viewed by the cable data provider in one = config file o pre-provisioned on the CPE device for all embedded CM in E-MTAs, = whether or not the MTA telephony service is enabled and whether the MTA = boots up Setting up NCS SF in the MTA config - pros: o separate telephony from high speed data CPE config settings o more scalable (SF triggers for apps needing special QoS are = inherently part of the application level configuration) o pre-provisioned on the CMTS via SCN and on CPE device in the MTA = config file, activated only when MTA boots up Any additionals pros for one or the other? Any opinions on whether we should keep those objects at all? Thanks, Jean-Fran=E7ois=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue May 18 01:00:15 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29931 for ; Tue, 18 May 2004 01:00:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPwf3-0004Kv-0T for ipcdn-archive@odin.ietf.org; Tue, 18 May 2004 00:57:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I4v4ID016662 for ipcdn-archive@odin.ietf.org; Tue, 18 May 2004 00:57:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPwa9-0003W3-LY; Tue, 18 May 2004 00:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPwUD-0002FR-5V for ipcdn@optimus.ietf.org; Tue, 18 May 2004 00:45:53 -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 AAA29419 for ; Tue, 18 May 2004 00:45:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPwUA-000426-D0 for ipcdn@ietf.org; Tue, 18 May 2004 00:45:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPwTB-0003ef-00 for ipcdn@ietf.org; Tue, 18 May 2004 00:44:50 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BPwSS-0003FJ-00 for ipcdn@ietf.org; Tue, 18 May 2004 00:44:04 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id i4I4hXGe024201; Mon, 17 May 2004 22:43:33 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] Sig MIB, NCS SF Objects -2: SCN provisioning on CMTS Date: Mon, 17 May 2004 22:43:33 -0600 Message-ID: Thread-Topic: [ipcdn] Sig MIB, NCS SF Objects -2: SCN provisioning on CMTS Thread-Index: AcQoa4fbd5V1ZomvTKCScYzP0A5aTwFvlUvQA5isAOAAAPIjAA== From: "Jean-Francois Mule" To: Cc: , "Kevin Johns" X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > 2/ Are the DOCSIS Service Class Name provisioning on the CMTS=20 > (and all the associated policies to authorize flows based on=20 > SCN and other rules) too open to vendor differentiation,=20 > hence opening up security risks? Wg consensus seems to be that yes, this is way too open and more spec = langage is required to mandate some sort of rule-based authorization on = the CMTS. An Engineering Change has been submitted by Dave Flanagan of Motorola = and will be discussed in the PacketCable QoS team tomorrow. To provide = total transparency to the IETF ipcdn participants, here's the proposed = change: --- Affected spec:=20 PKT-SP-DQOS-I09-040402 http://www.packetcable.com/specifications/specifications10.html --- Old text:=20 section 3.2.5, titled "CMTS Authorization and Behavior" paragraph 5 If the PacketCable authorization module receives a bandwidth reservation = request without an authorization block, the CMTS MUST reject the request = with confirmation code "24: authorization failure".=20 --- New proposed text: If the PacketCable authorization module receives a bandwidth reservation = request without an authorization block, the CMTS MUST reject the request = with confirmation code "24: authorization failure".=20 Note that the above requirement applies to bandwidth requests processed = by the PacketCable authorization module. It does not preclude the use of = the DOCSIS authorization module to process other requests without an = authorization block. The PacketCable authorization module and DOCSIS = authorization module are logical functions of the CMTS that approve or = deny QoS parameters and classifiers. Conceptually, when a QoS request = arrives at the CMTS, the DOCSIS authorization module determines if the = request is to be processed within the DOCSIS authorization module itself = or hand it off to the PacketCable authorization module. The one comment I would make would be to add a normative MUST statement = on the CMTS to provide some kind of configuration settings for = authorizing DSx requests based on SCN (the idea expressed on the list = was that we don't care what specific mechanism is in place to = allow/allow-some/deny-all as long as there is such a mechanism). Comments appreciated. Jean-Fran=E7ois=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue May 18 02:46:51 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18581 for ; Tue, 18 May 2004 02:46:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPyHN-0001Gs-PD for ipcdn-archive@odin.ietf.org; Tue, 18 May 2004 02:40:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I6ejhc004855 for ipcdn-archive@odin.ietf.org; Tue, 18 May 2004 02:40:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPy9v-0008Hh-Cd; Tue, 18 May 2004 02:33:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPy50-000750-Hf for ipcdn@optimus.ietf.org; Tue, 18 May 2004 02:27:58 -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 CAA17498 for ; Tue, 18 May 2004 02:27:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPy4w-000410-Qs for ipcdn@ietf.org; Tue, 18 May 2004 02:27:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPy3r-0003ck-00 for ipcdn@ietf.org; Tue, 18 May 2004 02:26:48 -0400 Received: from adicia.telenet-ops.be ([195.130.132.56]) by ietf-mx with esmtp (Exim 4.12) id 1BPy2v-0003EC-00 for ipcdn@ietf.org; Tue, 18 May 2004 02:25:49 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by adicia.telenet-ops.be (Postfix) with SMTP id 625B244016 for ; Tue, 18 May 2004 08:25:44 +0200 (MEST) Received: from tcomlabs.com (D5E0B8ED.kabel.telenet.be [213.224.184.237]) by adicia.telenet-ops.be (Postfix) with ESMTP id 296FC440C4 for ; Tue, 18 May 2004 08:25:44 +0200 (MEST) Received: (qmail 5227 invoked from network); 18 May 2004 08:22:29 +0200 Received: from localhost (HELO gateway) (127.0.0.1) by localhost with SMTP; 18 May 2004 08:22:29 +0200 Received: from ([10.5.5.72]) by gateway.tcomlabs.com (MailMonitor for SMTP v1.2.2 ) ; Tue, 18 May 2004 08:22:28 +0200 (CEST) From: "David De Reu" To: "Jean-Francois Mule" , Subject: RE: [ipcdn] Sig MIB, NCS SF Objects -1: CM or MTA config? Date: Tue, 18 May 2004 08:25:43 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal In-Reply-To: Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > Setting up NCS SF in the CM config - pros: > o used by operators, proven and operationally preferred > o no security risks due to SCN name authorization > o all special SF settings viewed by the cable data provider in > one config file > o pre-provisioned on the CPE device for all embedded CM in > E-MTAs, whether or not the MTA telephony service is enabled and > whether the MTA boots up Another pro is that this mechanism also works for a standalone MTA. Wouldn't it be nice if we were able to use the same MIBs for both E-MTA a= nd S-MTA? Thanks, David _____________________________________________________ David De Reu tComLabs Stapelplein 70/004 =96 9000 Ghent =96 Belgium Tel: +32 9 269 22 91 =96 Fax: +32 9 329 31 74 www.tComLabs.com _____________________________________________________ _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue May 18 17:33:49 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20468 for ; Tue, 18 May 2004 17:33:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQC98-0005xx-MO for ipcdn-archive@odin.ietf.org; Tue, 18 May 2004 17:29:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ILTA6J022911 for ipcdn-archive@odin.ietf.org; Tue, 18 May 2004 17:29:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQBzK-0003xY-Ks; Tue, 18 May 2004 17:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQBqp-0001bG-Pl for ipcdn@optimus.ietf.org; Tue, 18 May 2004 17:10:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18717 for ; Tue, 18 May 2004 17:10:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQBqn-0004VC-Fz for ipcdn@ietf.org; Tue, 18 May 2004 17:10:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQBpk-0004Mp-00 for ipcdn@ietf.org; Tue, 18 May 2004 17:09:09 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BQBor-0004BL-00 for ipcdn@ietf.org; Tue, 18 May 2004 17:08:13 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id i4IL7eGe012185; Tue, 18 May 2004 15:07:42 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] Sig MIB, NCS SF Objects -1: CM or MTA config? Date: Tue, 18 May 2004 15:07:40 -0600 Message-ID: Thread-Topic: [ipcdn] Sig MIB, NCS SF Objects -1: CM or MTA config? Thread-Index: AcQ8oPmTkOITiaSyRaCFIW+1o2AuMgAeqW3g From: "Jean-Francois Mule" To: "David De Reu" , X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable David wrote: > Another pro is that this mechanism also works for a standalone MTA. Good point, yes, I will add it to the list. > Wouldn't it be nice if we were able to use the same MIBs for=20 > both E-MTA and S-MTA? Yes indeed but the QoS models for E-MTAs and S-MTAs are drastically different. The E-MTAs being deployed today use CM/MTA initiated DQoS SFs for voice media & static/dynamic SF for NCS. The S-MTAs are likely to use a proxied QoS model following the PacketCable MM spec. Jean-Francois. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed May 19 20:25:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00921 for ; Wed, 19 May 2004 20:25:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQbJj-0006iF-QG for ipcdn-archive@odin.ietf.org; Wed, 19 May 2004 20:21:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4K0LlUK025778 for ipcdn-archive@odin.ietf.org; Wed, 19 May 2004 20:21:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQbE8-00053x-6x; Wed, 19 May 2004 20:16:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNdDZ-0001lQ-MQ for ipcdn@optimus.ietf.org; Tue, 11 May 2004 15:47:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20756 for ; Tue, 11 May 2004 15:47:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNdDY-00023Q-4H for ipcdn@ietf.org; Tue, 11 May 2004 15:47:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNdCY-0001cq-00 for ipcdn@ietf.org; Tue, 11 May 2004 15:46:07 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BNdBW-0000od-00 for ipcdn@ietf.org; Tue, 11 May 2004 15:45:02 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 11 May 2004 11:50:28 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i4BJiUW9003882 for ; Tue, 11 May 2004 12:44:30 -0700 (PDT) Received: from bridavisw2k02 (dhcp-161-44-182-174.cisco.com [161.44.182.174]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIJ44856; Tue, 11 May 2004 15:44:29 -0400 (EDT) Message-Id: <200405111944.AIJ44856@flask.cisco.com> From: "Brian A. Davis" To: Date: Tue, 11 May 2004 15:44:32 -0400 Organization: Cisco Systems, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Thread-Index: AcQ3kGE+faYYcXvTSJSyM8NqvlX2vw== X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [ipcdn] Detecting CPE IPs via CMTS 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: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I've been looking through the current DOCSIS MIBs, and I don't see a way to currently get a list of CPE IP address via a CMTS MIB. Is there any current work in adding this functionality to the standard set of DOCSIS MIBs? Is there a current method I've overlooked? Thanks, Brian _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed May 19 20:44:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01877 for ; Wed, 19 May 2004 20:44:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQbe6-0003rg-ME for ipcdn-archive@odin.ietf.org; Wed, 19 May 2004 20:42:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4K0go3I014834 for ipcdn-archive@odin.ietf.org; Wed, 19 May 2004 20:42:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQbYU-0002Fz-SG; Wed, 19 May 2004 20:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQbVj-0001Tm-SP for ipcdn@optimus.ietf.org; Wed, 19 May 2004 20:34:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01451 for ; Wed, 19 May 2004 20:34:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQbVh-0002sA-Iu for ipcdn@ietf.org; Wed, 19 May 2004 20:34:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQbUq-0002lz-00 for ipcdn@ietf.org; Wed, 19 May 2004 20:33:17 -0400 Received: from paoakoavas04.cable.comcast.com ([208.17.35.53] helo=paoakoavas04.paoakoavas04.cable.comcast.com) by ietf-mx with esmtp (Exim 4.12) id 1BQbUQ-0002el-00 for ipcdn@ietf.org; Wed, 19 May 2004 20:32:50 -0400 Received: from ([10.20.62.20]) by paoakoavas04.paoakoavas04.cable with ESMTP ; Wed, 19 May 2004 20:32:20 -0400 Received: by pacdcexsmtp05.cable.comcast.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 May 2004 20:35:03 -0400 Message-ID: From: "Woundy, Richard" To: "'Brian A. Davis'" Cc: ipcdn@ietf.org Subject: RE: [ipcdn] Detecting CPE IPs via CMTS MIB? Date: Wed, 19 May 2004 20:24:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , One method is to use "ipNetToMediaNetAddress" from the ipNetToMediaTable (RFC 2011). Another, cleaner method is to use "docsSubMgtCpeIpAddr" from the docsSubMgtCpeIpTable in the Subscriber Management MIB (currently specified in ) . This assumes that the CMTS has been configured to learn IP addresses, e.g. "docsSubMgtCpeControlLearnable". -- Rich -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Brian A. Davis Sent: Tuesday, May 11, 2004 3:45 PM To: ipcdn@ietf.org Subject: [ipcdn] Detecting CPE IPs via CMTS MIB? I've been looking through the current DOCSIS MIBs, and I don't see a way to currently get a list of CPE IP address via a CMTS MIB. Is there any current work in adding this functionality to the standard set of DOCSIS MIBs? Is there a current method I've overlooked? Thanks, Brian _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu May 20 14:10:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08012 for ; Thu, 20 May 2004 14:10:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQrt3-0002Hu-5G for ipcdn-archive@odin.ietf.org; Thu, 20 May 2004 14:03:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KI3Lfu008772 for ipcdn-archive@odin.ietf.org; Thu, 20 May 2004 14:03:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQrfB-0007IH-MR; Thu, 20 May 2004 13:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQrV2-0004ow-JI for ipcdn@optimus.ietf.org; Thu, 20 May 2004 13:38:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05794 for ; Thu, 20 May 2004 13:38:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQrV0-0002zt-BT for ipcdn@ietf.org; Thu, 20 May 2004 13:38:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQrU2-0002qT-00 for ipcdn@ietf.org; Thu, 20 May 2004 13:37:31 -0400 Received: from pacdcoavas04.cable.comcast.com ([208.17.33.53]) by ietf-mx with esmtp (Exim 4.12) id 1BQrSZ-0002VT-00 for ipcdn@ietf.org; Thu, 20 May 2004 13:35:59 -0400 Message-ID: From: "Woundy, Richard" To: "IPCDN WG (E-mail)" Date: Thu, 20 May 2004 13:25:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [ipcdn] FW: New ID-Checklist to replace ID-nits 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: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , FYI only. I added a reference to the new Internet Draft checklist discussed below at . -- Rich -----Original Message----- From: ietf-announce-admin@ietf.org [mailto:ietf-announce-admin@ietf.org]On Behalf Of The IESG Sent: Thursday, May 20, 2004 9:34 AM Subject: New ID-Checklist to replace ID-nits As you probably all know, we have used the ID-nits for a few years to help you all to prepare your Internet-Drafts such that they will process faster through the AD-review, IETF Last Call and IESG approval process. The name was somewhat wrong in that it is more a serious checklist than merely "nits" (however, there are some nits too). The IESG, RFC-Editor and IANA have evaluated the checklist, and a new (improved) ID-Checklist is now available at http://www.ietf.org/ID-Checklist.html Please help us all by actually CHECKING your Internet-Draft BEFORE you pass it on to your AD and the IESG via a "request to publish". It will help to make the process go faster and reduce the workload on all of us if your document has been checked and complies with the guidance/rules in the ID-Checklist. Thanks, the IESG _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri May 21 17:30:33 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05148 for ; Fri, 21 May 2004 17:30:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRHTW-0007KH-Hi for ipcdn-archive@odin.ietf.org; Fri, 21 May 2004 17:22:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LLMgfI028150 for ipcdn-archive@odin.ietf.org; Fri, 21 May 2004 17:22:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRHLZ-0003WL-J6; Fri, 21 May 2004 17:14:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRHCH-00013B-Am for ipcdn@optimus.ietf.org; Fri, 21 May 2004 17:04:53 -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 RAA03317 for ; Fri, 21 May 2004 17:04:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRHCD-0004OL-Bm for ipcdn@ietf.org; Fri, 21 May 2004 17:04:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRHBG-0004HF-00 for ipcdn@ietf.org; Fri, 21 May 2004 17:03:50 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BRHAR-000449-00 for ipcdn@ietf.org; Fri, 21 May 2004 17:02:59 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id i4LL2RGe004405; Fri, 21 May 2004 15:02:27 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] Sig MIB, NCS SF Objects -1: CM or MTA config? Date: Fri, 21 May 2004 15:02:27 -0600 Message-ID: Thread-Topic: [ipcdn] Sig MIB, NCS SF Objects -1: CM or MTA config? Thread-Index: AcQ8oPmTkOITiaSyRaCFIW+1o2AuMgAeqW3gAJbDqhA= From: "Jean-Francois Mule" To: "David De Reu" Cc: X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Fyi, I am trying to get formal input from some MSOs on whether they want = to use the MTA NCS SF mechanism in the future. If I don't get any = positive responses, I see no reason why we should keep these objects at = this point in the development of this mib. I don't expect much until June 9. Jean-Fran=E7ois=20 > -----Original Message----- > From: Jean-Francois Mule=20 > Sent: Tuesday, May 18, 2004 3:08 PM > To: David De Reu; ipcdn@ietf.org > Subject: RE: [ipcdn] Sig MIB, NCS SF Objects -1: CM or MTA config? >=20 >=20 > David wrote: > > Another pro is that this mechanism also works for a standalone MTA. > Good point, yes, I will add it to the list. >=20 > > Wouldn't it be nice if we were able to use the same MIBs for > > both E-MTA and S-MTA? > Yes indeed but the QoS models for E-MTAs and S-MTAs are=20 > drastically different. The E-MTAs being deployed today use=20 > CM/MTA initiated DQoS SFs for voice media & static/dynamic SF=20 > for NCS. The S-MTAs are likely to use a proxied QoS model=20 > following the PacketCable MM spec. >=20 > Jean-Francois. >=20 > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn >=20 >=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn