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
_______________________________________________
Syslog-sec mailing list
Syslog-sec@www.employees.org
http://www.employees.org/mailman/listinfo/syslog-sec
