RE: [Syslog] WGLC: protocol

"Rainer Gerhards" <> Wed, 16 August 2006 05:38 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1GDE6U-0005uL-Ew; Wed, 16 Aug 2006 01:38:10 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1GDE6T-0005uG-5d for; Wed, 16 Aug 2006 01:38:09 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1GDE6Q-0001je-5a for; Wed, 16 Aug 2006 01:38:09 -0400
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7D2FD9C00C; Wed, 16 Aug 2006 07:39:33 +0200 (CEST)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 18328-06; Wed, 16 Aug 2006 07:39:27 +0200 (CEST)
Received: from (grfint2 []) by (Postfix) with ESMTP id DBAF29C00B; Wed, 16 Aug 2006 07:39:27 +0200 (CEST)
Subject: RE: [Syslog] WGLC: protocol
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 16 Aug 2006 07:37:58 +0200
Content-class: urn:content-classes:message
Message-ID: <>
X-MimeOLE: Produced By Microsoft Exchange V6.5
In-Reply-To: <0b4e01c6c0c9$ef25f700$>
Thread-Topic: [Syslog] WGLC: protocol
Thread-Index: AcbAye5nX/6MyTgHSY2bGGKvmBcxKQAGY+ug
From: Rainer Gerhards <>
To: David Harrington <>,
X-Virus-Scanned: by amavisd-new-2.3.3 (20050822) (Debian) at
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4bb0e9e1ca9d18125bc841b2d8d77e24
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>


PS: I might be offline tomorrow...

> -----Original Message-----
> From: David Harrington [] 
> Sent: Tuesday, August 15, 2006 6:22 PM
> To:
> 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.


> -- 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. 

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
> 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.

> 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.

> 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? 

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:

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.

> 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"?

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.

> 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.


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.
> 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.

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<enterprise
> ID> subtree assigned by IANA to that enterprise. The enterpriseId MUST
> contain only a value from the
><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 mailing list adddress. That should be
> used rather than the address.
> You should identify that I work for Huawei Technologies USA.

      David Harrington
      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