[Syslog] Review of draft-ietf-syslog-protocol-17.txt
"Sharon Chisholm" <schishol@nortel.com> Mon, 25 September 2006 16:50 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRtex-0002Nm-Rx; Mon, 25 Sep 2006 12:50:23 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRtew-0002IN-Nw for syslog@ietf.org; Mon, 25 Sep 2006 12:50:22 -0400
Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRtUO-0001aD-Mw for syslog@ietf.org; Mon, 25 Sep 2006 12:39:31 -0400
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k8PGdQd29431 for <syslog@ietf.org>; Mon, 25 Sep 2006 12:39:26 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 25 Sep 2006 12:39:24 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40AF6EAF4@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Review of draft-ietf-syslog-protocol-17.txt
thread-index: AcbgwSiBjbwtZRMaSWqmTH99sPOEmg==
From: Sharon Chisholm <schishol@nortel.com>
To: syslog@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0
Cc:
Subject: [Syslog] Review of draft-ietf-syslog-protocol-17.txt
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
Hi It's been a few revisions since I've given the protocol draft a good read, so when Chris called for reviewers I figured I should give it's a go. In general, I think the document is in good shape, but I have some comments and nits. There was one major change while I was napping which I'm not sure was for the better. That is my item number 1 below: Comments -------- C-1. Section 6.3.2 says that standard SD-IDs don't have an @ sign in them while proprietary ones do. I much preferred the x-acme approach of earlier drafts. This provided a well-behaved namespace that I understood how to manage within my company and in fact was starting to be used. This foo@acme stuff opens syslog up to chaos and anarchy, or at the very least it will lead to a proliferation of duplicate parameters among different products from the same ACME. Plus, x-acme was much easier to read and understand. C-2. Section 6.1 does not actually use the term minimum maximum, although this term is used later in the document. I think it would be helpful if it did because otherwise there is some confusion in the first paragraph around whether we are specifying maximum message length. C-3. In section 6.1, second paragraph I'm having deja-vu, because I thought we agreed to recommend one way or other whether messages were suppose to be dropped or truncated. The rest of the document talks in terms of truncation. C-4. In section 6.2.6, I was originally going to complain about the SHOULD, but then when I read all the way down to the end of the document I found some additional guidance in the non-normative section which explains some use cases as to when you might want to do something else. It seems these can be better linked. I'd suggest adding either a cross reference to the appendix of each of these sections to the specific spot where people can find more information about the specific SD-PARAM or have a general note at the start of section 6 before the different parameters start getting explained. C-5. In section 7.1, I got a little nervous about the implication that if the sender *was* confident in their time stuff they would not send this field. This would also be what someone would do if they didn't support it, I imagine. Can we tighten this up so that if the sender has any doubts about their time stuff they MUST support this timeQuality? C-6. In section 7.3.3, can we expand 'enc' to 'encode'. Those three extra letters add a lot of readability. C-7. In section 7.3.3, would be worth specifying some strings for other potentially popular encodings while we are here? C-8. In section 8.2 It says, "This document does not impose any restrictions on the MSG or PARAM-VALUE content. As such, they MAY contain control characters, including the NUL character." but in section 6.4 it says 'The sender SHOULD avoid octet values below 32 (the traditional US-ASCII control character range except DEL).' Not that this means people won't see them, but it does mean that technically some non-mandatory restrictions have been made by this document. C-9. In section 8.4, it makes replay sound like a features, rather then a security concern. Do we mean to? It is in some notification systems, but I just want to verify. C-10. In section 8.5, I would suggest that sequence numbers, if supported, can be used to detect problems. C-11. In section 8.8, it would seem that reliable transport solving this problem assumes that some form of mutual relationship is established. It might be worth expanding on this since one could in theory reliably deliver messages to the wrong host. C-12. In section A-2, last paragraph, did we mean to say 'larger minimum size', or 'larger minimum maximum size' Nits ---- N-1. In section 1, it claims 'This document has been written with the spirit of RFC 3164 [16] in mind.', what exactly does that mean? The 'spirit of'? N-2. In section 5, first paragraph, there is a reference to [15] without some friendly text in front of it. I'd suggest RFC XXXX, with an understanding that the RFC editor will fix that later. N-3. In section 5, second paragraph, the phrase 'due to transmission or similar errors.' seems problematic to me. It implies transmission is an error, not transmission errors. How about 'transmission errors or other problems."? N-4. Section 6.1, third paragraph has the word 'trucation' instead of 'truncation'. N-5. In section 6.2.1 we are first introduced to definitive sounding set of values for Facility and Severity and then told they are non-normative. If they are non-normative, that should be made clear before they are introduced. N-6, In section 6.3.4, it says "An exception is the addition of a new OPTIONAL PARAM-NAME to an existing SD-ID, what MAY be done." which doesn't work. Should that say 'which MAY be done'? N-7 In section 9.1, I would replace 'according to this document' with 'Defined in RFCXXXX - RFC Editor: replace XXXX with actual RFC number & remove' Otherwise IANA might not have the right information for its database and/or the document might not get updated. N-8. Why is the author information twice in the document? N-9. In section A.5, technically you are using lower camel case. Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
- [Syslog] Review of draft-ietf-syslog-protocol-17.… Sharon Chisholm