Subject: [Syslog] Review of draft-ietf-syslog-protocol-17.txt

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 25 Sep 2006 12:39:24 -0400

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog