Hi Again,
On Thu, 22 Sep 2005, Rainer Gerhards wrote:
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.
We have seen the problem with collisions, but accepted it. Again, the
prime reasoning is the worst-case-size limitation. The longer the
prefix, the less space is left for actual message content. It obviously
is good to have a discussion on what is more desirable: short overhead
size or low avoidance of name space problems.
After re-reading and re-thinking based on your comment, a compromise
would probably be to use the vendor's enterprise numbers (same as in
section 7.2.2, preferably without sub-identifiers) as the prefix for
vendor extensions. So a vendor extension would not be "x-extension" but
"19406-extension" (19406 is the enterprise id of the company I work for,
I use it as a sample to avoid hitting someone else's id). The extra
overhead in size should be acceptable if we look at what we gain on
safety in namespace collisions. Optionally (if the vendor sees need),
sub-identifiers could be used, leading to things like
"19406.1.32.4.7.89-extension" - obviously this needs more space and thus
should be avoided if it does not create any issues for the vendor (but I
guess we would see such things quite often).
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?
This is a very good question. The consensus ([too?] quickly reached) was
that vendor-extension (and experimental ones) to standard SD-IDs are
useful. The reasoning behind this is that if a vendor intends to provide
information that is logically closely related to a standard SD-ID, it
would be useful to include it with that SD-ID. This would keep the
message both shorter and better readble than when a completely new
(vendor-specific) SD-ID is used for that purpose. So this mechanism
should be used to include not-yet-supported, closely related information
into a standard SD-ID. Of course, what is "closely related" depends. So
this mechanism could easily be abused.
If I look at your comment 5) above, I also begin to have some other
concern. For the same reasoning, we would have to replace the "x-" with
something vendor specific down here, too. Even if we go for the compact
enterprise-id, adding it to potentially multiple SD-PARAMs causes a lot
of overhead.
Given this whole picture, it probably makes sense to disallow x- params.
An alternative might be that the vendor uses a SD-ID with the same name
as the standard one but with its prefix (e.g. "19406-origin"), then add
the new SD-PARAMs without any further prefix.
Another alternative would be to use the precedent set (and already
accepted by the IESG) in the SSH IDs. This would mean that the
IANA-registered SD-ID params could not use the "@" character. See section
6 of draft-ietf-secsh-architecture-22.txt and Section 4.6.1 of
draft-ietf-secsh-assignednumbers-12.txt.
This would allow something like
[origin [EMAIL PROTECTED]"1"]
or even
[EMAIL PROTECTED] foo="bar"]
Thanks,
Chris
_______________________________________________
Syslog-sec mailing list
[email protected]
http://www.employees.org/mailman/listinfo/syslog-sec
