<inline> Rainer PS: I might be offline tomorrow...
> -----Original Message----- > From: David Harrington [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 15, 2006 6:22 PM > To: [EMAIL PROTECTED] > Subject: [Syslog] WGLC: protocol > > Hi, > > Here is my review of the protocol-17 document. > > Let me apologize (slightly) for such a thorough review, Nothing to apologize, I am glad it happened. I just feared it would occur when I have the least ability to do serious work. Anyhow, I have been able to edit it. Find comments inline... > 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. > Removed > -- 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. I am working on that, but it is a pain with the low-bandwidth, instable Internet I currently have ;) > > -- 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 I have changed the references, but have not (Yet) been able to check if that means any material differences. A quick check tells me it does not. > > 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" I have no references here, either. If someone could verify, I would appreciate. Alternatively, Chris had recommended that we drop this section. If there is no objection, we could also do that. > -- 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. changed > > In section 5.1, it says "This ensures interoperability ...". This > might be better stated as "This ensures at least a minimum > interoperability ..." > Changed > Section 6 is entitled "Required syslog format". I suggest making it > simply "Syslog Message Format". Changed > > 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? This was discussed on-list and the consensus at that time was that the behaviour should be unspecified. The reasoning was to avoid any complexity at the receiver. I have added the following sentence: The receiver MAY discard the message or MAY try to process as much as possible in this case. > > 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. Agree, changed to 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. These three fields must not necessarily be operator-assigned (I guess most often the vendor-specific defaults be used). I have added the following sentence to all three: This field MAY be operator-assigned. > > 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. > Added > 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." changed > > 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"? We could add a preferred address param, but would that actually be useful? I am not sure, as we have the hostname (granted, a FQDN) for the orginator. The (potential) list should help log analysers. It can list all addresses it may send from there. > > 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. Agreed, changed "... MUST always contain..." > > 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. changed > > 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. Changed NOTE on both above: I left the size as is, as this was already a compromise given the small guaranteed size of a message. I expect that in the vast majority of cases these fields will be USASCII strings. > > > -- 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/ > Corrected > enterpriseId or enterpriseID - inconsistent usage. That stems back to the discussion that we should use camelcase on all parameters. Thus I have change to enterpriseId whereever used. > > 6.2.4 "described in RFC 3513" should this be ", as described in RFC > 3513"? Yes - corrected > > 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." Excellent - thank you! > > 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. I have added this note to the text. > > -- 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. I could merge this in from a transport document, if that would help. Please advise. > > -- IANA considerations -- > > Good. > > -- Authors -- > > We now have a [EMAIL PROTECTED] mailing list adddress. That should be > used rather than the employees.org address. changed > > You should identify that I work for Huawei Technologies USA. > David Harrington Huawei Technologies USA Email: [EMAIL PROTECTED] Ok? > -- 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 > [email protected] > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
