The Syslog Protocol
RFC 5424

Received changes through RFC Editor sync (changed abstract to 'This document describes the syslog protocol, which is used to convey event notification messages. This protocol utilizes a layered architecture, which allows the use of any number of transport protocols for transmission of syslog messages. It also provides a message format that allows vendor-specific extensions to be provided in a structured way.

This document has been written with the original design goals for traditional syslog in mind. The need for a new layered specification has arisen because standardization efforts for reliable and secure syslog extensions suffer from the lack of a Standards-Track and transport-independent RFC. Without this document, each other standard needs to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. This layered architecture approach also provides a solid basis that allows code to be written once for each syslog feature rather than once for each transport. [STANDARDS-TRACK]')

[Ballot discuss]
Given the issues that the UDP transport has with congestion control, security and fragmentation, I'd like the document to recommend the TLS-based transport over the UDP-based one for general use, i.e., when the network is not specifically provisioned for this type of traffic.

draft-ietf-syslog-protocol-21, Section 5., paragraph 2:
>    If a syslog application is running on a machine
>    that has both statically and dynamically assigned addresses, then
>    that value SHOULD be from the statically assigned addresses.  As an
>    alternative, the syslog application MAY use the IP address of the
>    interface that is used to send the message.

  DISCUSS: So if a machine has only a dynamic address, it should instead
  use 127.0.0.1 in syslog messages, because that's statically assigned?
  That doesn't seem to make sense. Also, in practice, it will be
  difficult for the syslog sender to determine which addresses are
  statically or dynamically assigned (think MobileIP or even HIP).


draft-ietf-syslog-transport-udp-09, Section 65535, paragraph 0:
>    This transport mapping supports transmission of syslog messages up to
>    65535 octets in size.  This limit stems from the maximum supported
>    UDP payload of 65535 octets specified in the RFC 768 [1].

  DISCUSS: The RFC768 length field includes the UDP header, so the
  permitted payload size is 65535 minus the UDP header (and for IPv4,
  minus the IP header, because IPv4 has a 16-bit length field that also
  includes the header length.)

[Ballot comment]
* When UTF-8 is not used, this protocol does not interoperate absent
  manual configuration on both client and server to align the charset.
  The document should state this clearly.  I'm aware of the charset
  support history in Unix so I understand this is a necessary nod for
  backwards compatibility but the document should make it clear this

* The protocol would be simpler if the UTF-8 BOM was never used.  Use of
  the UTF-8 BOM in this protocol simply changes two cases (UTF-8 or
  unknown charset) into three cases (UTF-8 with BOM, UTF-8 without BOM,
  or unknown charset).  This makes the protocol more complex than
  necessary, reduces interoperability and potentially reduces security.
  A receiver could simply apply the UTF8-octets ABNF rule to the
  received data and if it complies assume the data is UTF-8 unless an
  explicit in-band or out-of-band label states otherwise.

* This text doesn't make sense:
  If a syslog application is processing a MSG starting with a BOM, then
  it MUST be interpreted as being encoded in UTF-8 for the reasons
  outlined in UNICODE TR36 [UNICODE-TR36], section 3.1.
Correct text would say:
  Even when a MSG starts with a UTF-8 BOM, if it contains UTF-8 that is
  not shortest form it MUST NOT be interpreted as being encoded in UTF-8
  for the reasons outlined in UNICODE TR36 [UNICODE-TR36], section 3.1.
Note that the sense of the text in the document is exactly backwards from the security requirement, and this mistake is probably the result of the additional complexity caused by unnecessary use of the BOM.  Note that UNICODE TR36 never mentions the BOM.

* The ABNF for UTF-8-STRING should simply reference the UTF8-octets
  production from RFC 3629 which already mandates shortest form.

* The ABNF would be shorter if it referenced the date-time production
  from RFC 3339 instead of embedding a copy of the ABNF.  For example:

  TIMESTAMP      = NILVALUE / date-time
                  ; date-time is as defined in [RFC3339] and with
                  ; additional restrictions discussed in section 6.2.3.

[Ballot discuss]
This is a talk about on the call then clear DISCUSS.

draft-ietf-syslog-protocol has a normative reference to draft-ietf-syslog-transport-tls.  Should we hold approval for the latter, or let the RFC editor hold publication until the latter is ready?

[Ballot comment]
-udp, Section 1, 1st paragraph: Please remove the word "formally" -- it sounds like you are claiming there's a formal definition of SYSLOG, whereas you only mean that the IETF has officially sanctioned this now as a Proposed Standard. Same issue in -protocol, Appendix A.1.

[Ballot discuss]
Would there be a way to have at least the option of having some security and some congestion control? What is our bar for standards today?

I plan to remove this discuss once we have talked about it - I think it is likely covered by other people discusses.

[Ballot comment]
draft-ietf-syslog-protocol-21, Section 1., paragraph 5:
>    This document obsoletes RFC3164, which is only an Informational
>    document describing some implementations found in the field.  Some
>    vendors market their products as compliant to RFC3164, but RFC3164
>    does not define a standard.  Hopefully, declaring RFC3164 obsolete
>    will reduce associated bogus marketing claims.

  Suggest to cut the commentary, i.e., cut the last two sentences of
  this paragraph.


draft-ietf-syslog-protocol-21, Section 8.5., paragraph 2:
>    It may be desirable to use a transport with guaranteed delivery to
>    mitigate congestion.

  Reliable delivery and congestion control are orthogonal features. A
  reliable transport will not necessarily have congestion control, and
  vice versa.


draft-ietf-syslog-protocol-21, Section 8.5., paragraph 3:
>    It may also be desirable to include rate-limiting features in syslog
>    originators and relays.  This can reduce potential congestion
>    problems when message bursts happen.

  This is too weak a statement on congestion control. See DISCUSS above.


draft-ietf-syslog-protocol-21, Section 8.5., paragraph 4:
>    Reliable delivery may not always be desirable.  Reliable delivery
>    means that the syslog originator or relay must block when the relay
>    or collector is not able to accept any more messages.  In some
>    operating systems, namely Unix/Linux, the syslog originator or relay
>    runs inside a high-priority system process (syslogd).  If that
>    process blocks, the system at large comes to a stand-still.  The same
>    occurs if there is a deadlock situation between syslogd and e.g. the
>    DNS server.

  This paragraph is inaccurate. One, I'm not aware of any OS that
  doesn't offer non-blocking I/O. Two, even if "a high-priority system
  process (syslogd)" would block for I/O, the system does NOT come to a
  stand-still. It's a user space daemon, not kernel code.


draft-ietf-syslog-protocol-21, Section 8.9., paragraph 1:
>    As shown in Diagram 2, machines may be configured to relay syslog
>    messages to subsequent relays before reaching a collector.  In one
>    particular case, an administrator found that he had mistakenly
>    configured two relays to forward messages with certain SEVERITY
>    values to each other.  When either of these machines either received
>    or generated that type of message, it would forward it to the other
>    relay.  That relay would, in turn, forward it back.  This cycle did
>    cause degradation to the intervening network as well as to the
>    processing availability on the two devices.  Network administrators
>    must take care not to cause such a death spiral.

  A sequence number or - even better - a hop count in the message would
  allow breaking such loops.


draft-ietf-syslog-protocol-21, Section 8.10., paragraph 2:
>    Administrators and network planners must also critically review the
>    network paths between the originators, the relays, and the
>    collectors.  Generated syslog messages should not overwhelm any of
>    the network links.

  Given that syslog can generate unlimited amounts of traffic, no level
  of critical review will guarantee that syslog won't overload the path.


draft-ietf-syslog-protocol-21, Section 8.10., paragraph 3:
>    In order to reduce the impact of this issue, using transports with
>    guaranteed delivery is recommended.

  Again, reliability != congestion control.


draft-ietf-syslog-transport-udp-09, Section 3.6., paragraph 2:
>    It is RECOMMENDED that syslog senders use valid UDP checksums when
>    sending messages over IPv4 and IPv6.

  Agree with Tim's DISCUSS - this language weakens the MUST for IPv6.


draft-ietf-syslog-transport-udp-09, Section 4.3., paragraph 0:
>  4.3.  Congestion Control

  Fully agree with Magnus' DISCUSS.


draft-ietf-syslog-transport-udp-09, Section 4.4., paragraph 1:
>    The order of
>    syslog message arrival via this transport SHOULD NOT be used as an
>    authoritative guide in establishing an absolute or relative sequence
>    of events on the syslog sender hosts.

  Better make this a MUST NOT. Also, IP packets can become duplicated
  and delivered multiple times, which should also be discussed in this
  section.

[Ballot discuss]
draft-ietf-syslog-protocol-21, Section 5., paragraph 1:
>    The first transport is defined in [RFCXXXX] and is
>    consistent with the traditional UDP transport.  This transport is
>    mandatory to implement for compliance to the standard to support
>    interoperability as the UDP transport has historically been used for
>    the transmission of syslog messages.

  DISCUSS: Above, the document has argued that the Informational RFC3164
  wasn't really a standard. Now it argues that a UDP transport - which
  currently has very problematic features (see Magnus' DISCUSS) - is
  mandatory to implement, because UDP has historically been used to
  transport syslog messages. I have serious concerns with an IETF
  standards-track recommendation where the only mandatory-to-implement
  transport doesn't have any congestion control. I don't buy the
  argument made below that going with UDP provides a "non-disruptive
  transition path" for existing implementations, because they need to be
  modified anyway to implement the new message format. Switching to a
  different transport protocol should be a comparatively small change.
  There are several ways forward: One, add some congestion control to
  the UDP-based transport (I think Magnus' DISCUSS has some pointers.)
  Two, define a second mandatory-to-implement transport that has
  congestion control (ideally, I'd like to see that one being
  recommended and the UDP-based transport being recommended against.)


draft-ietf-syslog-protocol-21, Section 5., paragraph 2:
>    If a syslog application is running on a machine
>    that has both statically and dynamically assigned addresses, then
>    that value SHOULD be from the statically assigned addresses.  As an
>    alternative, the syslog application MAY use the IP address of the
>    interface that is used to send the message.

  DISCUSS: So if a machine has only a dynamic address, it should instead
  use 127.0.0.1 in syslog messages, because that's statically assigned?
  That doesn't seem to make sense. Also, in practice, it will be
  difficult for the syslog sender to determine which addresses are
  statically or dynamically assigned (think MobileIP or even HIP).


draft-ietf-syslog-transport-udp-09, Section 65535, paragraph 0:
>    This transport mapping supports transmission of syslog messages up to
>    65535 octets in size.  This limit stems from the maximum supported
>    UDP payload of 65535 octets specified in the RFC 768 [1].

  DISCUSS: The RFC768 length field includes the UDP header, so the
  permitted payload size is 65535 minus the UDP header (and for IPv4,
  minus the IP header, because IPv4 has a 16-bit length field that also
  includes the header length.)

[Ballot discuss]
draft-ietf-syslog-protocol-21, Section 5., paragraph 1:
>    This document does not specify any transport layer protocol.
>    Instead, it describes the format of a syslog message in a transport
>    layer independent way.  Syslog transports are defined in other
>    documents.  The first transport is defined in [RFCXXXX] and is
>    consistent with the traditional UDP transport.  This transport is
>    mandatory to implement for compliance to the standard to support
>    interoperability as the UDP transport has historically been used for
>    the transmission of syslog messages.

  DISCUSS: Above, the document has argued that the Informational RFC3164
  wasn't really a standard. Now it argues that a UDP transport - which
  currently has very problematic features (see Magnus' DISCUSS) - is
  mandatory to implement, because UDP has historically been used to
  transport syslog messages. I have serious concerns with an IETF
  standards-track recommendation where the only mandatory-to-implement
  transport doesn't have any congestion control. I don't buy the
  argument made below that going with UDP provides a "non-disruptive
  transition path" for existing implementations, because they need to be
  modified anyway to implement the new message format. Switching to a
  different transport protocol should be a comparatively small change.
  There are several ways forward: One, add some congestion control to
  the UDP-based transport (I think Magnus' DISCUSS has some pointers.)
  Two, define a second mandatory-to-implement transport that has
  congestion control (ideally, I'd like to see that one being
  recommended and the UDP-based transport being recommended against.)


draft-ietf-syslog-protocol-21, Section 5., paragraph 2:
>    If a syslog application is running on a machine
>    that has both statically and dynamically assigned addresses, then
>    that value SHOULD be from the statically assigned addresses.  As an
>    alternative, the syslog application MAY use the IP address of the
>    interface that is used to send the message.

  DISCUSS: So if a machine has only a dynamic address, it should instead
  use 127.0.0.1 in syslog messages, because that's statically assigned?
  That doesn't seem to make sense. Also, in practice, it will be
  difficult for the syslog sender to determine which addresses are
  statically or dynamically assigned (think MobileIP or even HIP).


draft-ietf-syslog-transport-udp-09, Section 65535, paragraph 0:
>    This transport mapping supports transmission of syslog messages up to
>    65535 octets in size.  This limit stems from the maximum supported
>    UDP payload of 65535 octets specified in the RFC 768 [1].

  DISCUSS: The RFC768 length field includes the UDP header, so the
  permitted payload size is 65535 minus the UDP header (and for IPv4,
  minus the IP header, because IPv4 has a 16-bit length field that also
  includes the header length.)

[Ballot comment]
In Section 6.2.3, wouldn't it be better to record the time as number of units from the beginning of an epoch. This would make timezones irrelevant to the sender.

[Ballot discuss]
UDP transport:

Section 3.6:

  It is RECOMMENDED that syslog senders use valid UDP checksums when
  sending messages over IPv4 and IPv6.

  It is RECOMMENDED that syslog receivers check the checksums whenever
  they are present (i.e. the UDP header checksum field value is not 0)
  and discard messages with incorrect checksums.  Note that this is
  typically accomplished by the UDP layer implementation, and some UDP
  implementations allow for checksum validation to be enabled or
  disabled.


Why isn't these MUST? For IPv6 it is an MUST and for IPv4 does there exist a single reason not to use the UDP checksum?

Section 4.3:

4.3.  Congestion Control

  The UDP does not provide for congestion control.  Any network host or
  router can discard UDP packets when it is overloaded.  One or
  multiple syslog senders can maliciously or inadvertently overload the
  receiver or the network infrastructure and cause loss of syslog
  messages.

  If the potentially unrestricted use of syslog data being transferred
  over UDP in a particular deployment can saturate the link, then the
  network path should be provisioned so the offered load (including
  syslog packets) does not exceed the path capacity.  Otherwise, some
  of the syslog packets could be lost, or cause the loss of other UDP
  packets.

The language in this section needs some corrections. First of all a SYSLOG sender over utilizing the network may cause congestion events. These affect any IP packet sharing the path with the SYSLOG traffic.

But what I think is needed here is some clear and normative requirement on how to avoid and limit congestion. First of all I would like to see a restriction on the applicability of this transport to within a controlled environment unless the rate is capped to a level that is TCP friendly or the full path is provisioned to handle the traffic. There should also be a discussion on how one rate limits SYSLOG traffic.

If any higher rates of packets are to be sent over best effort networks then a feedback mechanism is needed. That would probably need to include forward path UDP packetization layer with sequence number to enable loss detection. Complemented with feedback traffic to enable rate control of outgoing traffic. That could also resolve the PMTUD issue.

[Ballot discuss]
In syslog-transport-udp-09, Section 3.6  (UDP Checksums):

The second and third paragraphs could be read as relaxing the
requirements (specified in RFC 2460) for IPv6 nodes to generate
and verify UDP checksums.

It would be clearer if the text described the recommendations for IPv4
independently, and then noted the requirements inherited from
RFC 2460 with respect to IPv6.

[Ballot discuss]
Section 3.6.  UDP Checksums:

The second and third paragraphs could be read as relaxing the
requirements (specified in RFC 2460) for IPv6 nodes to generate
and verify UDP checksums.

It would be clearer if the text described the recommendations for IPv4
independently, and then noted the requirements inherited from
RFC 2460 with respect to IPv6.

[Ballot comment]
This will have to be fixed I'm sure:

  The character set used in MSG SHOULD be UNICODE, encoded using UTF-8
  as specified in [RFC3629].  If the syslog application can not encode
  the MSG in Unicode, it MAY use any other encoding.

Is the second sentence supposed to read "If the syslog application can not encode the MSG in UTF-8, it MAY use any other encoding." ?  if so, is that really intentional?  There would have to be a way of specifying the encoding otherwise the recipient cannot interoperably interpret the message. 

If other encodings are indeed allowed, the sections on looking for ASCII control characters will have to be re-examined.

[Note]: 'The WG chairs believe they may have backed out enough changes that
this no longer requires an second IETF last call.  In the hopes that I
will get a chance to review this weekend and issue a ballot I''m placining it on the agenda.
If I fail to issue a ballot by Monday I will remove.' added by Sam Hartman

IANA Additional Comment:

IETF consensus is only used for 9.2 (SD-IDs), not
for 9.1 (Version). I do not see any text that implies ietf
consensus for 9.1.

IANA Last Call Comments:

As described in the IANA Considerations section of this
document, IANA will complete two actions upon approval
of the document.

First, in the syslog parameters registry located at:

http://www.iana.org/assignments/syslog-parameters

IANA will create a new subregisty entitled "syslog version
values." The initial registration for this registry will be:

Version Format Reference
------- ---------------------------------------- -----------------------------
1 Defined in [RFC-ietf-syslog-protocol-19]
[RFC-ietf-syslog-protocol-19]

Future registrations in the "syslog version values"
registry require IETF Consensus.

Second, also in the syslog parameters registry located at:

http://www.iana.org/assignments/syslog-parameters

IANA will create a new subregisty entitled "syslog
structured data id values"

The initial registrations for this registry will be:

Structured Structured Required or
Data ID Data Parameter Optional
------------ ----------------------- -----------
timeQuality OPTIONAL
tzKnown OPTIONAL
isSynced OPTIONAL
syncAccuracy OPTIONAL

origin OPTIONAL
ip OPTIONAL
enterpriseId OPTIONAL
software OPTIONAL
swVersion OPTIONAL

meta OPTIONAL
sequenceId OPTIONAL
sysUpTime OPTIONAL
language OPTIONAL

The registration rules for this registry will be that
new Structured Data ID values and new Parameter Name
values must be registered via IETF Consensus. In addition,
once SD-IDs and SD-PARAMs are defined, the syntax and
semantics of these registrations must not be altered.
In the event that modifications of existing registry items
are required, a new SD-ID or SD-PARAM must be created,
leaving the older one unchanged. Finally, the IANA does
not register, and will not control SD-IDs or SD-PARAMs
\with an "@" sign (ABNF %d64) in them.

IANA understands that these are the only actions required
upon approval of this document.

PROTO Write-up

(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?
Chris Lonvick
Yes; I believe that the document is ready for publication.
===
(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?

Adequate review has occurred from WG members, and it has been reviewed
by others. The reviews of the WG Last Call for this document (-17
version) may be found here:

Bert Wijnen's review (not a member of the WG mailing list)
http://www1.ietf.org/mail-archive/web/syslog/current/msg01243.html

Richard Graveman's review
http://www1.ietf.org/mail-archive/web/syslog/current/msg01240.html

Sharon Chisolm's review
http://www1.ietf.org/mail-archive/web/syslog/current/msg01232.html

Tom Petch's review
http://www1.ietf.org/mail-archive/web/syslog/current/msg01167.html

David Harrington's review
http://www1.ietf.org/mail-archive/web/syslog/current/msg01144.html


The issues raised in these reviews have been discussed on the mailing
list and most of them were fixed in version -18. A very few minor issues
were also addressed from that which resulted in vresion -19. I am
satisfied about the level of review.
===
(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?

No.
===
(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.

None.
===
(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?

There is strong consensus to publish this document.
===
(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
http://www.ietf.org/ID-Checklist.html 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 was generated using xml2rfc, has passed automated checking
using idnits 1.118 with the two notes below, and has passed a manual check
of idnits by the shepherd. I have reviewed the document.

Section 12 is a Note to the RFC Editor to say that other documents are
dependent upon this one. This will be dropped by the RFC Editor.

Reference [10] is unused and will be removed by the RFC Editor or during
Auth48.
===
(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 references are split into normative and informational references. The
document is dependant upon draft-ietf-syslog-transport-udp-08.txt and
draft-ietf-syslog-transport-tls-06.txt which are being submitted along
with this document. This document REQUIRES the UDP transport for
compatability and interoperability and also REQUIRES the TLS transport for
security.

All other references are to other documents in good standing.
===
(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 suggested a
reasonable name for the new registry? See
[I-D.narten-iana-considerations-rfc2434bis]. 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 document IANA section is complete and the requested registries are
clearly marked.
===
(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 in the document has been verified through
http://www.apps.ietf.org/abnf.html
===
(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Writeup? 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.


This document describes the syslog protocol, which is used to convey
event notification messages. This protocol utilizes a layered
architecture, which allows the use of any number of transport
protocols for transmission of syslog messages. It also provides a
message format that allows vendor-specific extensions to be provided
in a structured way.

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?

Nothing worth noting.

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?

One implementation of the protocol has been produced.
No vendors have announced that they will utilize this protocol. Some
vendors have indicated interest in supporting this document.
The above named reviewers did an outstanding and thorough job.



Personnel
Who is the Document Shepherd for this document? Who is the
Responsible Area Director?

[Area] SECURITY
[WG] syslog
[I-D] draft-ietf-syslog-protocol-19.txt
[Qver] draft-ietf-proto-wgchair-doc-shepherding-08.txt
[Shep] Chris Lonvick
[AD] Sam Hartman
===

Thanks,
Chris

Hi.  A few weeks ago you submitted draft-ietf-syslog-protocol-14 for
publication as a proposed standard.  The first step in that process is
review by the responsible AD, me.


here are my comments.  The working group needs to respond to these
comments; responses can come in the form of answers to questions,
disagreement, proposed changes, etc.

1) Has the ABNF been validated?  Which parser was used?  I'm
  particularly concerned about the handling of escaping in sd-values.
  If the ABNF is used directly to generate a parser, will it
  correctly handle the escaped text?  Is the handling of the escaping
  issue in this spec consistent with handling in other specs?

2) You do not discuss Unicode security at all.  I suggest that people
    in the working group read Unicode TR 36 and also consider the
    implications of the Unicode security presentation given at the
    last SAAG presentation.  particularly consider comments from
    operators concerned about Unicode characters interacting with
    existing scripts.  Then write up a security considerations
    section.  You need to at least explain the security risks
    associated with your choice to support all Unicode characters.  It
    would be a good idea to discuss other alternatives that were
    considered and to explain why this choice was made.


3) Backward compatibility and versioning are not really discussed.
  You define semantics of the version field but these semantics
  require the sender to be configured with the version that the
  receiver will support.  Is this extensibility model acceptable to
  people who will deploy this protocol?  Also, it seems that this
  extensibility model means that making a change that requires a
  version number bump is very costly.  Structured data seems like the
  major extensibility mechanism that does not require a version
  number bump.  Is this mechanism sufficient to make sure version
  bumps will be infrequent?


4) The working group has adopted the very restrictive standards action
  IANA policy for  structured data.  Why is such a restrictive policy
  chosen?


5) I don't think x- as a prefix is such a good idea for vendor use SD.
  It seems like that some way of identifying the vendor would be
  better; possibly something based on OIDs, enterprise numbers, or
  domain names.  The problem with a flat namespace for vendors is
  what do you do about collisions.


6) I'm concerned about the use of x- param names in sd-ids that are
    not experimental.  As I read the spec, any x- param name can be
    used in any sd-id regardless of whether the specification for that
    sd-id permits the param-name.  However the specification of an
    sd-id must define the non-x-param names valid with that sd-id.  It
    seems like this will be used as a way to extend sd-ids after the
    fact rather than defining a new sd-id as required elsewhere in the
    text.  Is this really desirable?



7) What sort of review has this spec received from the vendor
  community that generates syslog messages and the operator community
  that consumes them?  Will this specification actually be useful to
  the Internet community?  Has the review been wide enough that we
  believe we are headed in the right direction?


thanks for your responses,

--Sam