Transmission of Syslog Messages over TCP

Note: This ballot was opened for revision 14 and is now closed.

(Wesley Eddy) Yes

(Dan Romascanu) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Adrian Farrel) No Objection

Comment (2011-12-11 for -)
It would be good if the Introduction included a brief paragraph on the
purpose/content of this document. The first paragraph of Section 4
contains roughly the necessary material.


I am uncomfortable (but not quite to the point of a Discuss) by the way
that this I-D flies in the face of IETF consensus to recommend the use
of TLS. I believe this could be resolved by a slightly stronger 
statement on the intent of the document to facilitate interoperability
with legacy deployments whild continuing to recommend the use of TLS.
I.e. "this document does not recommend that new implementations or
deployments use syslog over TCP except for the explicit purpose of 
interoperating with existing deployments."


I am surprised that section 5 does not mention TCP/AO.

(Stephen Farrell) No Objection

Comment (2011-12-14 for -)
- I agree with Dave's discuss points 1,2 and 4 and sympathise with
his point 3.

- Be nice to add the hex values that go with %d32 and %d126 just to
be super-clear

- 3.1 mentions "relays" but those weren't mentioned in the intro -
be nice to say what those are in section 1.

- What does "not available" mean at the end of section 5?  I think
it would be better to say "This protocol SHOULD NOT be used unless
syslog/tls [RFC5425] has been tried and failed, e.g. because there
is no listener on port 6514."

- I think you could note that falling back to this if syslog/tls
fails could in principle indicate that an attack is happening. If
there's a sensible action to take there (e.g. some local logging of
the failure of the TLS handshake or whatever in addition to remote
logging using this) that'd maybe be worth saying.

(David Harrington) (was Discuss) No Objection

(Russ Housley) (was Discuss) No Objection

(Pete Resnick) No Objection

Comment (2011-12-13 for -)
I must agree with Robert's comment that the port allocation seems inappropriate. However, it concerns me that the port that is chosen some of the time is the rsh port. If there is an unregistered port that is widely used for this, it should be registered.

I agree with Adrian's comment that some of the contents of section 4 would be terribly helpful in the intro.

I think Peter's comment regarding character terminology is important, and I'm happy to see you're addressing it.

I am ambivalent as to whether the document should be Informational or Historic. I lean slightly toward Informational since it is describing widespread current practice.

[Updated to add:]

Please re-use ABNF constructs defined in RFC 5234 instead of redefining them here:

3.4.1 - DIGIT and SP are already defined in 5234.

3.4.2 - LF is already in 5234.

(Peter Saint-Andre) No Objection

Comment (2011-12-08 for -)
According to BCP 166 (RFC 6365):

   The terms "charset", or "character encoding scheme"
   and "coded character set", are strongly preferred over the term
   "character set" because "character set" has other definitions in
   other contexts, particularly outside the IETF.

Please consider changing the term used in Section 3.1 of this I-D to match BCP 166.

(Robert Sparks) (was Discuss) No Objection

(Sean Turner) No Objection

Comment (2011-12-14 for -)
I tend to agree with Dave here.