[ipcdn] Summary: draft-ietf-ipcdn-pktc-eventmess-11

Folks,

A new version of draft-ietf-ipcdn-pktc-eventmess (-11) is now available. This incorporates MIB doctor comments from David Harrington, discussions with the co-authors, and feedback from Rich Woundy. A summary of the changes is attached with this email.

The new version of the I-D is available at:

http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-eventmess-11.txt

Thanks!
- S

 MIB doctor (David Harrington) comments that have been incorporated:
------------------------------------------------------------------

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.
[S] Done.

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

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.)
[S] The examples were removed in the modified description. The rest of  the recommendations have been incorporated.

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.
[S] Done (note: The Syslog charter currently does not include BEEP, but this is going to be modified based on David's comments).

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

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.
[S] Done for the following MIB Objects: pktcEventSyslogMsgFormat, pktcEventLogOrg, pktcEventLogId and pktcEventDescrClass.

Enumerations are expandable; do not say in the text that only two formats are supported. Describe the two values, without specifying an upper limit.
[S] The descriptions have been modified.

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.
[S] Done

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? 
[S] It is a locally-meaningful value. This has been clarified.

9) pktcEveneClassReportStatus is dependent on pktcEventDescrReporting; what happens if that object does not exist?
[S] pktcEventClassStatus specifies a group of events. For each event, pktcEventDescrReporting MUST exist. Thus, this condition does not occur. I did add a condition for the table to explicitly indicate this. 

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

11) pktcEventThrottleAdminStatus - writing to the object resets the thresholding state. What does that mean?
[S] Redundant informative statement. It was meant to indicate that the threshold is re-calculated based on the last value of the MIB. This has been removed.

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

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? 
[S] This is a read-write object, what is being specified is default behavior. This is now clearly articulated in the DESCRIPTION. 
14) pktxEventDescrClass - can an event fall into more than one class?
How is this done? 
[S] Yes, and this has been clarified further.

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? 
[S] I have modified this to be an informative statement

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?
[S] The statement starts with "This object will always increase except"...
Thus, if it implements non-volatile storage, then it will increase (unless one of the other conditions occur). I have tried to clarify this.

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?
[S] Done.

18) there are a number places with "to which the priority and display strings belong" - are these really needed? are they accurate?
[S] These are redundant and have been removed.

19) There are a number of SnnmpAdminString objects in the log with no SIZE constraints. 
[S] Three MIB Objects: pktcEventLogAdditionalInfo, pktcEventLogEndpointName, pktcEventLogTargetInfo; Size constraints are not placed to allow for the max size allowed (255). This is now indicated.

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?
[S] This is a log, and it reports 'what happened', irrespective of the reason. So, if a message was not sent, it is not indicated . In the use case described, it will report only the local logging of the event. This has been clarified further.

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.
[S] Added informative text referencing this.

22) targetinfo might exceed capacity with a number of IPv6 addresses.
[S] Yes, and this has been indicated.

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?
[S] As specified currently, this would just be one entry: snmpTrap/192.168.1.2 (as we do not differentiate between users or even ports).

24) I am concerned that objects like AdditionalInfo might overflow the 255t limit of SnmpAdminStrings.
[S] Since this is specified by the vendor, they need to ensure that the length does not exceed. I have added an explicit size constraint and informative text to follow SnmpAdminString definitions.

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.
[S] Done.

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.
[S] Done

27) The Relationship to other MIB modules doesn't mention the syslog-tc-mib.
[S] Since this was not included earlier, it was not mentioned. 

28) pktcEventTransmissionStatus - how will the MTA determine validsyslogServerAbsent? I don't think even syslog can determine that, since it is a one-way protocol.
[S] This can be determined if it is set to a broadcast address, as an example. (Additionally, MTAs can detect ICMP failures.) We can indicate that this is not always detectable.

Other changes include:
- Editorial corrections
- Modifications to the MIB name from PKTC-EVENT-MIB (pktcEventMib) to PKTC-IETF-EVENT-MIB (pktcIetfEventMib) based on the recommendation by the WG co-chair (Jean-Francois) and agreement of the MIB Doctor (David Harrington)

------------
IDNits check:
------------
idnits 2.04.16 

  Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to http://www.ietf.org/ID-Checklist.html:
  ----------------------------------------------------------------------------

     No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFC 3967 for information about using normative references to
     lower-maturity documents in RFCs)

  -- Possible downref: Non-RFC (?) normative reference: ref. 'PKT-SP-PROV'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'RFCABC'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'RFCAAA'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'RFCBBB'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'RFCCCC'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'RFCDDD'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-T-J176'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'ETSITS101909-22'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-ENTERPRISE'

     Summary: 0 errors (**), 0 warnings (==), 9 comments (--).
--------------------------------------------------------------------------------

------------
MIB Check
------------
mibs/pktc-ietf-event-mib.txt:75: [2] {bad-identifier-case} `XXX' should start with a lower case letter
mibs/pktc-ietf-event-mib.txt:75: [2] {object-identifier-not-prefix} Object identifier element `XXX' name only allowed as first element

(note: there are other warnings for the syslog-tc-mib)