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.
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? David Harrington [EMAIL PROTECTED] > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Rainer Gerhards > Sent: Friday, September 30, 2005 12:42 PM > To: [email protected] > 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: [email protected] > > 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 > [email protected] > http://www.employees.org/mailman/listinfo/syslog-sec > _______________________________________________ Syslog-sec mailing list [email protected] http://www.employees.org/mailman/listinfo/syslog-sec
