Subject: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14

From: Sam Hartman <[email-masked]>
Date: Sun, 18 Sep 2005 21:58:38 -0400 (EDT)

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
[email-masked]
http://www.employees.org/mailman/listinfo/syslog-sec

---

From: "Rainer Gerhards" <[email-masked]>
Date: Fri, 30 Sep 2005 18:41:52 +0200

Hello all,

I have thought quite a while about Sam's very good message. There are
pros and cons in all approaches. Before going ahead, I would *really*
appreciate any feedback from the WG on what the WG members would prefer.
In short words:

- enterprise-id based unique vendor SD-IDs
- vendor SD-IDs as in ssh
- stick with x- but relax the IANA policy

I have brought the options down to 3 bulletpoints in hopes to get more
response. Of course, there are some subtle things to think about with
any of the three choices.

Feedback is highly appreciated.
Rainer

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]] 
> Sent: Thursday, September 29, 2005 8:31 PM
> To: Rainer Gerhards
> Cc: [email-masked]
> Subject: Re: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14
> 
> Hi.  Sorry about the delay.
> 
> Your proposed directions seem reasonable.  However based on your
> comments on operator input I'm going to request explicit review from
> the ops directorate.
> 
> I'd like to give some proposed constraints on the solutions for the
> sd-ids and parameters.
> 
> 1) It seems like it should be relatively easy to add vendor
>    extensions.  Mechanisms for doing this include a liberal IANA
>    policy, vendor prefixes or vendor suffixes (like ssh).
> 
> 2) It may be desirable to have a way to extend sd-ids with
>    vendor-specific parameters.  However if such a mechanism exists,
>    there also needs to be a way to extend sd-ids with standards track
>    parameters.  I.E. it seems silly for it to be more inconvenient for
>    the IETF to extend something than a vendor.  Possible ways of
>    handling this are to allow standards track specifications to update
>    the list of sd-params for sd-id, creating a special notation for
>    after-the-fact extensions (a special prefix, @ietf.org suffix,
>    etc), or removing the mechanism for vendor extensions to sd-params
>    completely.
> 
> 
> 3) Namespace uniqueness should be considered.  How important this is
>     depends on how difficult it is to get a name registered.  For
>     example with a liberal IANA policy like first-come-first-serve or
>     specification required, x- may be a fine prefix for sd-ids.  A
>     vendor concerned by namespace conflicts can just register an
>     extension.  However if the iANA policy is going to be more
>     restrictive, then mechanisms such as those discussed on the list
>     become more important.  It is likely that with a liberal IANA
>     policy mechanisms for vendor-specific sd-parameters may still be
>     important.
> 
> Your original proposal as well as the ssh-style proposal do meet these
> constraints.  However there may be options that better meet your
> desires to make messages small.  For this reason, I've tried to
> explicitly enumerate what I consider the constraints to be.
> 
> --Sam
> 
>

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Tue, 4 Oct 2005 11:10:12 -0800

In general, the "@example.company.com" name space is a nice idea.
However, I am concerned about the length that this introduces.  I would
much prefer to have a more compact encoding, resembling what parameters
would look like in SDP more than what they would look like XML (in terms
of compactness).  This is one reason why I actually like the proposal to
use the company identifier (typically 3 digits) as prefix (followed by
some delimiter) as was suggested to denote a private name space.

Just my 2 cents.
--- Alex

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Chris
Lonvick (clonvick)
Sent: Monday, October 03, 2005 6:25 PM
To: David B Harrington
Cc: [email-masked]
Subject: RE: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14

Hi David,

On Fri, 30 Sep 2005, David B Harrington wrote:

> Hi,
>
> Because I believe we should be working to integrate our network 
> management standards, at least to the point they can secure and 
> correlate data easily across NM interfaces, I would like to see the 
> approach adopted by syslog to be similar to the approaches used by 
> other IETF protocols, especially network management protocols.

I'd like that as well.

>
> SNMP uses the vendor ID approach, managed by IANA.
> Netconf has no data model, so we don't know what they will use for 
> vendor extensions.
> I'm not sure what ipfix is using.
>
> Who will manage the @cisco.com registrations? IANA or another external

> agency? Will the assignments be as stable as IANA assignments?

The "[email-masked]" namespace for SSH is for private use and will not
be registered with anyone.  It's been working well enough for the SSH
community with the warning of, "It is up to each domain how it manages
its local namespace."  I will say that this practice in SSH is not as
widespread as SNMP but it has been done and it seems to be working.

It would be good to have discussion of this on the mailing list and we
can hopefully finalize what we want in Vancouver.  Your input would be
appreciated.

Thanks,
Chris