Transmission of Syslog Messages over TCP
Summary: Needs a YES.
Note: This ballot was opened for revision 11 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
( spt ) No Objection
Comment (2011-12-14 for -)
I tend to agree with Dave here.