Re: [Syslog] WGLC: protocol

"tom.petch" <> Fri, 18 August 2006 17:39 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1GE8JE-0006eQ-A3; Fri, 18 Aug 2006 13:39:04 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1GE8JC-0006eD-TJ for; Fri, 18 Aug 2006 13:39:02 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1GE8JC-0002W2-8P for; Fri, 18 Aug 2006 13:39:02 -0400
Received: from pc6 ( []) by (Postfix) with SMTP id BB71DE0002C7; Fri, 18 Aug 2006 18:38:52 +0100 (BST)
Message-ID: <000401c6c2e4$0f11e1c0$0601a8c0@pc6>
From: "tom.petch" <>
To: David Harrington <>,
References: <0b4e01c6c0c9$ef25f700$>
Subject: Re: [Syslog] WGLC: protocol
Date: Thu, 17 Aug 2006 16:18:53 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "tom.petch" <>
List-Id: Security Issues in Network Event Logging <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

The only comments I would add are

- p.18 suggest replacing 'ABNF %D92' by 'ABNF %d92'

- 6.4 suggest ' a "meta" SD-ID'  for 'an "meta" SD-ID'

- 8.1 suggest replacing. 'security issues bound with UNICODE' by
  'security issues with UNICODE' or
  'security issues bound up with UNICODE'

 - On ITU perceived severity, I would stay with the Alam MIB reference.  I seem
to recall that the discussions in disman were complex and that what is there is
the best compromise.  M.3100 only talks of perceivedSeverity in a reference to
Q.821, it uses severity in several other contexts with different enumerations
for the same severity in different places.  I think that disman provided a good
interpretation of the complexity of the ITU Recommendations and that we cannot
better that in syslog.
Tom Petch

----- Original Message -----
From: "David Harrington" <>
To: <>
Sent: Wednesday, August 16, 2006 2:21 AM
Subject: [Syslog] WGLC: protocol

> 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
> 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
> identified
> some obsolete references:
> RFC 2234 has been obsoleted by RFC4234
> RFC 3513 has been obsoleted by RFC4291
> 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.
> supports parseable.
> Apparently the Oxford dictionary supports parseable, based on a
> discussion at, 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<enterprise
> ID> subtree assigned by IANA to that enterprise. The enterpriseId MUST
> contain only a value from the
><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 mailing list adddress. That should be
> used rather than the 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
> _______________________________________________
> Syslog mailing list

Syslog mailing list