[ipcdn] FW: Gen-ART review of draft-ietf-ipcdn-pktc-eventmess-12

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Thu, 24 January 2008 12:44 UTC

Return-path: <ipcdn-bounces@ietf.org>
Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI1Ra-000469-Qv; Thu, 24 Jan 2008 07:44:34 -0500
Received: from ipcdn by megatron.ietf.org with local (Exim 4.43) id 1JI1RZ-000463-QL for ipcdn-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 07:44:33 -0500
Received: from [] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI1RZ-00045v-FL for ipcdn@ietf.org; Thu, 24 Jan 2008 07:44:33 -0500
Received: from nj300815-nj-outbound.net.avaya.com ([] helo=nj300815-nj-outbound.avaya.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JI1RY-0002Sx-Rk for ipcdn@ietf.org; Thu, 24 Jan 2008 07:44:33 -0500
X-IronPort-AV: E=Sophos;i="4.25,244,1199682000"; d="scan'208";a="94699752"
Received: from (HELO co300216-co-erhwest.avaya.com) ([]) by nj300815-nj-outbound.avaya.com with ESMTP; 24 Jan 2008 07:44:32 -0500
X-IronPort-AV: E=Sophos;i="4.25,244,1199682000"; d="scan'208";a="153551234"
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([]) by co300216-co-erhwest-out.avaya.com with ESMTP; 24 Jan 2008 07:44:31 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 24 Jan 2008 13:44:01 +0100
Message-ID: <EDC652A26FB23C4EB6384A4584434A04854515@307622ANEX5.global.avaya.com>
Thread-Topic: Gen-ART review of draft-ietf-ipcdn-pktc-eventmess-12
Thread-Index: AchedjTWTTNVYT6RSDafhlWydMFdzwAEJGvg
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: <ipcdn@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Subject: [ipcdn] FW: Gen-ART review of draft-ietf-ipcdn-pktc-eventmess-12
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>, <mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>, <mailto:ipcdn-request@ietf.org?subject=subscribe>
Errors-To: ipcdn-bounces@ietf.org



-----Original Message-----
From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] 
Sent: Thursday, January 24, 2008 12:45 PM
To: gen-art@ietf.org; Richard_Woundy@cable.comcast.com;
jf.mule@cablelabs.com; Romascanu, Dan (Dan); Sumanth@cablelabs.com;
deketelaere@tComLabs.com; enechamkin@broadcom.com
Subject: Gen-ART review of draft-ietf-ipcdn-pktc-eventmess-12

I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-ipcdn-pktc-eventmess-12
Reviewer: Pasi Eronen
Review Date: 2008-01-24
IETF LC End Date: 2008-01-28
IESG Telechat date: (not known yet)

Summary: This draft is basically ready for publication, but has nits
that should be fixed before publication.


pktcEventReset: typo in description, "resetEvDescrTable" should be

pktcEventLogIndex: the text describes the maximum value as 2^31, but the
SYNTAX line has 2^32-1?

pktcEventLogEndpointName: this object combines three different
information elements (endpoint number, FQDN, and IP address) to a single
string. Why this, instead of having them in separate objects?
(perhaps this should be explained in the DESCRIPTION text)

pktcEventLogType: bits 2 and 3 should be named snmpTrap and snmpInform
to match pktcEventReporting object.

Section 11 (Security Considerations):
- typo: pktcEventSyslogUdpPort should be pktcEventSyslogPort
- the following read-write objects are missing from the list:
  pktcEventSyslogMessageFormat, pktcEventSyslogTransport
- pktcEventClass is listed as having MAX-ACCESS read-write,
  but it's shown as read-only in MIB?

The normative reference list is quite long; I'm wondering if all the
PacketCable, ETSI, and ITU-T specs are actually normative (in the sense
described in RFC 3967)?  (For example, [ITU-T-J176] is cited only twice
in the text, and neither instances looks really normative to me.)

Best regards,

This email was protected during delivery to Avaya with TLS encryption

IPCDN mailing list