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

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,


Syslog-sec mailing list

Reply via email to