Hi, Here is my review of the protocol-17 document.
Let me apologize (slightly) for such a thorough review, late in the process, but as co-chair I need to say I reviewed this thoroughly and that I agree it is ready to be published as a standard. I am much pickier about a document I will sign-off as co-chair than one I accept as a casual WG participant. For the most part, this review focuses on publication and standardization requirements rather than on the technical design of the protocol. I plan to do that review separately, and consider the WG members more competent in syslog specifics than me. >From the standpoint of what I reviewed, this document generally looks good. dbh -- idnits -- The document has the correct IPR boilerplates, RFC2119 boilerplate, and the document passes the automated idnits tool. Idnits found two reference problems that should be addressed. Reference [2] is never used in the text. Reference [17] is never used in the text. -- xml2rfc validation -- Since the source for this document is written in xml2rfc format, the RFC editor will request that you submit a copy of the xml2rfc source with the document to be published. It is a good thing if the sources used to publish the final document are consisteent with the copy we have for future update work, so it is a good thing to fix any known problems in the xml2rfc source before submitting it to the RFC editor. The rfc editor typically does not return their edited version to us. The xml2rfc-validator tool at http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/valid.cgi identified a number of usages that are invalid according to the rfc2629.dtd, and some usages that have been deprecated or obsoleted by the xml2rfc tool. The xml2rfc tool will still accept these on the basis of being liberal in what it accepts, but we should also be conservative in what we send. It would be good to fix all these errors and warnings. -- References -- The xml2rfc-validator tool at http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/valid.cgi identified some obsolete references: RFC 2234 has been obsoleted by RFC4234 RFC 3513 has been obsoleted by RFC4291 6.2.1.1 says The Alarm MIB defines ITU perceived severities. Actually, don't ITU M.3100 and X.733 define the severities, and the Alarm MIB just uses them? I don't have a copy of M.3100 or X.733, so I cannot check this; can somebody check this? I think we should reference the original definition, and then we can point out that the Alarm MIB references the ITU severities as well. According to RFC3877, the references are "ITU Recommendation M.3100, 'Generic Network Information Model', 1995" and "ITU Recommendation X.733, 'Information Technology - Open Systems Interconnection - System Management: Alarm Reporting Function', 1992" -- RFC2119 language -- Section 5 states the UDP "transport is REQUIRED for interoperability ...". I think this might be better phrased as the UDP "transport is mandatory to implement for compliance to the standard to support interoperability ..." or remove the sentence since the next section discusses the minimum required transport mapping. In section 5.1, it says "This ensures interoperability ...". This might be better stated as "This ensures at least a minimum interoperability ..." Section 6 is entitled "Required syslog format". I suggest making it simply "Syslog Message Format". Section 6.1: "After trucation, the message MAY contain invalid UTF-8 encoding or invalid STRUCTURED-DATA." Does this need an addendum to standardize subsequent behavior? If the truncated message now contains invalid content, should the whole message be discarded, or should the receiver try to process as much as it can, even if it is incomplete, and the results of subsequent processing could be misleading to an operator? 6.2.1: "A receiver MUST NOT assume any specific semantics by default." I think this fails the RFC2119 test - RFC2119 keywords MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm; this assumption would happen after the message came off the wire, so should not impact interoperability on-the-wire, and it should have no effect on behavior such as retransmission. Obviously, a management application might cause a configuration change based on a faulty assumption, but I don't think that is a protocol issue. I think the maximum RFC2119 language here would be a SHOULD NOT. 6.2.5 This section should mention that APP-NAME is an operator-configured value, which justifies the use of SHOULD rather than MUST here. 6.2.6 if operator-configured, then ditto. 6.2.7 if operator-configured, then ditto. 6.3.2 "to be assigned by IETF CONSENSUS" should include a reference to BCP26 (RFC2434), since IETF CONSENSUS has a specific meaning defined in the BCP. 6.3.4 "An exception is the addition of a new OPTIONAL PARAM-NAME to an existing SD-ID, what MAY be done." This strikes me as incorrect English grammar; I recommend rewording it. Here is some suggested text: "OPTIONAL PARAM-NAMEs MAY be added to an existing SD-ID." 7.2.1 Can it list an ip address in the "ip" parameter AND provide a list of multiple "ip" parameters in an "origin" element? If not, why not? Wouldn't it be useful to provide the "origin" list, but also to identify its "preferred" address for syslog purposes in "ip"? 7.2.3 "It always contains the name of the generating software," - should this one be MUST? "whereas APP-NAME can contain anything else, including an operator-configured value." Section 6.2.5 should mention that APP-NAME is an operator-configured value. If the software parameter contains UTF-8, then it is important to specify the maximum length of strings in octets rather than characters, since characters can be multi-byte. 7.2.4 If the swVersion parameter contains UTF-8, then it is important to specify the maximum length of strings in octets rather than characters, since characters can be multi-byte. -- spelling -- /parsable/parseable/g neither MS-Word nor Merriam-Webster recognizes either spelling. Wikipedia supports parseable under parsing. computing-dictionary.thefreedictionary.com supports parseable. Apparently the Oxford dictionary supports parseable, based on a discussion at apache.org, but I don't have a subscription to check it. /trucation/truncation /conceptionally/conceptually/ /mimimize/minimize/ /timezone/time zone/g according to MS-Word and Mirriam-Webster online /implementor/implementer/g for consistency with rfc-editor boilerplate text. /any-enterprise assigned/any enterprise-assigned/ enterpriseId or enterpriseID - inconsistent usage. 6.2.4 "described in RFC 3513" should this be ", as described in RFC 3513"? 7.2.2 "Only that number and any-enterprise assigned ID below it MUST be specified in the "enterpriseId" parameter." seems awkward. Would this be better as "An enterprise is only authorized to assign values within the iso.org.dod.internet.private.enterprise.<enterprise ID> subtree assigned by IANA to that enterprise. The enterpriseId MUST contain only a value from the iso.org.dod.internet.private.enterprise.<enterprise ID> subtree." 7.3.2 /integer/INTEGER/ Note that the semantics in RFC3418 are "The time (in hundredths of a second) since the network management portion of the system was last re-initialized." This of course relates to the SNMP-related management portion of the system, which MAY be different than the syslog-related management portion of the system. -- security considerations Good job describing the potential configuration issues. Since the transport documents will describe the threat models, it is probably acceptable that the threat model is not covered here in the terminology recommended by rfc3552. -- IANA considerations -- Good. -- Authors -- We now have a [EMAIL PROTECTED] mailing list adddress. That should be used rather than the employees.org address. You should identify that I work for Huawei Technologies USA. -- Acknowledgment -- The funding acknowledgment for the RFC Editor function is out of date, but the latest xml2rfc tool corrects it to acknowledge the IASA rather than the Internet Society. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog