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
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?
> -----Original Message-----
> From: syslog-sec-bounces@www.... > [mailto:syslog-sec-bounces@www....] On Behalf Of
> Rainer Gerhards
> Sent: Friday, September 30, 2005 12:42 PM
> To: syslog-sec@empl... > Subject: RE: [Syslog-sec] AD Review for
> Hello all,
> I have thought quite a while about Sam's very good message. There
> pros and cons in all approaches. Before going ahead, I would
> 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
> response. Of course, there are some subtle things to think about
> any of the three choices.
> Feedback is highly appreciated.
> > -----Original Message-----
> > From: Sam Hartman [mailto:hartmans-ietf@mit....]
> > Sent: Thursday, September 29, 2005 8:31 PM
> > To: Rainer Gerhards
> > Cc: syslog-sec@empl... > > Subject: Re: [Syslog-sec] AD Review for
> > 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
> > the ops directorate.
> > I'd like to give some proposed constraints on the solutions for
> > 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
> > 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
> > after-the-fact extensions (a special prefix, @ietf.org suffix,
> > etc), or removing the mechanism for vendor extensions to
> > completely.
> > 3) Namespace uniqueness should be considered. How important this
> > 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
> > become more important. It is likely that with a liberal IANA
> > policy mechanisms for vendor-specific sd-parameters may still
> > 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.... > http://www.employees.org/mailman/listinfo/syslog-sec >