From ipcdn-bounces@ietf.org Fri Apr 1 15:54:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14866 for ; Fri, 1 Apr 2005 15:54:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHTHR-00056d-ST for ipcdn-archive@ietf.org; Fri, 01 Apr 2005 16:02:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHT8R-0005EI-V4; Fri, 01 Apr 2005 15:52:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHT8M-0005Al-Mo for ipcdn@megatron.ietf.org; Fri, 01 Apr 2005 15:52:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14231 for ; Fri, 1 Apr 2005 15:52:48 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHTFk-0004gY-Vw for ipcdn@ietf.org; Fri, 01 Apr 2005 16:00:29 -0500 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 j31KqYDW011100; Fri, 1 Apr 2005 13:52:39 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] docsDevEvReporting functionality and conflicts Date: Fri, 1 Apr 2005 13:52:36 -0700 Message-ID: Thread-Topic: [ipcdn] docsDevEvReporting functionality and conflicts Thread-Index: AcUmbuvdYj+IKCNmQ06DD2Wdr/pwHAQja6Fw From: "Jean-Francois Mule" To: "Marez Kevin-MGI1375" , X-Approved: ondar X-Spam-Score: 0.3 (/) X-Scan-Signature: 17cf8eab1d6bbd2874a56f9e3554d91d X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1722450276==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: df1883a27a831c1ea5e8cfe5eb3ad38e This is a multi-part message in MIME format. --===============1722450276== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C536FC.BC3E781A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C536FC.BC3E781A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have not seen any response or comment on Kevin's proposal. The approach summarized below seems to address Randy's concern and looks ok to me. =20 Any comments from anyone? =20 Jean-Francois =20 _____ =20 From: Marez Kevin-MGI1375 [mailto:Kevin.Marez@motorola.com]=20 Sent: Friday, March 11, 2005 12:13 PM To: 'ipcdn@ietf.org' Subject: [ipcdn] docsDevEvReporting functionality and conflicts =20 To all: =20 There is a problem with the description of the docsDevEvReporting MIB description and the conflicts it has with RFC3413 and RFC3014. =20 docsDevEvReporting dictates the logging mechanism(s) that are to be invoked when an event occurs (trap, syslog, local, etc). However, RFC3413 also specifies similar functionality; more specifically with the snmpNotify table and the snmpNotifyType object listing the enumerated types of trap(1) and inform(2). Additionally, RFC3014 specifies a mechanism for the management of notification/event logging. Taking these two RFCs into account essentially removes all but the syslog(2) functionality of the docsDevEvReporting object. =20 My proposal would be to add another enumerated type (bit) for stdInterface(9) which would indicate the usage of RFC3413/RFC3014 mechanisms for notifications. There should be no problems with concurrent usage/support of both mechanisms so it would be possible to perform notifications in both places. Or, do we want to consider this being an xor situation? It would be necessary to exclude syslog(2) in this case, since neither RFC3413 nor RFC3014 covers this functionality. Essentially, (stdInterface && syslog) XOR (local && traps && localVolatile). =20 Does anyone have any other suggestions on how to address the conflicts that have been created between docsDevEvReporting functionality and RFC3413/RFC3014? =20 Thanks for your time and consideration on this issue, =20 Kevin =20 ------_=_NextPart_001_01C536FC.BC3E781A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

I have = not seen any response or comment on Kevin’s proposal. The approach = summarized below seems to address Randy’s concern and looks ok to = me.

 

Any = comments from anyone?

 

Jean-Francois

 

From: Marez Kevin-MGI1375 [mailto:Kevin.Marez@motorola.com]
Sent: Friday, March 11, = 2005 12:13 PM
To: 'ipcdn@ietf.org'
Subject: [ipcdn] docsDevEvReporting functionality and = conflicts

 

To all:

 

There is a problem with the description of the docsDevEvReporting MIB description and the conflicts it has = with RFC3413 and RFC3014.

 

docsDevEvReporting dictates the logging mechanism(s) = that are to be invoked when an event occurs (trap, syslog, local, etc).  However, RFC3413 also specifies similar functionality; more specifically = with the snmpNotify table and the snmpNotifyType object listing the = enumerated types of trap(1) and inform(2).  Additionally, RFC3014 specifies a = mechanism for the management of notification/event logging.  Taking these two = RFCs into account essentially removes all but the syslog(2) functionality of the docsDevEvReporting object.

 

My proposal would be to add another enumerated = type (bit) for stdInterface(9) which would indicate the usage of RFC3413/RFC3014 mechanisms for notifications.  There should be no = problems with concurrent usage/support of both mechanisms so it would be possible = to perform notifications in both places.  Or, do we want to consider = this being an xor situation?  It would be necessary to exclude syslog(2) = in this case, since neither RFC3413 nor RFC3014 covers this = functionality.  Essentially, (stdInterface && syslog) XOR (local && = traps && localVolatile).

 

Does anyone have any other suggestions on how to = address the conflicts that have been created between docsDevEvReporting = functionality and RFC3413/RFC3014?

 

Thanks for your time and consideration on this = issue,

 

Kevin

 

------_=_NextPart_001_01C536FC.BC3E781A-- --===============1722450276== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============1722450276==-- From ipcdn-bounces@ietf.org Fri Apr 1 16:31:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23101 for ; Fri, 1 Apr 2005 16:31:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHTqk-0008I3-LU for ipcdn-archive@ietf.org; Fri, 01 Apr 2005 16:38:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHTht-0007jC-03; Fri, 01 Apr 2005 16:29:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHThr-0007j7-8V for ipcdn@megatron.ietf.org; Fri, 01 Apr 2005 16:29:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22994 for ; Fri, 1 Apr 2005 16:29:29 -0500 (EST) Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHTpF-0008Fm-KD for ipcdn@ietf.org; Fri, 01 Apr 2005 16:37:10 -0500 Received: from ([10.20.9.174]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.9935065; Fri, 01 Apr 2005 16:28:49 -0500 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Apr 2005 16:28:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] docsDevEvReporting functionality and conflicts Date: Fri, 1 Apr 2005 16:28:47 -0500 Message-ID: Thread-Topic: [ipcdn] docsDevEvReporting functionality and conflicts Thread-Index: AcUmbuvdYj+IKCNmQ06DD2Wdr/pwHAQja6FwAABooxA= From: "Woundy, Richard" To: "Jean-Francois Mule" , "Marez Kevin-MGI1375" X-OriginalArrivalTime: 01 Apr 2005 21:28:49.0613 (UTC) FILETIME=[CB5A87D0:01C53701] X-Spam-Score: 0.4 (/) X-Scan-Signature: f251f249fc9a04067ce354aa0943ab98 Cc: ipcdn@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1103851027==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: 19c92f723dac1bcdd68591cc46e38e95 This is a multi-part message in MIME format. --===============1103851027== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C53701.CA105BF8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C53701.CA105BF8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, =20 Kevin's proposal also looks good to me. =20 Kevin and I (mostly Kevin :^) are working on the actual MIB module changes to make this happen. In particular, if the RFC 3413/RFC 3014 notification MIBs are used per stdInterface(9), we specify that the trap(1) and inform(2) bits are ignored. =20 We plan to submit a revised internet-draft today or Monday (at the latest), so please respond if this approach is not acceptable. =20 Here is the proposed revised definition: =20 docsDevEvReporting OBJECT-TYPE SYNTAX BITS { local(0), traps(1), syslog(2), localVolatile(8), stdInterface(9) } MAX-ACCESS read-write STATUS current DESCRIPTION "Defines the action to be taken on occurrence of this event class. Implementations may not necessarily support all options for all event classes, but at minimum must allow traps and syslogging to be disabled. If the local(0) bit is set, then log to the internal log and update non-volatile store, for backward compatibility with the original RFC 2669 definition. If the traps(1) bit is set, then generate an SNMP trap, and if the syslog(2) bit is set, then send a syslog message (assuming the syslog address is set). If the localVolatile(8) bit is set, then log to the internal log without updating non-volatile store. If the stdInterface(9) bit is set, then the agent ignores all other bits except the local(0), syslog(2) and localVolatile(8) bits. Setting the stdInterface(9) bit indicates that RFC3413 and RFC3014 are being used to control event reporting mechanisms. =20 Any attempt to SET the traps(1) or syslog(2) bits without setting the local(0) or localVolatile(8) bits MUST result in an error being generated." REFERENCE "RFC 3413 and RFC 3014" ::=3D { docsDevEvControlEntry 2 } =20 -- Rich -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Jean-Francois Mule Sent: Friday, April 01, 2005 3:53 PM To: Marez Kevin-MGI1375; ipcdn@ietf.org Subject: RE: [ipcdn] docsDevEvReporting functionality and conflicts =09 =09 I have not seen any response or comment on Kevin's proposal. The approach summarized below seems to address Randy's concern and looks ok to me. =20 Any comments from anyone? =20 Jean-Francois =20 =09 ________________________________ From: Marez Kevin-MGI1375 [mailto:Kevin.Marez@motorola.com]=20 Sent: Friday, March 11, 2005 12:13 PM To: 'ipcdn@ietf.org' Subject: [ipcdn] docsDevEvReporting functionality and conflicts =20 To all: =20 There is a problem with the description of the docsDevEvReporting MIB description and the conflicts it has with RFC3413 and RFC3014. =20 docsDevEvReporting dictates the logging mechanism(s) that are to be invoked when an event occurs (trap, syslog, local, etc). However, RFC3413 also specifies similar functionality; more specifically with the snmpNotify table and the snmpNotifyType object listing the enumerated types of trap(1) and inform(2). Additionally, RFC3014 specifies a mechanism for the management of notification/event logging. Taking these two RFCs into account essentially removes all but the syslog(2) functionality of the docsDevEvReporting object. =20 My proposal would be to add another enumerated type (bit) for stdInterface(9) which would indicate the usage of RFC3413/RFC3014 mechanisms for notifications. There should be no problems with concurrent usage/support of both mechanisms so it would be possible to perform notifications in both places. Or, do we want to consider this being an xor situation? It would be necessary to exclude syslog(2) in this case, since neither RFC3413 nor RFC3014 covers this functionality. Essentially, (stdInterface && syslog) XOR (local && traps && localVolatile). =20 Does anyone have any other suggestions on how to address the conflicts that have been created between docsDevEvReporting functionality and RFC3413/RFC3014? =20 Thanks for your time and consideration on this issue, =20 Kevin =20 ------_=_NextPart_001_01C53701.CA105BF8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Folks,
 
Kevin's proposal also looks good to=20 me.
 
Kevin=20 and I (mostly Kevin :^) are working on the actual MIB module changes to = make=20 this happen. In particular, if the RFC 3413/RFC 3014 notification MIBs = are used=20 per stdInterface(9), we specify that the trap(1) and inform(2) bits are=20 ignored.
 
We=20 plan to submit a revised internet-draft today or Monday (at the latest), = so=20 please respond if this approach is not acceptable.
 
Here=20 is the proposed revised definition:
 
docsDevEvReporting=20 OBJECT-TYPE
        SYNTAX BITS=20 {
           =20 local(0),
          =  =20 traps(1),
          =  =20 syslog(2),
          = ; =20 localVolatile(8),
        &nbs= p;  =20 stdInterface(9)
       =20 }
        MAX-ACCESS =20 read-write
       =20 STATUS     =20 current
       =20 DESCRIPTION
         &nbs= p; =20 "Defines the action to be taken on occurrence of=20 this
           = ;    =20 event class.  Implementations may not=20 necessarily
         &nbs= p;     =20 support all options for all event classes, but=20 at
           &= nbsp;   =20 minimum must allow traps and syslogging to=20 be
           &= nbsp;   =20 disabled.
          =      =20 If the local(0) bit is set, then log to the=20 internal
          &= nbsp;    =20 log and update non-volatile store, for=20 backward
          &= nbsp;    =20 compatibility with the original RFC 2669=20 definition.
         &nbs= p;     =20 If the traps(1) bit is set, then=20 generate
          &= nbsp;    =20 an SNMP trap, and if the syslog(2) bit is set,=20 then
           = ;    =20 send a syslog message (assuming the syslog=20 address
          &n= bsp;    =20 is set).  If the localVolatile(8) bit is set,=20 then
           = ;    =20 log to the internal log without updating=20 non-volatile
         &nb= sp;     =20 store.  If the stdInterface(9) bit is set, then=20 the
           =     =20 agent ignores all other bits except the=20 local(0),
          =      =20 syslog(2) and localVolatile(8) bits.  Setting=20 the
           =     =20 stdInterface(9) bit indicates that RFC3413=20 and
           =     =20 RFC3014 are being used to control event=20 reporting
          =      =20 mechanisms.
         &nbs= p;     =20
           &nb= sp;   =20 Any attempt to SET the traps(1) or syslog(2)=20 bits
           = ;    =20 without setting the local(0) or=20 localVolatile(8)
         = ;      =20 bits MUST result in an error being=20 generated."
       =20 REFERENCE
          =  =20 "RFC 3413 and RFC 3014"
        = ::=3D {=20 docsDevEvControlEntry 2 }
 
--=20 Rich
-----Original Message-----
From:=20 ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of = Jean-Francois Mule
Sent: Friday, April 01, 2005 3:53=20 PM
To: Marez Kevin-MGI1375; = ipcdn@ietf.org
Subject: RE:=20 [ipcdn] docsDevEvReporting functionality and = conflicts

I = have not=20 seen any response or comment on Kevin’s proposal. The approach = summarized=20 below seems to address Randy’s concern and looks ok to=20 me.

 

Any = comments=20 from anyone?

 

Jean-Francois

 

From: Marez=20 Kevin-MGI1375 [mailto:Kevin.Marez@motorola.com]
Sent: Friday, March 11, 2005 = 12:13=20 PM
To:=20 'ipcdn@ietf.org'
Subject:=20 [ipcdn] docsDevEvReporting functionality and=20 conflicts

 

To=20 all:

 

There is a problem with = the=20 description of the docsDevEvReporting MIB description and the = conflicts it has=20 with RFC3413 and RFC3014.

 

docsDevEvReporting = dictates the=20 logging mechanism(s) that are to be invoked when an event occurs = (trap,=20 syslog, local, etc).  However, RFC3413 also specifies similar=20 functionality; more specifically with the snmpNotify table and the=20 snmpNotifyType object listing the enumerated types of trap(1) and=20 inform(2).  Additionally, RFC3014 specifies a mechanism for the=20 management of notification/event logging.  Taking these two RFCs = into=20 account essentially removes all but the syslog(2) functionality of the = docsDevEvReporting object.

 

My proposal would = be to add=20 another enumerated type (bit) for stdInterface(9) which = would=20 indicate the usage of RFC3413/RFC3014 mechanisms for = notifications. =20 There should be no problems with concurrent usage/support of both = mechanisms=20 so it would be possible to perform notifications in both places.  = Or, do=20 we want to consider this being an xor situation?  It would be = necessary=20 to exclude syslog(2) in this case, since neither RFC3413 nor RFC3014 = covers=20 this functionality.  Essentially, (stdInterface && = syslog)=20 XOR (local && traps &&=20 localVolatile).

 

Does anyone have any = other=20 suggestions on how to address the conflicts that have been created = between=20 docsDevEvReporting functionality and=20 RFC3413/RFC3014?

 

Thanks for your time and = consideration on this issue,

 

Kevin

 

<= /BODY> ------_=_NextPart_001_01C53701.CA105BF8-- --===============1103851027== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============1103851027==-- From ipcdn-bounces@ietf.org Fri Apr 1 17:04:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26298 for ; Fri, 1 Apr 2005 17:04:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHUNa-0001M8-BY for ipcdn-archive@ietf.org; Fri, 01 Apr 2005 17:12:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHUEf-0006AT-KK; Fri, 01 Apr 2005 17:03:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHUEb-0006AD-8e for ipcdn@megatron.ietf.org; Fri, 01 Apr 2005 17:03:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26174 for ; Fri, 1 Apr 2005 17:03:18 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHULy-0001Gw-JC for ipcdn@ietf.org; Fri, 01 Apr 2005 17:11:00 -0500 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 j31M34DU026205; Fri, 1 Apr 2005 15:03:05 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 1 Apr 2005 15:03:04 -0700 Message-ID: Thread-Topic: IETF#62 - IPCDN wg minutes Thread-Index: AcU3BpsgPp1a+ydaQrGg/uIH8p1qJQ== From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.5 (/) X-Scan-Signature: bec09d1709ba59869cec93c1a1c207e5 Cc: Eduardo Cardona , Jean-Francois Mule , Gordon.Beacham@motorola.com, enechamkin@broadcom.com, gnakanishi@motorola.com, bwijnen@lucent.com, "Richard Woundy @ Comcast" , Kevin.Marez@motorola.com Subject: [ipcdn] IETF#62 - IPCDN wg minutes X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0468553443==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 35b3af3416a6d11f1eee5b96bdee48c4 This is a multi-part message in MIME format. --===============0468553443== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C53706.946750DC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C53706.946750DC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable See below, thank you again Greg for taking notes during the meeting.=20 Note that the jabber log was also used. =20 I also copy the folks who have some action items and that includes Rich and I ;) =20 Rich and Jean-Francois IPCDN co-chairs. =20 ------------------------------------------ IETF IPCDN Meeting Notes IETF#62, IP over Cable Data Networks WG Minneapolis, USA Tuesday, March 8, 2005 =20 Reported by Greg Nakanishi (gnakanishi@motorola.com) Edited by Jean-Francois Mule' (jfm@cablelabs.com) =20 =20 --- WG Meeting Summary --- ------------------ About ten IETF participants attended the IPCDN WG meeting at IETF #62 in Minneapolis on March 8 2005. Two participants joined the wg meeting via the jabber session. Total meeting time was about one hour. =20 The meeting materials are consolidated into 1 deck of slides and are provided as part of the IETF proceedings. They are also posted at http://www.ipcdn.org/meetings.html =20 The slides provided for the meeting contain lots of details on the wg status and Internet-Draft issues. The present notes do not duplicate the slide content, please read the slides for details. The action items (AI) are outlined and called out in the text below. =20 =20 1/ Agenda Bashing Greg Nakanishi volunteered to be the note taker. A jabber session was also initiated with two participants: Bert Wijnen, AD and area advisor for ipcdn and Eduardo Cardona, current editor of a couple of Internet-Drafts. The jabber chat room was: ipcdn@conference.ietf.jabber.com; Rich Woundy and Jean-Francois Mule volunteered to be the jabber scribes during the meeting. The proposed agenda was accepted by the wg without modifications, it is also available at: http://www.ipcdn.org/meetings.html =20 =20 2/ Administration We reviewed the WG Charter & milestones (see slide 4) and http://www.ietf.org/html.charters/ipcdn-charter.html =20 The chairs proposed to update milestone for the DOCSIS Cable Device MIB v2 and the PacketCable MIBs to June 2005, that is be "wg done" by June 2005 and formerly request publication which will start Ad and IESG review. Bert commented that June 2005 seems aggressive for completing the CD MIB (via jabber). While this may be aggressive given the past pace, with Kevin Marez as the new editor and the ad-hoc session with Randy Presuhn we were able to organize at IETF to address some of Randy's mib doctor comments on the draft, this should still be doable. # AI: wg chairs to reflect new milestones when proposing updated IPCDN # charter to AD =20 Bert also added that he hoped to pick up MIB reviews for the event MIB and the RFIv2 MIB modules shortly after IETF. # AI: wg chairs to follow-up with Bert and MIB co-authors to ensure # mib doctors have been assigned to those 2 IPCDN DOCSIS I-Ds # AI completed on 4/1/2005. =20 =20 + Concluding the IPCDN CableHome work items The chairs (Jean-Francois speaking at the mike) proposed that the WG drops the CableHome MIBs from the charter. There were 6 expired Internet-Drafts: draft-ietf-ipcdn-cable-gateway-config-mib-00 draft-ietf-ipcdn-cable-gateway-tools-mib-00 draft-ietf-ipcdn-cable-gateway-device-mib-00 draft-ietf-ipcdn-cable-gateway-addressing-mib-00 draft-ietf-ipcdn-cable-gateway-security-mib-00 draft-ietf-ipcdn-cable-gateway-qos-mib-00 =20 =20 The rationale for concluding all the CH work items was discussed later in the meeting and is documented on slide 41 of the meeting materials. The AD Bert asked whether the CableHome mib modules had been rooted under mib-2 at CableLabs (the answer is no which means from an IETF point of view, we do not have the same worries as with some of the earlier DOCSIS MIBs. =3D> There was no objection from the WG participants in the room. =3D> Via jabber, Bert accepted our explanations and agreed to reflect the WG decision by modifying the charter. # Decision: wg and AD agreement to conclude the IPCDN CableHome work # AI: wg chairs to propose new updated IPCDN charter reflecting the # change =20 =20 3/ IPCDN DOCSIS mibs =20 + DOCSIS Cable Device MIB version 2 draft-ietf-ipcdn-device-mibv2-07.txt Editor: Kevin Marez =20 http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-07.txt We spent much of the meeting time discussing the update of the DOCSIS cable device mibv2 and the open issues to advance this Internet-Draft. Most of those issues were raised by the mib doctor review from Randy. =20 Note that the complete enumerated listing of all the draft07 modifications is available at: http://www.ipcdn.org/meetings/cdmib-07-changes.doc or http://tools.ietf.org/wg/ipcdn/ and a diff between draft06 and draft07 is at: http://tools.ietf.org/wg/ipcdn/draft-ietf-ipcdn-device-mibv2/draft-ietf- ipcdn-device-mibv2-07-from-06.diff.html =20 - Open issue #1: MIB compile warning in compliance statement Multiple entries in the docsDevGroups are deprecated ex: docsDevNmAccessGroup, docsDevSoftwareGroup, etc. The MIB compiler complains with warning messages about compliance statements that referred to deprecated objects. Rich indicated he thought the inclusion of deprecated groups was not proper practice, but that it was not prohibited per se. Rich added that in the mib review guidelines, page 31, it says something about it. >From page 31: | - The status of a compliance statement is independent of the status | of its members. Thus, a current compliance statement MAY refer to | deprecated object groups or notification groups. This may be | desirable in certain cases, e.g., a set of widely-deployed object | or notification groups may be deprecated when they are replaced by | a more up-to-date set of definitions, but compliance statements | that refer to them may remain current in order to encourage | continued implementation of the deprecated groups. =20 Bert commented that this practice is not allowed. # AI: Kevin Marez to look into this issue further and propose a new # compliance statement addressing the issue. =20 - Open issue #2 The docsDevEvReporting object description doesn't mesh well with the RFC3413 guidelines. This was reported by Randy. RFC3413 and RFC3014 overlaps with some logging objects in the CD MIB. During the meeting, Kevin proposed that a clarification can be made in the CD MIB that indicates that the CD MIB object only be applicable when running in SNMPv1/2 mode and that RFC3413 be applicable when running in Coexistence mode. Eduardo commented via jabber that that proposal may not work. # AI: Kevin to post pb statement and resolution to the list # done on 3/11 Kevin also met with Randy after the IPCDN meeting and actually proposed the following in an email sent on March 11 to the ipcdn list: Kevin wrote: >My proposal would be to add another enumerated type (bit) for >stdInterface(9) which would indicate the usage of RFC3413/RFC3014 >mechanisms for notifications. There should be no problems with >concurrent usage/support of both mechanisms so it would be possible >to perform notifications in both places. Or, do we want to consider >this being an xor situation? It would be necessary to exclude >syslog(2) in this case, since neither RFC3413 nor RFC3014 covers this >functionality. Essentially, (stdInterface && syslog) XOR (local && >traps && localVolatile). =20 - Open Issue #3 The relationship between docsDevEventGroup, docsDevEventGroupv2 and RFC3014 needs to be defined. There was no real discussion on this item during the ipcdn meeting. # AI: Kevin to address this issue on the list together with issue #3. =20 =20 - Open Issue #4: What is the purpose of the docsDevFilterPolicyObsoleteGroup group? # Decision: since the objects have been obsoleted, we agreed to remove # the group entirely. If anyone objects to Kevin's recommendation, # please send your comments to the list. =20 =20 + RF MIB v2 draft-ietf-ipcdn-docs-rfmibv2-13.txt Editor: Eduardo Cardona =20 http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-13.txt We went through the slides which document the updates in draft 13. A number of issues need to be resolved to release what will hopefully be the last draft (see slide 18-21). Rich asked if anyone had questions or comments on the changes made to the draft: nobody had any comments. # AI: Eduardo to close the issues by proposing resolutions to the list # and release draft14 before June. =20 =20 + DOCSIS Event Notification MIB draft-ietf-ipcdn-docsisevent-mib-06.txt Editor: Greg Nakanishi =20 http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docsisevent-mib-06. txt =20 Greg commented that all AD comments were incorporated in draft06. Bert should provide an additional review shortly after IETF#62. Bert asked the chairs to remind him. # AI: Bert to do a final check on draft 06 of the ipcdn docsis event mib # AI: chairs to remind Bert (done on 4/1/2005). =20 4/ IPCDN IPCablecom/PacketCable MIB Updates =20 + PacketCable/IPCablecom MTA MIB draft-ietf-ipcdn-pktc-mtamib-06.txt =20 http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-mtamib-06.txt =20 The current status on MTA MIB draft 06 was presented by Jean-Francois. A number of comments were made by Bert on draft06 (see slide 31). The next step is to update the draft. # AI: MTA MIB authors to update the draft by the end of May and # release draft07. =20 =20 + PacketCable/IPCablecom Signaling MIB draft-ietf-ipcdn-pktc-signaling-08.txt =20 http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-08.t xt =20 Sumanth is taking over editorship from Gordon Beacham (many thanks to Gordon for leading the 7 revisions of the draft to date). List of changes in draft07: http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01594.html =20 Rich asked about the txGain and rxGain objects. His understanding is that most vendors implement equivalent objects in private MIBs. He is not concerned that these parameters cannot be set dynamically. It is OK to configure them at device startup. Some operators had to reduce the gain to reduce/prevent echo on the line. Note that a patent disclosure was brought to the attention of the WG by Jean-Francois Mule, ipcdn co-chair http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01593.html. =20 There are no pending issues on this draft. # Decision: it was agreed by Bert and the chairs to issue a new WG # Last Call as the next step. =20 + PacketCable/IPCablecom Management Event MIB draft-ietf-ipcdn-pktc-eventmess-04.txt =20 http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-eventmess-04.t xt =20 Sumanth also took over the editorship of this draft. The MIB is not widely implemented or tested at CableLabs to date (as it is not a core requirement for PacketCable 1.0). The MIB functionality will become mandatory for PacketCable 1.5 so Jean-Francois expressed interest in advancing this MIB module to WG last call ASAP.s =20 Rich asks if this is the version of the MIB that gets rid of the distinction between fixed and programmable events. Answer is yes. =20 Bert commented that if this MIB is being implemented it (under the CableLabs root while awaiting ipcdn RFC), it is better to get some MIB doctor review ASAP. =20 # AI: chairs to send a note to request review from Randy and/or Bert =20 5/ CableHome MIB modules The chairs would like to discuss the withdrawal of all the CableHome MIB Ids from our IETF IPCDN charter with the wg participants. We will then consider make this proposal to the ADs. =20 There have been no updates to the IETF Internet-Drafts since June 2003. Bert asked if there is no activity in both IETF and CableLabs. Jean-Francois indicated that there has been some changes within the CableLabs MIBs. After consulting with some vendors participant in IETF and the internal CableLabs CableHome team in February 2005 (before IETF#62), there is not enough vendor or CableLabs support to advance those MIBs in IETF: we cannot find any committed resources to do this. see slide 41. Burt asks if the CableLabs CableHome MIBs were rooted under MIBII. The answer is 'no', there are under the CableLabs enterprise OID. Bert stated that if that is the case, we don't have to worry about it as much as we did for the DOCSIS mibs (from an IETF point of view). Rich Woundy and Greg N agree that the best path forward is to remove them from the charter. Bert accepted the chair proposal and is ok with charter update to remove them. =20 As indicated in section 2/ of these notes: # Decision: wg and AD agreement to conclude the IPCDN CableHome work # AI: wg chairs to propose new updated IPCDN charter reflecting the # change =20 =20 6/ IPCDN WG next steps Beyond the action items noted above and implementation of the various decisions the wg agreed to, the following is our work plan: - Finish all DOCSIS MIBs by June 2004 - Request publication for PacketCable/IPCablecom MTA MIB PacketCable/IPCablecom Signaling MIB - Advance expert + mib doctor reviews for Management Event MIB for MTAs - Revise IPCDN Charter Milestones =20 >.end of the IETF#62 ipcdn meeting notes ------------------------------------------ =20 =20 ------_=_NextPart_001_01C53706.946750DC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
See below, thank you again Greg for taking =
notes during the meeting. 
Note that =
the jabber log was also used.
 
I also =
copy the folks who have some action items and that includes Rich and I =
;)
 
Rich and =
Jean-Francois
IPCDN =
co-chairs.
 
------------------------------------------
IETF =
IPCDN Meeting Notes
IETF#62, =
IP over Cable Data Networks =
WG
Minneapolis, =
USA
Tuesday, =
March 8, 2005
 
Reported =
by Greg Nakanishi =
(gnakanishi@motorola.com)
Edited by =
Jean-Francois Mule' =
(jfm@cablelabs.com)
 
 
<=
font
size=3D2 color=3Dseagreen face=3D"Courier New">--- WG Meeting =
Summary
--- =
------------------
About ten =
IETF participants attended the IPCDN WG meeting at IETF =
#62
in =
Minneapolis on March 8 2005. Two =
participants joined the wg =
meeting
via the =
jabber session. Total meeting time was about one =
hour.
 
The =
meeting materials are consolidated into 1 deck of slides and =
are
provided =
as part of the IETF proceedings. They are also posted =
at
http://www.ipcdn.org/meetings=
.html
 
The =
slides provided for the meeting contain lots of details on =
the
wg status =
and Internet-Draft issues. The present notes do =
not
duplicate =
the slide content, please read the slides for =
details.
The =
action items (AI) are outlined and called out in the text =
below.
 
 
<=
font
size=3D2 color=3D"#804040" face=3D"Courier New">1/ Agenda =
Bashing
Greg =
Nakanishi volunteered to be the note =
taker.
A jabber =
session was also initiated with two participants: =
Bert
Wijnen, =
AD and area advisor for ipcdn and Eduardo Cardona, =
current
editor of =
a couple of Internet-Drafts. The jabber chat room =
was:
ipcdn@conference.ietf.jabber.com; Rich Woundy =
and Jean-Francois =
Mule
volunteered to be the jabber scribes during =
the meeting.
The =
proposed agenda was accepted by the wg without modifications, =
it
is also =
available at: http://www.ipcdn.org/meetings=
.html
 
 
<=
font
size=3D2 color=3D"#804040" face=3D"Courier New">2/ =
Administration
We =
reviewed the WG Charter & milestones (see slide 4) =
and
http://www.=
ietf.org/html.charters/ipcdn-charter.html
 
The =
chairs proposed to update milestone for the DOCSIS Cable =
Device
MIB v2 =
and the PacketCable MIBs to June 2005, that is be "wg done" =
by
June 2005 =
and formerly request publication which will start Ad =
and
IESG =
review.
Bert =
commented that June 2005 seems aggressive for completing the =
CD
MIB (via =
jabber). While this may be aggressive given the past =
pace,
with =
Kevin Marez as the new editor and the ad-hoc session with =
Randy
Presuhn =
we were able to organize at IETF to address some of =
Randy's
mib =
doctor comments on the draft, this should still be =
doable.
# AI: wg chairs to reflect new =
milestones when proposing updated =
IPCDN
# charter to =
AD
 
Bert also =
added that he hoped to pick up MIB reviews for the event =
MIB
and the =
RFIv2 MIB modules shortly after =
IETF.
# AI: wg chairs to follow-up with =
Bert and MIB co-authors to =
ensure
# mib doctors have been assigned =
to those 2 IPCDN DOCSIS I-Ds
# AI completed on =
4/1/2005.
 
 
+ Concluding the IPCDN CableHome =
work items
The =
chairs (Jean-Francois speaking at the mike) proposed that the =
WG
drops the =
CableHome MIBs from the charter.  There were 6 =
expired
Internet-Drafts:
draft-ietf-ipcdn-cable-gateway-config-mib-00
draft-ietf-ipcdn-cable-gateway-tools-mib-00
draft-ietf-ipcdn-cable-gateway-device-mib-00
draft-ietf-ipcdn-cable-gateway-addressing-mib-=
00
draft-ietf-ipcdn-cable-gateway-security-mib-00=

draft-ietf-ipcdn-cable-gateway-qos-mib-00=

 
 
The =
rationale for concluding all the CH work items was discussed =
later
in the =
meeting and is documented on slide 41 of the meeting =
materials.
The AD =
Bert asked whether the CableHome mib modules had been =
rooted
under =
mib-2 at CableLabs (the answer is no which means from an =
IETF
point of =
view, we do not have the same worries as with some of =
the
earlier =
DOCSIS MIBs.
=3D> =
There was no objection from the WG participants in the =
room.
=3D> =
Via jabber, Bert accepted our explanations and agreed to =
reflect
   the WG decision by modifying the =
charter.
# Decision: wg and AD agreement to =
conclude the IPCDN CableHome =
work
# AI: wg chairs to propose new =
updated IPCDN charter reflecting =
the
# change
 
 
<=
font
size=3D2 color=3D"#804040" face=3D"Courier New">3/ IPCDN DOCSIS =
mibs
 
+ DOCSIS Cable Device MIB version 2
  =
draft-ietf-ipcdn-device-mibv2-07.txt
<=
font
size=3D2 face=3D"Courier New">  =
Editor: Kevin Marez
  http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv=
2-07.txt
We spent =
much of the meeting time discussing the update of the =
DOCSIS
cable =
device mibv2 and the open issues to advance this =
Internet-Draft.
Most of =
those issues were raised by the mib doctor review from =
Randy.
 
Note that =
the complete enumerated listing of all the =
draft07
modifications is available =
at:
http://www.ip=
cdn.org/meetings/cdmib-07-changes.doc
<=
pre>or http://tools.ietf.org/wg/ipcdn/<=
/a>
and a =
diff between draft06 and draft07 is =
at:
http://tools.ietf.org/wg/=
ipcdn/draft-ietf-ipcdn-device-mibv2/draft-ietf-ipcdn-device-mibv2-07-from=
-06.diff.html
 
- Open issue #1: MIB compile warning in compliance =
statement
Multiple =
entries in the docsDevGroups are deprecated =
ex:
docsDevNmAccessGroup, docsDevSoftwareGroup, =
etc. The MIB compiler
complains =
with warning messages about compliance statements =
that
referred =
to deprecated objects.
Rich =
indicated he thought the inclusion of deprecated groups was =
not
proper =
practice, but that it was not prohibited per se. Rich =
added
that in =
the mib review guidelines, page 31, it says something =
about
it.
From page =
31:
| - The =
status of a compliance statement is independent of the =
status
|   of its members.  Thus, a =
current compliance statement MAY refer =
to
|   deprecated object groups or =
notification groups.  This may =
be
|   desirable in certain cases, =
e.g., a set of widely-deployed =
object
|   or notification groups may be =
deprecated when they are replaced =
by
|   a more up-to-date set of =
definitions, but compliance =
statements
|   that refer to them may remain =
current in order to encourage
|   continued implementation of the =
deprecated groups.
 
Bert =
commented that this practice is not =
allowed.
# AI: Kevin Marez to look into =
this issue further and propose a =
new
# compliance statement addressing =
the issue.
 
- Open issue =
#2
The =
docsDevEvReporting object description doesn’t mesh well with =
the
RFC3413 =
guidelines. This was reported by =
Randy.
RFC3413 =
and RFC3014 overlaps with some logging objects in the CD =
MIB.
During =
the meeting, Kevin proposed that a clarification can be made =
in
the CD =
MIB that indicates that the CD MIB object only be =
applicable
when =
running in SNMPv1/2 mode and that RFC3413 be applicable =
when
running =
in Coexistence mode. Eduardo commented via jabber that =
that
proposal =
may not work.
# AI: Kevin to post pb statement =
and resolution to the list
# done on =
3/11
Kevin =
also met with Randy after the IPCDN meeting and =
actually
proposed =
the following in an email sent on March 11 to the =
ipcdn
list:
Kevin =
wrote:
>My proposal would be to add =
another enumerated type (bit) =
for
>stdInterface(9) which would =
indicate the usage of =
RFC3413/RFC3014
>mechanisms for =
notifications.  There should be no problems =
with
>concurrent usage/support of =
both mechanisms so it would be =
possible
>to perform notifications in =
both places.  Or, do we want to =
consider
>this being an xor =
situation?  It would be necessary to =
exclude
>syslog(2) in this case, since =
neither RFC3413 nor RFC3014 covers =
this
>functionality.  =
Essentially, (stdInterface && syslog) XOR (local =
&&
>traps && =
localVolatile).
 
- Open Issue =
#3
The =
relationship between docsDevEventGroup, docsDevEventGroupv2 =
and
RFC3014 =
needs to be defined. There was no real discussion on this =
item
during =
the ipcdn meeting.
# AI: Kevin to address this issue =
on the list together with issue =
#3.
 
 
- Open Issue =
#4:
What is =
the purpose of the docsDevFilterPolicyObsoleteGroup =
group?
# Decision: since the objects have =
been obsoleted, we agreed to =
remove
# the group entirely. If anyone =
objects to Kevin's =
recommendation,
# please send your comments to the =
list.
 
 
+ RF MIB =
v2
  =
draft-ietf-ipcdn-docs-rfmibv2-13.txt
<=
font
size=3D2 face=3D"Courier New">  =
Editor: Eduardo =
Cardona
  http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv=
2-13.txt
We went =
through the slides which document the updates in draft 13. =
A
number of =
issues need to be resolved to release what will hopefully =
be
the last =
draft (see slide 18-21).
Rich =
asked if anyone had questions or comments on the changes made =
to
the =
draft: nobody had any comments.
# AI: Eduardo to close the issues =
by proposing resolutions to the =
list
# and release draft14 before =
June.
 
 
+ DOCSIS Event Notification =
MIB
  =
draft-ietf-ipcdn-docsisevent-mib-06.txt
  =
Editor: Greg Nakanishi
  http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docsisev=
ent-mib-06.txt
 
Greg =
commented that all AD comments were incorporated in =
draft06.
Bert =
should provide an additional review shortly after IETF#62.  =
Bert
asked the =
chairs to remind him.
# AI: Bert to do a final check on =
draft 06 of the ipcdn docsis event =
mib
# AI: chairs to remind Bert (done =
on 4/1/2005).
 
<=
font
size=3D2 color=3D"#804040" face=3D"Courier New">4/ IPCDN IPCablecom/PacketCable MIB =
Updates
 
+ PacketCable/IPCablecom MTA =
MIB
  =
draft-ietf-ipcdn-pktc-mtamib-06.txt
  http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-mtamib-=
06.txt
 
The =
current status on MTA MIB draft 06 was presented by =
Jean-Francois.
A number =
of comments were made by Bert on draft06 (see slide 31). =
The
next step =
is to update the draft.
# AI: MTA MIB authors to update =
the draft by the end of May and
# release =
draft07.
 
 
+ PacketCable/IPCablecom Signaling =
MIB
  =
draft-ietf-ipcdn-pktc-signaling-08.txt
  http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-sign= aling-08.txt
 
Sumanth =
is taking over editorship from Gordon Beacham (many thanks =
to
Gordon =
for leading the 7 revisions of the draft to =
date).
List of =
changes in draft07:
 http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01594.html
 
Rich =
asked about the txGain and rxGain objects.  His understanding =
is
that most =
vendors implement equivalent objects in private MIBs.  He =
is
not =
concerned that these parameters cannot be set dynamically.  It =
is
OK to =
configure them at device startup.  Some operators had to =
reduce
the gain =
to reduce/prevent echo on the =
line.
Note that =
a patent disclosure was brought to the attention of the =
WG
by =
Jean-Francois Mule, ipcdn =
co-chair
 http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01593.html.<=
o:p>
 
There are =
no pending issues on this =
draft.
# Decision: it was agreed by Bert =
and the chairs to issue a new =
WG
# Last Call as the next =
step.
 
+ PacketCable/IPCablecom =
Management Event MIB
  =
draft-ietf-ipcdn-pktc-eventmess-04.txt
  http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-even= tmess-04.txt
 
Sumanth =
also took over the editorship of this draft. The MIB is =
not
widely =
implemented or tested at CableLabs to date (as it is not a =
core
requirement for PacketCable 1.0). The MIB =
functionality will become
mandatory =
for PacketCable 1.5 so Jean-Francois expressed interest =
in
advancing =
this MIB module to WG last call =
ASAP.s
 
Rich asks =
if this is the version of the MIB that gets rid of =
the
distinction between fixed and programmable =
events. Answer is yes.
 
Bert =
commented that if this MIB is being implemented it (under =
the
CableLabs =
root while awaiting ipcdn RFC), it is better to get some =
MIB
doctor =
review ASAP.
 
# AI: chairs to send a note to =
request review from Randy and/or =
Bert
 
<=
font
size=3D2 color=3D"#804040" face=3D"Courier New">5/ CableHome MIB =
modules
The =
chairs would like to discuss the withdrawal of all the =
CableHome
MIB Ids =
from our IETF IPCDN charter with the wg participants. We =
will
then =
consider make this proposal to the =
ADs.
 
There =
have been no updates to the IETF Internet-Drafts since June =
2003.
Bert =
asked if there is no activity in both IETF and =
CableLabs.
Jean-Francois indicated that there has been =
some changes within the
CableLabs =
MIBs. After consulting with some vendors participant in =
IETF
and the =
internal CableLabs CableHome team in February 2005 =
(before
IETF#62), =
there is not enough vendor or CableLabs support =
to
advance =
those MIBs in IETF: we cannot find any committed resources =
to
do =
this.
see slide =
41.
Burt asks =
if the CableLabs CableHome MIBs were rooted under =
MIBII.
The =
answer is 'no', there are under the CableLabs enterprise =
OID.
Bert =
stated that if that is the case, we don't have to worry about =
it
as much =
as we did for the DOCSIS mibs (from an IETF point of =
view).
Rich =
Woundy and Greg N agree that the best path forward is to =
remove
them from =
the charter. Bert accepted the chair proposal and is ok =
with
charter =
update to remove them.
 
As =
indicated in section 2/ of these =
notes:
# Decision: wg and AD agreement to =
conclude the IPCDN CableHome =
work
# AI: wg chairs to propose new =
updated IPCDN charter reflecting =
the
# =
change
 
 
<=
font
size=3D2 color=3D"#804040" face=3D"Courier New">6/ IPCDN WG next =
steps
Beyond =
the action items noted above and implementation of the =
various
decisions =
the wg agreed to, the following is our work =
plan:
 - Finish =
all DOCSIS MIBs by June 2004
 - =
Request publication for
   PacketCable/IPCablecom MTA =
MIB
   PacketCable/IPCablecom Signaling =
MIB
 - =
Advance expert + mib doctor reviews for Management Event MIB =
for
   =
MTAs
 - Revise =
IPCDN Charter Milestones
 
>.end of the IETF#62 ipcdn =
meeting notes
------------------------------------------
 

 

------_=_NextPart_001_01C53706.946750DC-- --===============0468553443== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============0468553443==-- From ipcdn-bounces@ietf.org Tue Apr 5 15:43:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27986 for ; Tue, 5 Apr 2005 15:43:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIu5n-0007bM-Dt for ipcdn-archive@ietf.org; Tue, 05 Apr 2005 15:52:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DItns-0005FP-EM; Tue, 05 Apr 2005 15:33:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DItno-0005ET-Rc; Tue, 05 Apr 2005 15:33:32 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24366; Tue, 5 Apr 2005 15:33:30 -0400 (EDT) Message-Id: <200504051933.PAA24366@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 05 Apr 2005 15:33:30 -0400 Cc: ipcdn@ietf.org Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-device-mibv2-08.txt X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Cable Data Network Working Group of the IETF. Title : Cable Device Management Information Base for Data-Over-Cable Service Interface Specification Compliant Cable Modems and Cable Modem Termination Systems Author(s) : R. Woundy, K. Marez Filename : draft-ietf-ipcdn-device-mibv2-08.txt Pages : 89 Date : 2005-4-5 This memo is a draft revision of the standards track RFC-2669. Please see 'Revision Descriptions' below for a description of changes. This document will obsolete RFC-2669 when accepted. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP- based management of DOCSIS compliant Cable Modems and Cable Modem Termination Systems. This memo is a product of the IPCDN working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@ietf.org and/or the author. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipcdn-device-mibv2-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipcdn-device-mibv2-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-4-5160201.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-device-mibv2-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-device-mibv2-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-4-5160201.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --NextPart-- From ipcdn-bounces@ietf.org Thu Apr 21 11:22:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOdVz-000821-Up; Thu, 21 Apr 2005 11:22:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMVls-0007C7-Vd; Fri, 15 Apr 2005 14:42:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00444; Fri, 15 Apr 2005 14:42:27 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMVw7-0005ye-2b; Fri, 15 Apr 2005 14:53:04 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j3FIf6608880; Fri, 15 Apr 2005 11:41:06 -0700 (PDT) Message-Id: <200504151841.j3FIf6608880@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 15 Apr 2005 11:41:06 -0700 X-ISI-4-39-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f X-Mailman-Approved-At: Thu, 21 Apr 2005 11:22:50 -0400 Cc: ipcdn@ietf.org, rfc-editor@rfc-editor.org Subject: [ipcdn] RFC 4036 on Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4036 Title: Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management Authors: W. Sawyer Status: Standards Track Date: April 2005 Mailbox: wsawyer@ieee.org Pages: 27 Characters: 57946 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipcdn-subscriber-mib-16.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4036.txt This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a set of managed objects for Simple Network Management Protocol (SNMP)-based management of Data-over-Cable Service Interface Specification (DOCSIS)-compliant Cable Modem Termination Systems. These managed objects facilitate protection of the cable network from misuse by subscribers. The Differentiated Services MIB (RFC 3289) provides the filtering functions needed here, making use of classification items defined in this specification. This document is a product of the IP over Cable Data Network Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <050415113831.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4036 --OtherAccess Content-Type: Message/External-body; name="rfc4036.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <050415113831.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --NextPart-- From ipcdn-bounces@ietf.org Tue Apr 26 19:53:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQZrq-00036w-4o; Tue, 26 Apr 2005 19:53:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQZro-00036o-Ok for ipcdn@megatron.ietf.org; Tue, 26 Apr 2005 19:53:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04771 for ; Tue, 26 Apr 2005 19:53:21 -0400 (EDT) Received: from pacdcoavas10.cable.comcast.com ([208.17.33.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQa4K-0003Vs-Mb for ipcdn@ietf.org; Tue, 26 Apr 2005 20:06:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C54ABB.107EF333" Date: Tue, 26 Apr 2005 19:52:54 -0400 Message-ID: X-MS-Has-Attach: yes Thread-Topic: BCP 103, RFC 4053 on Procedures for Handling Liaison Statements to and fromthe IETF Thread-Index: AcVKt57tHdoh5xcATXS9EvF9YU1HpQAAzZLg From: "Woundy, Richard" To: X-OriginalArrivalTime: 26 Apr 2005 23:52:55.0013 (UTC) FILETIME=[10BDA150:01C54ABB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Subject: [ipcdn] FW: BCP 103, RFC 4053 on Procedures for Handling Liaison Statements to and fromthe IETF X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C54ABB.107EF333 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, This new RFC specifies procedures for handling liaison statements to and from the IETF. Since we have had a few liaison statements from other Standards Development Organizations in the past, I thought this might be of interest to this WG. -- Rich -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of rfc-editor@rfc-editor.org Sent: Tuesday, April 26, 2005 7:20 PM To: ietf-announce@ietf.org Cc: rfc-editor@rfc-editor.org Subject: BCP 103,RFC 4053 on Procedures for Handling Liaison Statements to and fromthe IETF A new Request for Comments is now available in online RFC libraries. BCP 103 RFC 4053 Title: Procedures for Handling Liaison Statements to and from the IETF Author(s): S. Trowbridge, S. Bradner, F. Baker Status: Best Current Practice Date: April 2005 Mailbox: sjtrowbridge@lucent.com, sob@harvard.edu, fred@cisco.com Pages: 19 Characters: 38816 SeeAlso: BCP 103 I-D Tag: draft-baker-liaison-statements-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4053.txt This document describes the procedure for proper handling of incoming liaison statements from other standards development organizations (SDOs), consortia, and industry fora, and for generating liaison statements to be transmitted from IETF to other SDOs, consortia and industry fora. This procedure allows IETF to effectively collaborate with other organizations in the international standards community. The IETF expects that liaison statements might come from a variety of organizations, and it may choose to respond to many of those. The IETF is only obligated to respond if there is an agreed liaison relationship, however. This document is a product of the Internet Architecture Board. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body=20 help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader=20 implementation to automatically retrieve the ASCII version of the RFCs. ------_=_NextPart_001_01C54ABB.107EF333 Content-Type: application/octet-stream; name="rfc4053.URL" Content-Description: rfc4053.URL Content-Disposition: attachment; filename="rfc4053.URL" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlzaS5lZHUvaW4tbm90ZXMvcmZjNDA1 My50eHQNCg== ------_=_NextPart_001_01C54ABB.107EF333 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn ------_=_NextPart_001_01C54ABB.107EF333--