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

=20


=20

-----Original Message-----
From: [email protected] [mailto:[email protected]]=20
Sent: Thursday, January 24, 2008 12:45 PM
To: [email protected]; [email protected];
[email protected]; Romascanu, Dan (Dan); [email protected];
[email protected]; [email protected]
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
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

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.

Comments:

pktcEventReset: typo in description, "resetEvDescrTable" should be
"resetEventTable"?

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,
Pasi

This email was protected during delivery to Avaya with TLS encryption