[Syslog] review of draft-ietf-syslog-protocol-17

rfgraveman@nac.net Mon, 02 October 2006 19:23 UTC

Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUTO7-0002lg-P7; Mon, 02 Oct 2006 15:23:39 -0400
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUTO6-0002la-Ra for syslog@lists.ietf.org; Mon, 02 Oct 2006 15:23:38 -0400
Received: from smtp-out1.oct.nac.net ([]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GUTO5-00046X-Js for syslog@lists.ietf.org; Mon, 02 Oct 2006 15:23:38 -0400
Received: (qmail 57982 invoked by uid 0); 2 Oct 2006 15:23:37 -0400
Received: from by smtp-out1.oct (envelope-from <rfgraveman@nac.net>, uid 0) with qmail-scanner-1.25 (uvscan: v4.2.40/v4291. sophie: 2.14/3.73. f-prot: 4.1.1/3.13.4. Clear:RC:1( Processed in 0.298245 secs); 02 Oct 2006 19:23:37 -0000
Received: from unknown (HELO webmail.nac.net) ( by smtp-out1.oct.nac.net with SMTP; 2 Oct 2006 15:23:36 -0400
Received: from (SquirrelMail authenticated user rfgraveman) by webmail.nac.net with HTTP; Mon, 2 Oct 2006 15:23:37 -0400 (EDT)
Message-ID: <33100.>
Date: Mon, 02 Oct 2006 15:23:37 -0400
From: rfgraveman@nac.net
To: syslog@lists.ietf.org
User-Agent: SquirrelMail/1.4.5
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Subject: [Syslog] review of draft-ietf-syslog-protocol-17
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>, <mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>, <mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

I reviewed this draft and believe it is in good shape and reflects the
discussions on the list and consensus of the working group. After one more
round, it should IMO be ready to go to the AD.

In addition to or in agreement with the other review comments that have
been posted, I sent some editorial comments to the author and also made a
couple of small comments about:

1. replacing the reference to 3513 with 4291
2. clarifying the text about when UTF-8 versus "plain ASCII" is present in a
   SD-PARAMs versus the MSG
3. simplifying the overloaded use of HOSTNAME, Hostname, and hostname in
   Section 6.2.4.

The details are below.

Rich Graveman

   If an IPv4 address is used, it MUST be in the format of the dotted
   decimal notation as used in STD 13 [4].  If an IPv6 address is used,
   a valid textual representation described in RFC 3513 [10], Section
   2.2, MUST be used.
* RFC 4291 (DS) obsoletes 3513. Section number 2.2 is still correct.
-------------------from 6.2.4
   The NILVALUE SHOULD only be used when the sender has no way to obtain
   its real hostname.  This situation is considered highly unlikely.
* We now have HOSTNAME, Hostname, and hostname. Maybe just:
* s/its real hostname/any of the names or addresses listed above/
-------------------from 6.4
   If a sender encodes MSG in UTF-8, the string MUST start with the
* s/MSG/a MSG with international characters/
* Comment: Above, if I am correct, the SD-PARAM MUST be encoded in UTF-8,
* even though the examples show "plain ASCII." Technically, this is
* correct, becasue plain ASCII is legal UTF-8. But here, plain-ASCII
* UTF-8 should not require a BOM.
   Unicode byte order mask (BOM), which for UTF-8 is ABNF %xEF.BB.BF.
   The sender SHOULD also include an "meta" SD-ID with an "enc"
   parameter within the STRUCTURED-DATA.  The sender MUST encode in the
   "shortest form" and MAY use any valid UTF-8 sequence.

   If a receiver receives MSG starting with a BOM, it MUST assume UTF-8
   encoding.  For the reasons outlined in UNICODE TR36 [13], section
   3.1, a receiver MUST NOT interpret messages in the "non-shortest
   form".  It MUST NOT interpret invalid UTF-8 sequences.

   If a sender does not encode MSG in UTF-8, the string MUST NOT start
   with the Unicode BOM.  If MSG is not encoded in UTF-8, the sender MAY
   use any other encoding (including binary data).
* If the above comment makes sense, then turn it around and say:
* If the MSG string starts with the Unicode BOM, then it MUST be interpreted
* as UTF-8.

Syslog mailing list