I still think we should stick with x- It is widely used elsewhere and so is obvious. It conserves space in a confined area.
Yes, collisions may occur but I think this is engineering v (your favorite other philosophy:-). Keep it simple, as opposed to going for the perfect solution that caters for everything but is so complex that it tends towards unusability. I still see syslog as something humans use (although I have written parsers) and enterprise ids are not my idea of human friendly. If a manufacturer really wants, they can put x-19406-this is now mine and be less usable as a result. Tom Petch ----- Original Message ----- From: "Rainer Gerhards" <[EMAIL PROTECTED]> To: <syslog-sec@employees.org> Sent: Friday, September 30, 2005 6:41 PM Subject: RE: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 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 PROTECTED] > Sent: Thursday, September 29, 2005 8:31 PM > To: Rainer Gerhards > Cc: syslog-sec@employees.org > 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 > > _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec
