Management Event Management Information Base (MIB) for PacketCable- and IPCablecom-Compliant Devices
RFC 5428
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2017-05-16 |
14 | (System) | Changed document authors from "Sumanth Channabasappa" to "Sumanth Channabasappa, Eugene Nechamkin, Wim De Ketelaere" |
2015-10-14 |
14 | (System) | Notify list changed from Richard_Woundy@cable.comcast.com, RWoundy@broadband.att.com, jf.mule@cablelabs.com, Randy_Presuhn@mindspring.com to Randy_Presuhn@mindspring.com, RWoundy@broadband.att.com |
2012-08-22 |
14 | (System) | post-migration administrative database adjustment to the No Objection position for Pasi Eronen |
2012-08-22 |
14 | (System) | post-migration administrative database adjustment to the No Objection position for Lars Eggert |
2009-04-01 |
14 | Cindy Morgan | State Changes to RFC Published from RFC Ed Queue by Cindy Morgan |
2009-04-01 |
14 | Cindy Morgan | [Note]: 'RFC 5428' added by Cindy Morgan |
2009-04-01 |
14 | (System) | RFC published |
2008-08-19 |
14 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2008-08-19 |
14 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2008-08-19 |
14 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2008-08-18 |
14 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2008-08-18 |
14 | Cindy Morgan | State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan |
2008-08-18 |
14 | (System) | IANA Action state changed to In Progress |
2008-08-18 |
14 | Cindy Morgan | IESG state changed to Approved-announcement sent |
2008-08-18 |
14 | Cindy Morgan | IESG has approved the document |
2008-08-18 |
14 | Cindy Morgan | Closed "Approve" ballot |
2008-08-18 |
14 | Lars Eggert | [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss by Lars Eggert |
2008-08-18 |
14 | Pasi Eronen | [Ballot Position Update] Position for Pasi Eronen has been changed to No Objection from Discuss by Pasi Eronen |
2008-08-17 |
14 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2008-08-17 |
14 | (System) | New version available: draft-ietf-ipcdn-pktc-eventmess-14.txt |
2008-08-07 |
14 | Dan Romascanu | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Dan Romascanu |
2008-07-18 |
14 | (System) | Removed from agenda for telechat - 2008-07-17 |
2008-07-17 |
14 | Cindy Morgan | State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Cindy Morgan |
2008-07-17 |
14 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault |
2008-07-17 |
14 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley |
2008-07-17 |
14 | Pasi Eronen | [Ballot discuss] Spelling of SyslogSeverityMask labels should be aligned with SyslogSeverity labels. Also affects DESCRIPTION text of pktcEventClassSeverity and pktcEventReporting. |
2008-07-17 |
14 | Pasi Eronen | [Ballot Position Update] New position, Discuss, has been recorded by Pasi Eronen |
2008-07-17 |
14 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
2008-07-17 |
14 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson |
2008-07-16 |
14 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk |
2008-07-16 |
14 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
2008-07-16 |
14 | Cullen Jennings | [Ballot comment] This was one of the most easy to understand MIBs I have read. Thanks. |
2008-07-16 |
14 | David Ward | [Ballot Position Update] New position, No Objection, has been recorded by David Ward |
2008-07-16 |
14 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2008-07-15 |
14 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
2008-07-13 |
14 | Lars Eggert | [Ballot discuss] > pktcEventSyslogPort OBJECT-TYPE > SYNTAX InetPortNumber > MAX-ACCESS read-write > STATUS current > DESCRIPTION > … [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. |
2008-07-12 |
14 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
2008-07-11 |
14 | Lars Eggert | [Ballot discuss] (Updated discuss, forgot to add an issue.) Section 6., paragraph 31: > pktcEventSyslogAddress OBJECT-TYPE > SYNTAX InetAddress > MAX-ACCESS … [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. |
2008-07-11 |
14 | Lars Eggert | [Ballot comment] Section 6., paragraph 32: > The MTA SHOULD NOT attempt to route to a non-routable > … [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. |
2008-07-11 |
14 | Lars Eggert | [Ballot comment] Section 6., paragraph 32: > The MTA SHOULD NOT attempt to route to a non-routable > … [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. |
2008-07-11 |
14 | Lars Eggert | [Ballot discuss] Section 6., paragraph 31: > pktcEventSyslogAddress OBJECT-TYPE > SYNTAX InetAddress > MAX-ACCESS read-write > STATUS current … [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). |
2008-07-11 |
14 | Lars Eggert | [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert |
2008-07-10 |
14 | Dan Romascanu | [Ballot Position Update] New position, Yes, has been recorded for Dan Romascanu |
2008-07-10 |
14 | Dan Romascanu | Ballot has been issued by Dan Romascanu |
2008-07-10 |
14 | Dan Romascanu | Created "Approve" ballot |
2008-07-10 |
14 | Dan Romascanu | State Changes to IESG Evaluation from Waiting for Writeup::AD Followup by Dan Romascanu |
2008-07-10 |
14 | Dan Romascanu | Placed on agenda for telechat - 2008-07-17 by Dan Romascanu |
2008-06-24 |
14 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2008-06-24 |
13 | (System) | New version available: draft-ietf-ipcdn-pktc-eventmess-13.txt |
2008-06-12 |
14 | Dan Romascanu | State Changes to Waiting for Writeup::Revised ID Needed from Waiting for Writeup by Dan Romascanu |
2008-05-28 |
14 | Dan Romascanu | Still waiting for the editors to address comments from the GenART review. The AD sent warning message to WG chairs and editors. |
2008-01-28 |
14 | (System) | State has been changed to Waiting for Writeup from In Last Call by system |
2008-01-24 |
14 | Dan Romascanu | 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 … 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.) |
2008-01-23 |
14 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Hilarie Orman. |
2008-01-18 |
14 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Hilarie Orman |
2008-01-18 |
14 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Hilarie Orman |
2008-01-15 |
14 | Amanda Baber | 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 … 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. |
2008-01-14 |
14 | Amy Vezza | Last call sent |
2008-01-14 |
14 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2008-01-14 |
14 | Dan Romascanu | Last Call was requested by Dan Romascanu |
2008-01-14 |
14 | Dan Romascanu | State Changes to Last Call Requested from AD Evaluation::External Party by Dan Romascanu |
2008-01-14 |
14 | (System) | Ballot writeup text was added |
2008-01-14 |
14 | (System) | Last call text was added |
2008-01-14 |
14 | (System) | Ballot approval text was added |
2007-11-18 |
12 | (System) | New version available: draft-ietf-ipcdn-pktc-eventmess-12.txt |
2007-11-08 |
14 | Dan Romascanu | comments from MIB Doctor David Harrington are being dicussed with the editors |
2007-11-08 |
14 | Dan Romascanu | State Changes to AD Evaluation::External Party from AD Evaluation::AD Followup by Dan Romascanu |
2007-10-25 |
14 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2007-10-25 |
11 | (System) | New version available: draft-ietf-ipcdn-pktc-eventmess-11.txt |
2007-09-10 |
14 | Dan Romascanu | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Dan Romascanu |
2007-09-10 |
14 | Dan Romascanu | 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 … 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 |
2007-07-11 |
14 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2007-07-11 |
10 | (System) | New version available: draft-ietf-ipcdn-pktc-eventmess-10.txt |
2007-07-11 |
14 | Dan Romascanu | State Changes to AD Evaluation from AD Evaluation::AD Followup by Dan Romascanu |
2007-04-26 |
14 | Dan Romascanu | 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 … 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. |
2007-04-26 |
14 | Dan Romascanu | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Dan Romascanu |
2007-04-26 |
14 | Dan Romascanu | State Changes to AD Evaluation from Publication Requested by Dan Romascanu |
2006-12-13 |
14 | Dinara Suleymanova | 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, … 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. |
2006-12-13 |
14 | Dinara Suleymanova | State Changes to Publication Requested from AD is watching::AD Followup by Dinara Suleymanova |
2006-10-23 |
09 | (System) | New version available: draft-ietf-ipcdn-pktc-eventmess-09.txt |
2006-09-19 |
14 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2006-09-19 |
08 | (System) | New version available: draft-ietf-ipcdn-pktc-eventmess-08.txt |
2006-08-06 |
14 | Dan Romascanu | [Note]: 'Richard Woundy [Richard_Woundy@cable.comcast.com] is the PROTO shepherd of this document.' added by Dan Romascanu |
2006-07-25 |
14 | Dan Romascanu | State Changes to AD is watching::Revised ID Needed from Expert Review by Dan Romascanu |
2006-07-25 |
14 | 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 … 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 |
2006-06-27 |
07 | (System) | New version available: draft-ietf-ipcdn-pktc-eventmess-07.txt |
2006-06-21 |
14 | Dan Romascanu | State Changes to Expert Review from AD is watching by Dan Romascanu |
2006-06-21 |
14 | Dan Romascanu | 6/20/2006 - Waiting for MIB Doctor Review - call for a volunteer issued. |
2006-06-20 |
14 | Dan Romascanu | 6/20/2006 - background information required from WG chairs |
2006-06-20 |
14 | (System) | State Changes to AD is watching from Dead by system |
2006-06-19 |
06 | (System) | New version available: draft-ietf-ipcdn-pktc-eventmess-06.txt |
2006-05-05 |
14 | (System) | State Changes to Dead from AD is watching by system |
2006-05-05 |
14 | (System) | Document has expired |
2006-04-05 |
14 | Dan Romascanu | Shepherding AD has been changed to Dan Romascanu from Bert Wijnen |
2005-11-28 |
14 | Bert Wijnen | State Changes to AD is watching from Dead by Bert Wijnen |
2005-11-28 |
14 | Bert Wijnen | Status date has been changed to 2005-11-28 from |
2005-10-27 |
05 | (System) | New version available: draft-ietf-ipcdn-pktc-eventmess-05.txt |
2005-09-02 |
14 | (System) | Document has expired |
2005-09-02 |
14 | (System) | State Changes to Dead from AD is watching by system |
2005-08-16 |
14 | Bert Wijnen | Draft Added by Bert Wijnen in state AD is watching |
2005-02-22 |
04 | (System) | New version available: draft-ietf-ipcdn-pktc-eventmess-04.txt |
2004-02-17 |
03 | (System) | New version available: draft-ietf-ipcdn-pktc-eventmess-03.txt |
2003-10-28 |
02 | (System) | New version available: draft-ietf-ipcdn-pktc-eventmess-02.txt |
2003-01-17 |
01 | (System) | New version available: draft-ietf-ipcdn-pktc-eventmess-01.txt |
2002-10-29 |
00 | (System) | New version available: draft-ietf-ipcdn-pktc-eventmess-00.txt |