Note: This ballot was opened for revision 11 and is now closed.
Summary: Needs a YES.
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
- 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.
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.
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
[Updated to add:]
Please re-use ABNF constructs defined in RFC 5234 instead of redefining them
3.4.1 - DIGIT and SP are already defined in 5234.
3.4.2 - LF is already in 5234.
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