I think this again is a good wake-up call. After all, here in this group, we are talking about on-the wire protocols and specifications. In the light of this, a "syslog-storage" RFC is something that inherently is out of scope for IETF, as there is no communication involved.
Anyhow, I think the message format description is flexible enough to even accomodate such secondary use cases. But they MUST not influence tradeoff decisions in designing the on-the-wire protocol. I think the discussion was very useful. And every vendor is still free to use the same format for other purposes. Its just not a priority for this group here. Rainer > -----Original Message----- > From: Harrington, David [mailto:[EMAIL PROTECTED] > Sent: Friday, February 06, 2004 9:26 PM > To: Rainer Gerhards; Anton Okmianski; [EMAIL PROTECTED] > Subject: RE: -protocol: transport mappings > > Hi, > > Comments inline. > > *snip* > > > > 2. I think requiring UDP implementation reduces the > areas in which > > > syslog message format RFC could be utilized. I can see > > many different > > > areas. For example, if RFC came without UDP baggage, we, > > > within Cisco, > > > could potentially standardize on this format for products > > which write > > > directly to log file (no syslog servers) should be > > compatible with the > > > format. This would be a great thing for us to be able to have a > > > consistent format regardless of whether or not syslog > > > transport is used > > > because it is inevitable that some products will use syslog > > and other > > > will write straight to file. > > Any vendor can choose to develop supplementary uses for the syslog > message format without being forced to implement UDP. If they > choose not > to implement the UDP transport, then the only thing this affects is > > 1) whether the vendor can honestly claim in their marketing that their > implementaion is fully compliant to the syslog standard, > > 2) and whether they can honestly market their proprietary logging > products as being fully compliant to the syslog standard. > > Syslog is not being written with an interface to on-the-box storage or > with interfaces to other logging mechanisms. It is not being developed > to best meet the needs of marketing. It is being written as > an IETF (the > I stands for Internet) protocol to standardize the on-the-wire format > for interoperability over IP between implementations from multiple > implementors. > > There is no reason to not specify UDP (or whichever IP protocol) as a > standard transport just to accommodate a vendor's "potential" > usage that > is totally out of scope for this WG, and is out of scope for > the IETF in > general. > > My $.02 > dbh > > > > > > > > Another use case I have is writing log messages into Windows > > > Event Log. > > > I would really like if that format be the same as on > other platforms > > > which use syslog. It would have been easier for us to > > establish this > > > requirement for products within Cisco if we could just > > refer to syslog > > > message format RFC and it did not come with a baggage of having to > > > implement a syslog UDP transport, which may not be applicable. > > > > > > So, I am open on whether or not UDP binding is included in > > > -protocol or > > > outside. But I would really prefer if it was not required. > > > > I agree on your general comments. In fact, that was one of the > > motivations of splitting -protocol. I think, however, that > even if we > > specify a required transport mapping in -protocol itself, > > that does not > > necessarily prohibt this. > > > > I think you are talking about storage here. It seems natural that no > > transport is needed to store the message. I think the implementation > > requirement can be worded so that a minimal transport mapping > > needs only > > to be implemented if the program actually uses a transport. > > > > Besides that, I think you can always say that "the format > > must adhere to > > RFCxxxx, section 4." - that should leave out any ambiguity. > > > > I will comment on the other issue in a summary mail I am right now > > preparing. > > > > Rainer > > > > > > > > > > >
