[Ballot discuss]
> pktcEventSyslogPort  OBJECT-TYPE
>    SYNTAX      InetPortNumber
>    MAX-ACCESS  read-write
>    STATUS      current
>    DESCRIPTION
>            "This MIB object contains the port number of the
>              syslog Server to which the syslog messages are to
>              be transmitted."
>    REFERENCE
>            "Transmission of syslog messages over UDP, [RFCBBB];
>              TLS Transport Mapping for Syslog, [RFCCCC]."
>    DEFVAL { 514 }

  Discuss: The default for pktcEventSyslogTransport is syslog transport
  over TLS, but port 514 is only reserved for syslog over UDP. 514
  should be changed to the port number allocated by IANA for
  draft-ietf-syslog-transport-tls, which is currently with the RFC
  Editor.

[Ballot discuss]
(Updated discuss, forgot to add an issue.)

Section 6., paragraph 31:
> pktcEventSyslogAddress  OBJECT-TYPE
>    SYNTAX      InetAddress
>    MAX-ACCESS  read-write
>    STATUS      current
>    DESCRIPTION
>            "This MIB object contains the IP address of the
>            syslog server to which the MTA can transmit a syslog
>            message upon the generation of a management event.
>            The type of address this object represents is defined
>            by the MIB object pktDevEventSyslogAddressType.

  Discuss: pktcEventSyslogAddress is IPv4-only. What are our
  requirements on MIBs with regards to IPv6? It seems straightforward to
  extend this element to hold either an IPv4 or IPv6 address (or even a
  FQDN).


> pktcEventSyslogPort  OBJECT-TYPE
>    SYNTAX      InetPortNumber
>    MAX-ACCESS  read-write
>    STATUS      current
>    DESCRIPTION
>            "This MIB object contains the port number of the
>              syslog Server to which the syslog messages are to
>              be transmitted."
>    REFERENCE
>            "Transmission of syslog messages over UDP, [RFCBBB];
>              TLS Transport Mapping for Syslog, [RFCCCC]."
>    DEFVAL { 514 }

  Discuss: The default for pktcEventSyslogTransport is syslog transport
  over TLS, but port 514 is only reserved for syslog over UDP. 514
  should be changed to the port number allocated by IANA for
  draft-ietf-syslog-transport-tls, which is currently with the RFC
  Editor.

[Ballot comment]
Section 6., paragraph 32:
>            The MTA SHOULD NOT attempt to route to a non-routable
>            syslog IP address.

  Please define what exactly is meant by non-routable addresses.

[Ballot comment]
Section 6., paragraph 32:
>            The MTA SHOULD NOT attempt to route to a non-routable
>            syslog IP address.

  Please define what exactly is meant by non-routable addresses.

[Ballot discuss]
Section 6., paragraph 31:
> pktcEventSyslogAddress  OBJECT-TYPE
>    SYNTAX      InetAddress
>    MAX-ACCESS  read-write
>    STATUS      current
>    DESCRIPTION
>            "This MIB object contains the IP address of the
>            syslog server to which the MTA can transmit a syslog
>            message upon the generation of a management event.
>            The type of address this object represents is defined
>            by the MIB object pktDevEventSyslogAddressType.

  Discuss: pktcEventSyslogAddress is IPv4-only. What are our
  requirements on MIBs with regards to IPv6? It seems straightforward to
  extend this element to hold either an IPv4 or IPv6 address (or even a
  FQDN).

Gen-ART review by Pasi Eronen

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.)

IANA Last Call comments:


Upon approval of this document, the IANA will make the following
assignments in the "NETWORK MANAGEMENT PARAMETERS" registry
located at
http://www.iana.org/assignments/smi-numbers
sub-registry "Prefix: iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1)"

Decimal Name Description References
------- ---- ----------- ----------
[tbd] pktcIetfEventMib PKTC-IETF-EVENT-MIB
[RFC-ipcdn-pktc-eventmess-12]

We understand the above to be the only IANA Action for this
document.

MIB Doctor Review assessment from David Harrington on draft-10:

Hi,

1) The syslog WG split the textual conventions for severity and facility into draft-ietf-syslog-tc-mib (the SYSLOG-TC-MIB), so we wouldn't hold up ipcdn while we debated all the objects in the syslog mib. The import clause should be changed.

2) pktcEventReset can suffer multi-manager contention. The description should at least have a warning about manager contention.

I suggest adding some type of lock so that a manager who is troubleshooting can indicate that to other managers, so the log will not be reset during the middle of their troubleshooting session.

This reset capability should be discussed in the security considerations, since it could allow users to erase their tracks.

s/MUST not/MUST NOT/

2) pktcEventSyslogCapabiltiies should be separated into two, one for the message format and a second for the transport, so additional formats and transports can be added in the future.

syslog/BEEP is missing.

I suggest you might want to change formatBSDSyslog to BSDsyslog(0), and the formatSyslogProtocol to IETFsyslog(1)

BSDsyslog has existing implementations for SSL/TLS; why are you mandating that TLS is only applicable to the IETFsyslog?

The description that says "the MTA MUST support UDP ... and SHOULD support TLS" may contradict the IETF syslog protocol requirement, which the Transport ADs want to say "MUST support TLS, and MAY support UDP." This is consistent with the IETF's Danvers Doctrine (BCP 61) that requires support for strong security in all IETF protocols.

I recommend not putting this MUST language in the MIB. Let the IETF syslog standard set its requirements, and Cablelabs and others can set theirs. The MIB should not be the place to define what transports and what formats are required and optional for the syslog and SNMP protocols.

3) pktcEventSyslsogAddress provides IPv4 examples; you should probably include IPv6 exampes as well.

"If this MIB Object ... the MTA MUST suspend the transmission of Syslog messages." - Is that really what you want here? If you want to say that the MTA should not send syslog messages to a non-routable address, that should be acceptable.

s/daemon/service/

I don't think you shopuld discuss the format as part of this description. I question whether you need to discuss pktDevEvsyslogAddressType here (and note that you have changed the name of this object but not this reference to it.)

I recommend checking every reference in a description clause to another object to make sure the other object still exists.

4) pktcEventSyslsogTransport does nto include BEEP. The description should not state the only values that ar esupported, since enumerations can be expanded in the future.

I suggest making the last sentence more generic; if the MTA does not support the transport specified in a SET operation, then ...

I would be very careful about specifying that an error code MUST be XXX, because there could be more applicable error codes in a future version of the SNMP protocol.

Any mention of SNMP specific things should be as examples only, because a MIB module should be designed to be able to work with other protocols as well. There is ongoing work to make the MIB accessible through Netconf, for example, and other protocols might follow, so the MIB module should not be dependent on SNMP. It is acceptable to specify examples based on SNMP.

5) pktcEvenetSyslogPort - I don't think the second sentence is necessary for the MIB module.

6) pktcEvenetSyslogMsgFormat - I recommend eliminating abbreviations in naming - make this pktcEventSyslogMessageFormat so people aren't forced to remember how you choose to abbreviate message, as compared to other MIB modules that spell it out or abbreviate it differently.

Enumerations are expandable; do not say in the text that only two formats are supported. Describe the two values, without specifying an upper limit.

Please get rid of the MUST support statements; that is not a decision of the MIB module.

7) pktcEventClassReportTable - consistency in naming!!
All elements in this table should have the same prefix. I recommnnd dropping the "Report" from the name and just use pktcEventClassTable, and pktcEventClassEntry and pktcEventClassStatus. the "Report" isn't needed.

Is this table persistent?

8) pktcEvenetClassIndex - can the decription be made more meaningful?
It is ibviously the index into this table. Does it correspond to anything, or is it just a locally-meaningful value? If the table is persistent, should these values remain consistent across reboots?

9) pktcEveneClassReportStatus is dependent on pktcEventDescrReporting; what happens if that object does not exist?

10) pktcEventClassSeverityLevel - I suggest "Level" isnt needed, since pktcEventClassSeverity would have the same meaning.

I recomend the first sentnece be shortened to "This MIB Object defines the dseverity level of events belonging to a specific event class."
Whether the previous object is set to enable or disable is immaterial to this object.

I recommend eiminating the second paragraph from the description.

I find all the conditionals and references to other objects really confusing; Can't this definition be changed to something much simpler?
I also recommend discussing this interrelwtionship of objects on whether somehting gets sent as part of the Table definition, and a state table might be helpful in that discussion.

You are refencing the syslog protocol and the syslog MIB; neither really has much to do with this description. The type doesn't even use the textual conventions from the syslog mib here.

It would be good to have a DEFVAL here.

11) pktcEventThrottleAdminStatus - writing to the object resets the thresholding state. What does that mean?

I don't think the last paragraph is needed.

12) pktcEventDescrOrg should probably have a REFERENCE clause pointing to the IANA enterprise IDs.

13) pktcEventDescrReporting - why MUST an Inform be used for an emergency, alert, critical, or error? Why isn't this an operator's decision of whether Informs or traps are sufficient?

14) pktxEventDescrClass - can an event fall into more than one class?
How is this done?

15) pktcEventLogtable - the second sentence seems unnecessary here.
Why is it specified that the table MAT exist in NV memory? If it isn't required, then isn't it immaterail to interoperability? Are you tryig to say that on some systems the log might not be cleared when the device is rebooted?

16) pktcEventLogIndex discusses what to do if if the syteem does not implement NV storage; what happens if it does? Should the numbering start at n+1?

17) logTime - what architecture? Does this mean the implementation architecture, i..e, the value is implementation-dependent? There is a REFERENCE to BSDprotocol and syslogProtocol - are you saying the Time should be determined by the syslog version?

18) there are a number places with "to which the priority and display strings belong" - are these really needed? are they accurate?

19) There are a number of SnnmpAdminString objects in the log with no SIZE constraints.

20) pktcEventLogType - I find it unclear what happens when the action requested is syslog, but throtting is enabled, and the message is throttled; does logtype report local or syslog?

21) SnmpAdminStrings:
The use of control codes should be avoided.

      When it is necessary to represent a newline,
      the control code sequence CR LF should be used.

There are other restrictions as well. It shoul dbe made clear that those restrictins should be observed.

22) targetinfo might exceed capacity with a number of IPv6 addresses.

23) If I sent an SNMP Traps to multiple users at the same address, then I should report
snmpTrap/192.168.1.2,snmpTrap/192.168.1.2,snmpTrap/192.168.1.2 ?
Is that really helpful to operators?

24) I am concerned that objects like AdditionalInfo might overflow the 255t limit of SnmpAdminStrings.

25) AdditionalInfo should be populated with "a string of zero length"
- you mean this should be a zero-length OCTET-STRING, right? You should say that.

26) In the description of the structure of the MIB module, please do not refer to subtrees as groups; the word GROUP is now a reservced word. Please refer to subtrees as subtrees.

27) section 4.3 discusses throtting as a way for the managemet stations to control transmissions. Multiple management stations may have access to the MIB module; you should warn about possible contention for control of the throttling mechanisms.

You should also discuss this under security considerations, since one management station could create denials of service by severely throttling output, especially if the management station is an active attacker, and they want to hide their activities.

An attacker might also remove the throttling in order to cause overload.

28) pktcEventTransmissionStatus - how will the MTA determine validsyslogServerAbsent? I don't think even syslog can determine that, since it is a one-way protocol.

syslog should be capitalized in the name.

What is valid?

26) Why do you need a pktcEventTrap and a pktcEventInform? They are identical.

27) The Relationship to other MIB modules doesn't mention the syslog-tc-mib.

28) persistence across reboot is not mentioned for writable objects:
pktcEventSyslogXXX entries, pktcEventClassXXX entries, pktcEventThrottleXXX entries, pktcEventDescrXXXX entries

From MIB Doctor review by David Harrington:

I am not crazy about an approach that publishes an IETF standard designed to work with protocols the IETF has declared historic and NOT RECOMMENDED. The ISMS work, the only work going on to advance SNMP, does not support SNMPv1 or SNMPv2c messages. It just completed WGLC on two of the three major documents. I realize the real world has not declared SNMPv2c Historic and NOT RECOMMENDED, and PacketCable has not done so, but I think it is a bad thing for the IETF to be inconsistent in its leadership/advice about the use of SNMPv2c.

I am not crazy about an approach that publishes an IETF standard designed to work with an Informational document (RFC3164) that describes earlier approaches to syslog rather than work with the standards-track work being done on a standardized protocol for syslog.
I realize Packetcable set their designs based on what was available at the time, and on the variety of syslog implementations available in the industry. Note that the syslog WG plans to request that RFC3164 be declared obsolete because we found that the existing implementations were all over the map - the only thing they had in common was the <PRI> field that starts the message; after that all bets are off, and
RFC3164 does not do justice describing the cacophony of non-interoperable formats. I think it is a bad thing for the IETF to be inconsistent in its leadership/advice about the use of pre-standard versus standard syslog message formats.

I am especially concerned that the isms work and the syslog work and the ipcdn work are all going to the IETF at roughly the same time, so are likely to be published as Proposed Standards at roughly the same time, and have totally different recommendations about SNMPv2c versus SNMPv3, and about RFC3164 versus -protocol-. I do think this shows there is a lack of standard status appropriate to migration from an older version to a newer version, and maybe this is a good test for how the IETF/IESG can address the issue as this problem continues to arise. Maybe we should DEPRECATE RFC3164 and move SNMPv2c from Historic to DEPRECATED, although I don't think depecated is an option in RFC status.

PROTO Write-up

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Richard Woundy (IPCDN co-chair) is the Document Shepherd, and he has
personally reviewed this version of the internet-draft.

Based on the Document Shepherd review and WG discussion, this version is
ready for forwarding to the IESG for publication, with two minor
caveats:

1. The internet-draft uses the ISOC Copyright and disclaimer from RFC
3978, rather than from RFC 4748. RFC 4748 was published after the last
version of this internet-draft was posted.

2. According to verbose checking by id-nits, "The page length should not
exceed 58 lines per page, but there was 2 longer pages, the longest
(page 4) being 60 lines". This appears to be caused by a document
formatting error.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members?

Yes, there have been reviews from both subject-matter experts that are
WG members and MIB doctors who provided valuable comments to improve the
quality of the MIB module.

Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

No, given the time this ID has been in existence and the number of
revisions due to comments.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

The internet-draft requires a formal MIB Doctor review.

David Harrington has offered some preliminary MIB doctor comments, which
were incorporated in version -08 of the draft.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here.

No.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

This document represents the WG consensus as a whole: the WG as a whole
understands and agrees with it.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

There were no ID nits issues per the automated idnits check (version
1.114) at:
<http://tools.ietf.org/wg/ipcdn/draft-ietf-ipcdn-pktc-eventmess/draft-ie
tf-ipcdn-pktc-eventmess-09.nits.txt>.

However, using the *updated* idnits check (version 1.123) with the
verbose setting yielded the following concerns:

- This document has ISOC Copyright according to RFC 3978, instead of
the
newer IETF Trust Copyright according to RFC 4748. You should
consider
updating it; the new Copyright statement will be required from
February
1st, 2007
- In addition to a regular copyright notice, the document also has a
copyright notice embedded in the text.
- This document has an original RFC 3978 Section 5.5 Disclaimer,
instead of
the newer disclaimer which includes the IETF Trust according to RFC
4748.
You should consider updating it; the new disclaimer will be required
from
February 1st, 2007
- The page length should not exceed 58 lines per page, but there was 2
longer pages, the longest (page 4) being 60 lines

These issues were discussed in section (1.a) above.

The internet-draft requires a formal MIB Doctor review.

(1.h) Has the document split its references into normative and
informative?

Yes.

Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion?

There are two normative references to unpublished documents:

[RFCXYZ] Nechamkin, E., and Mule J., "Multimedia Terminal Adapter
(MTA) Management Information Base for PacketCable and IPCablecom
compliant devices", RFCXYZ, <Date>.

* This internet-draft is on the RFC Editor's Queue, to be published soon
as RFC 4682 (Proposed Standard).

[RFCABC] Glenn Mansfield Keeni, "Syslog Management Information
Base", RFCABC, <Date>.

* This internet-draft is within the domain of the SYSLOG WG, co-chaired
by David Harrington and Chris Lonvick, and the responsible AD is Sam
Hartman. The SYSLOG MIB module internet-draft completed WGLC on 9/29,
and is being reviewed by David Harrington. Note that David is likely to
be assigned as the MIB Doctor of draft-ietf-ipcdn-pktc-eventmess.

Here is some relevant SYSLOG mailing list items on the SYSLOG MIB, in
chronological order:

<http://www1.ietf.org/mail-archive/web/syslog/current/msg01236.html>
<http://www1.ietf.org/mail-archive/web/syslog/current/msg01250.html>
<http://www1.ietf.org/mail-archive/web/syslog/current/msg01252.html>
<http://www1.ietf.org/mail-archive/web/syslog/current/msg01256.html>
<http://www1.ietf.org/mail-archive/web/syslog/current/msg01259.html>
<http://www1.ietf.org/mail-archive/web/syslog/current/msg01342.html>
<http://www1.ietf.org/mail-archive/web/syslog/current/msg01343.html>
<http://www1.ietf.org/mail-archive/web/syslog/current/msg01344.html>
<http://www1.ietf.org/mail-archive/web/syslog/current/msg01350.html>

Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

According to the check at
<http://rtg.ietf.org/~fenner/ietf/deps/index.cgi?doc=draft-ietf-ipcdn-pk
tc-eventmess>, there are no normative references that are downward
references.

(Note: this assumes that the SYSLOG MIB is published as a Proposed
Standard.)

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified?

The IANA Considerations section exists and is consistent with the body
of the document.

IANA is requested to assign the value for the root OBJECT IDENTIFIER
'pktcIetfEventMib' in the SMI Numbers registry.

If the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggested a
reasonable name for the new registry? See
[I-D.narten-iana-considerations-rfc2434bis].

The document does not create a new registry.

If the document
describes an Expert Review process has Shepherd conferred with
the Responsible Area Director so that the IESG can appoint the
needed Expert during the IESG Evaluation?

The document does not describe an Expert Review process.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

The libsmi web interface was used to compile this MIB, which yielded the
following (expected) errors and warnings:

mibs/PKTC-IETF-EVENT-MIB:19: [1] {module-not-found} failed to locate MIB
module `SYSLOG-MIB'

* This is due to the dependency on the SYSLOG MIB, defined in
draft-ietf-syslog-device-mib.

mibs/PKTC-IETF-EVENT-MIB:73: [2] {bad-identifier-case} `XXX' should
start with a lower case letter
mibs/PKTC-IETF-EVENT-MIB:73: [2] {object-identifier-not-prefix} Object
identifier element `XXX' name only allowed as first element

* The root OBJECT IDENTIFIER value 'pktcIetfEventMib' will be assigned
by IANA after IESG approval.

mibs/PKTC-IETF-EVENT-MIB:263: [2] {basetype-unknown} type
`SyslogSeverity' of node `pktcDevEventClassSeverityLevel' does not
resolve to a known base type
mibs/PKTC-IETF-EVENT-MIB:520: [2] {basetype-unknown} type
`SyslogSeverity' of node `pktcDevEventDescrSeverityLevel' does not
resolve to a known base type
mibs/PKTC-IETF-EVENT-MIB:219: [2] {type-unknown} unknown type
`SyslogSeverity'

* This is due to the dependency on the SYSLOG MIB, defined in
draft-ietf-syslog-device-mib.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Writeup? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

This document defines a portion of the Management Information Base (MIB)

for use with network management protocols in the Internet community.
In particular, it provides a common data and format representation
for events generated by PacketCable and IPCablecom compliant
Multimedia Terminal Adapter devices.

Working Group Summary
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

The Working Group has consensus to publish this document as a Proposed
Standard.

Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?

The original PacketCable 1.5 Management Event MIB is very similar to the
MIB module defined in this internet-draft; see
<http://www.packetcable.com/downloads/specs/PKT-SP-EVEMIB1.5-I02-050812.
pdf>.

The WG expectation is that CableLabs will require implementation of the
final (RFC) version of this internet-draft for PacketCable 2.0 certified
user equipment.

The ETSI "AT Working Group Digital" has also indicated their interest in
publication of this internet-draft as an RFC; note the liaison to the
IPCDN WG at <https://datatracker.ietf.org/documents/LIAISON/file55.pdf>.

Personnel
Who is the Document Shepherd for this document? Who is the
Responsible Area Director?

The Document Shepherd is Richard Woundy, and the Responsible Area
Director is Dan Romascanu.

7/25/06 - The document was returned to the WG. Revision draft-ietf-ipcdn-pktc-eventmess-08.txt will address comments from preliminary MIB doctor review and possible fixes according to RFC 4181. WGLC will follow, prior to submission to the IESG for consideration as Proposed Stnadard