Transmission of Syslog Messages over TCP
draft-gerhards-syslog-plain-tcp-14

[Ballot discuss]
updated for -13-
(numbering of points updated)

1. I think the applicability statement is not consistent with IETF consensus:
"It is hoped that this description will promote future interoperability."
I do not believe this document will result in future interoperability for syslog, and sends the wrong message to the community about how to achieve interoperability, when we already have a standard for syslog/TLS that represents IETF consensus for strong security and consistent message formatting. I think this document will delay the wide deployment of the IETF standards for syslog.

2. I especially do not believe it is in the IETF interest to have this document say that many have successfully squatted on port 514, and to suggest that it is safe to squat on port 514 for syslog/tcp.

3.  Despite my belief that publishing this document will not make the Internet run better, I could accept publication of this document with a Historic or Obsolete label and a big IESG Note that says

"The IESG does NOT RECOMMEND implementing or deploying syslog over plain tcp, which is documented in this document, because it lacks the ability to enable strong security [BCP61].

syslog/tls [RFC5425] is RECOMMENDED for implementation so that security features are available to operators who want to deploy secure syslog, and those security features can be turned off for those who do not want them."

-13- had been changed to Historic, but is still missing an IESG Note in the writeup.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Transmission of Syslog Messages over TCP) to Historic RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Transmission of Syslog Messages over TCP'
  as an Historic RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-01-30. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

This is a second Last Call, following the IESG discussions which led
to a number of changes including (but not limited to) changing the
Intended Status of the document from Informational to Historic.

Abstract


  There have been many implementations and deployments of legacy syslog
  over TCP for many years.  That protocol has evolved without being
  standardized and has proven to be quite interoperable in practice.
  This memo describes how TCP has been used as a transport for syslog
  messages.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-gerhards-syslog-plain-tcp/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-gerhards-syslog-plain-tcp/


No IPR declarations have been submitted directly on this I-D.

[Ballot comment]
- 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.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot discuss]
As co-chair of syslog WG, I have worked witrh Rainer and Chris closely, and understand that they feel this is valuiable documentation for the community. I disagree for a number of reasons.

1. I think the applicability statement is not consistent with IETF consensus:
"It is hoped that this description, along with the assignment of a standardized port for this protocol, will promote future interoperability."
IETF consensus is to use strong security [RFC3365 - BCP61] to provide secure interoperability. RFC5424 and RFC5425 have IETF consensus as the right way to achieve syslog interoperability, and to do so securely.  Based on BCP61, RFC5424 and RFC5425 provide mandatory-to-implement security features, which may be configured by operators to provide no security if operators so choose (RFC5425, section 5).
I do not believe this document will result in future interoperability for syslog, and sends the wrong message to the community about how to achieve interoperability. I do not believe it is in the IETF interest to assign a standard port number for syslog/tcp.

2. I believe this document, if published, should be published as Historic (or Obsoleted by RFCs 5424 and 5425).
I believe this designation is important based on experience with RFC3164, which allegedly documented BSD Syslog, but actually ended up being a survey of existing syslog/UDP implementations that showed how on-the-wire formats of the many existing implementations had little in common.
Most only had the first byte in common. Many vendors claimed "compliance" to RFC3164.
I believe this document needs to have it very clearly spelled out that this is only a document of past practices, is NOT an IETF standard, and should NOT be implemented in new implementations.

RFC3164 (legacy syslog/udp) was obsoleted by RFC5424. This legacy syslog/tcp document should be handled the same way.

3. Personally, I don't see a lot of value to this document.  Similar to existing implementations of syslog that run over udp, existing implementations of syslog that run over tcp are not very consistent.
This document does not contain enough detail for syslog receivers/applications to process incoming legacy messages; application implementers would need to do additional research into the formats used by specific implementations. Therefore, this document does not serve to significantly improve interoperability between senders and receivers.
Cross-vendor interoperability could be improved by standardizing a port#, and recommending consistent implementation choices, such as message layout, support for octet-counting versus framing in the message format, internationalized character sets, and transport session initiation and closure.
The IETF has already standardized support for a message layout, and internationalized character sets in RFC5424.
The IETF has already standardized a transport for syslog messages in RFC5425, including session initiation and closure, a standard port#, as well as strong security as called for by BCP61.
I have concerns that publishing this as an RFC sends the wrong message to the community,  and am especially concerned that vendors wil use this to claim "compliance" to an IETF RFC,  just as they did with RFC3164.
This could slow vendors moving to support interoperability by using the IETF standards defined in RFC5424 and RFC 5425.

4.  Despite my belief that publishing this document will not make the Internet run better, I could accept publication of this document with a Historic or Obsolete label and a big IESG Note that says

"The IESG does NOT RECOMMEND implementing or deploying syslog over plain tcp, which is documented in this document, because it lacks the ability to enable strong security [BCP61].

syslog/tls [RFC5425] is RECOMMENDED for implementation so that security features are available to operators who want to deploy secure syslog, and those security features can be turned off for those who do not want them."

[Ballot comment]
Most of the document is written with a tone of "here's what we see deployed already",
which is good. In a few places it drifts into a tone that would be more appropriate
for "and we want people to make more things that do this". Section 3.2, in particular,
reads more like a protocol definition than a description of already existing behavior.
Section 3.4 uses the phrase "usually preferred". Something like "has caused fewer
problems" would be more descriptive (if it's accurate).

[Ballot discuss]
Capturing a description of what's observable in the wild is a very good thing -
thank you for putting this document together. If that's all this document is
trying to do, why isn't it Historic, and why doesn't it register the port(s) that
existing implementations are actually using?

A new port for something that's not a standard (and is not already the de facto port)
doesn't seem like the right thing to do.

[Ballot discuss]
Some updates are needed to Section 6 prior to publication.  Thanks to
  Brian Carpenter for flagging these issues in his Gen-ART Review of
  17-Nov-2011.

  6.  IANA Considerations

  --> needs an introductory sentence asking for a Registered TCP port
      according to the description that follows.

        Service Name - syslog-tcp
        Transport Protocol - TCP
        Assignee - IESG
        Contact - IETF Chair
        Description - syslog protocol (RFC 5424) over TCP
        Reference - This document
        Port Number - 10514

  --> The port number should be  for consistency with section 3.3.

  Note to the IANA - we're making an assumption that this document
  needs to be compliant with Section 8.1.1. of RFC 6335.  If so, then
  the above table is our best guess.  We'd also like to use 10514/tcp
  for this protocol as syslog over udp is assigned 514.

  --> This note should be tagged for removal by the RFC Editor after
      IANA assigns the port number.

[Ballot discuss]
Some updates are needed to Section 6 prior to publication.  Thanks to
  Brian Carpenter for flagging these issues in his Gen-ART Review of
  17-Nov-2011.

  6.  IANA Considerations

  --> needs an introductory sentence asking for a Registered TCP port
      according to the description that follows.

        Service Name - syslog-tcp
        Transport Protocol - TCP
        Assignee - IESG
        Contact - IETF Chair
        Description - syslog protocol (RFC 5424) over TCP
        Reference - This document
        Port Number - 10514

  --> The port number should be  for consistency with section 3.3.

  Note to the IANA - we're making an assumption that this document
  needs to be compliant with Section 8.1.1. of RFC 6335.  If so, then
  the above table is our best guess.  We'd also like to use 10514/tcp
  for this protocol as syslog over udp is assigned 514.

  --> This note should be tagged for removal by the RFC Editor after
      IANA assigns the port number.

[Ballot comment]
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.

[Ballot comment]
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.

IANA understands that, upon approval of this document, there is a single
IANA action that must be completed.

In the Service Name and Transport Protocol Port Number Registry located at:

http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml

a new registration will be made as follows:

Service Name - syslog-tcp
Transport Protocol - TCP
Assignee - IESG
Contact - IETF Chair
Description - syslog protocol (RFC 5424) over TCP
Reference - [ RFC-to-be ]
Port Number - [ TBD - see below ]

IANA notes that the authors request that port number 10514 be assigned
as the value for this registration. If the value is available at the
time the document is approved, IANA will use this suggestion.

IANA understands that this is the only action required upon approval of
this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Transmission of Syslog Messages over TCP) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Transmission of Syslog Messages over TCP'
  as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-12-07. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  There have been many implementations and deployments of legacy syslog
  over TCP for many years.  That protocol has evolved without being
  standardized and has proven to be quite interoperable in practice.
  The aim of this specification is to explain how TCP has been used as
  a transport for syslog messages.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-gerhards-syslog-plain-tcp/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-gerhards-syslog-plain-tcp/


No IPR declarations have been submitted directly on this I-D.

The shepherd write-up by Randy Presuhn:

As required by RFC 4858, this was filled in using the current template
for the Document Shepherd WriteUp, dated September 17, 2008.

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

Randy Presuhn.
Yes.


  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed?

The document is an individual submission and not associated with
any Working Group.  It is, however, a work that is of interest to
the syslog Working Group which was concluded in October of 2010.
The document has been discussed on the IETF mailing list that was
used for the syslog Working Group.  The reviews were thoughtful
and displayed that the document had been read and understood.
The mail list archives are here:
http://www.ietf.org/mail-archive/web/syslog/current/maillist.html

 
  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

The document does not need any additional review.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

No concerns or issues.  I am not aware of any IPR disclosures.
This document describes the behavior of in-the-wild implementations
of a legacy protocol, and as such, identifies several potential
problems with that protocol.

History:
The syslog Working Group was chartered to produce a secure transport
for event messages.  Specific to this, the Working Group produced
the following documents:
- RFC 5424: The Syslog Protocol (Proposed Standard)
- RFC 5425: Transport Layer Security (TLS) Transport Mapping for
  Syslog (Proposed Standard)
- RFC 5426: Transmission of Syslog Messages over UDP (Proposed Standard)
- RFC 6012: Datagram Transport Layer Security (DTLS) Transport
  Mapping for Syslog (Proposed Standard)
(Other documents were produced but they do not directly address the transport.)

The documents recommend that TLS and DTLS be used for the transport
of event messages.  Some people have expressed an opinion that a
TCP transport is not needed since transmission control and security
are addressed in the recommended documents.  On the other hand,
the authors and the community would like to see this document
proceed as INFORMATIONAL so that interoperability may be achieved
with the many impmentations that currently exist.  Additionally,
the IETF has received a liaison statement from the OIF in support
of publishing this document as they plan to use it.


  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it? 

The discussions on the mailing list show that a few people have
strong concurrence.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

No appeals have been threatened.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

The document passes the nit checker.  There are no MIBs, media types
or URIs in the document.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

The document has split the references into normative and informative.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

The authors are requesting a TCP port number for this protocol.
Historically, the syslog protocol has been run atop 514/udp.
Some people have been using 514/tcp for this even though that
port number has been assigned to a different protocol.  Others
have been using 10514/tcp.  No other registries are being
requested from the IANA.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

The ABNF code checks out with Bap. Bap wants to use hex values
rather than decimal but the authors are not feeling compelled
to change that.  "OCTET" and "SYSLOG-MSG" are not defined in
this document, coming instead from the ABNF in RFC 5424.


  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:
    Technical Summary
        Relevant content can frequently be found in the abstract
        and/or introduction of the document. If not, this may be
        an indication that there are deficiencies in the abstract
        or introduction.

There have been many implementations and deployments of legacy syslog
over TCP for many years.  That protocol has evolved without being
standardized and has proven to be quite interoperable in practice.
The aim of this specification is to explain how TCP has been used as
a transport for syslog messages.

    Working Group Summary
        Was there anything in WG process that is worth noting? For
        example, was there controversy about particular points or
        were there decisions where the consensus was particularly
        rough?

The WG mailing list seems content with the document.

    Document Quality
        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to
        implement the specification? Are there any reviewers that
        merit special mention as having done a thorough review,
        e.g., one that resulted in important changes or a
        conclusion that the document had no substantive issues? If
        there was a MIB Doctor, Media Type or other expert review,
        what was its course (briefly)? In the case of a Media Type
        review, on what date was the request posted?

There are existing implementations of the protocol.  It is in use
by Cisco, Adiscon, Splunk, SolarWinds, rsyslog, and syslog-ng,
to name a few.

State Change Notice email list has been changed to rgerhards@adiscon.com, clonvick@cisco.com, draft-gerhards-syslog-plain-tcp@tools.ietf.org, ietfdbh@comcast.net, randy_presuhn@mindspring.com from rgerhards@adiscon.com, clonvick@cisco.com, draft-gerhards-syslog-plain-tcp@tools.ietf.org, ietfdbh@comcast.net