David, > -----Original Message----- > From: David B Harrington [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 10, 2007 9:53 PM > To: [EMAIL PROTECTED] > Subject: [Syslog] Doubts on definitions > > Hi, > > As we have this discussion, I find that the terminology (and the > architecture it describes) in the protocol document is very ambiguous. > For example, > > > > > The following definitions are used in this document: > > > > o An application that can generate a syslog message is called > a > > > > "sender". > > So I have an application (or device) that sends a message via > inter-process > communication to syslogd which then takes the information and formats > it into a syslog message and sends the message into the network. So is > the application the 'sender" or is the syslogd process the sender? Is > the application the originator or is the syslogd process the > originator of the syslog message? > > We are dealing with Internet standards, so we should only care about > the process that sends the message onto the (IP) network, not about > the IPC communications - we should be concerned with the on-the-wire > formats and behaviors, not the internal formats and behaviors. > > What if the "application" is a limited-capability-device, such as an > IP-Phone, that sends (over a communications connection) syslog message > > content to a host/server that uses a syslogd to format and send a > syslog message across the Internet? Does the syslog device send a > "syslog message" to the server? If so, then is the device the sender > or the originator? And what role does the syslogd perform in this > configuration? Is the syslogd actually a > relay in this case? > > I don't think the -protocol- document does a good job of explaining > these relationships, especially describing how a syslogd fits into the > architecture.
Should it really describe all these relationships and how a specific (though important) sofware architecture works (syslogd)? I thought we are talking about on-the-wire standards. If we begin to describe how to implement the inner workings of the local syslog subsystem, we need to go far beyond what happens on the wire. The, I think, the next step needed would be to talk to the POSIX folks and ask them to cooperate on redefining the POSIX API. Next, we need to try to make this an universal standard. Is this really what we intend to do? I think we should stick with how different syslog systems can interoperate with each other and not try to force everyone to use the same SOFTWARE architecture... > Add to that the Windows approach where a syslogd (or a Windows syslog > service) is not provided by the OS, so each application has to provide > its own syslog stack, and the "architecture" gets really hard to model > in an unambiguous manner. I am probably not knowledgable enough - but what happens if different applications based on NET-SNMP run on a single machine? Are they all connecting back to a single engine and are they required to have the exact same software architecture and APIs? > > So I understand Glenn's difficulty developing a data > model using the terminology and architecture from the protocol > document. I think Glenn and Tom have very different views of what > architecture needs to be modeled, and the terminology in the > -protocol- document is really not very helpful. > > Remember that Miao also had a problem trying to describe the > funtionality in the TLS document using the > sender/receiver/relay/collector terminology. > > I personally dislike the "collector" terminology, because the > difference between a reciever and a collector is that a collector > stores the data after receiving the message from the network. We > should > be dealing with the sending and receiving of messages over IP, and it > should be immaterial whether the receiver stores the data (thereby > becoming a receiver-only, aka a collector) or passes it on (thereby > becoming a receiver plus sender, aka a relay). What happens once the > message is off the wire should not matter to the protocol. (It may > matter to -sign- but that is a different issue. It should not matter > to the protocol.) .. Nor should matter how it got on the wire.. > I think the terminology and architecture are woefully inadequate to > describe in a useful way the various configurations that can and do > occur in existing deployments, and how they relate to on-the-wire > message formats and security. > > I can understand why Glenn and Miao preferred to not use the > terminology from protocol-, and I have to wonder if this WG has met > the requirement for a Proposed Standard - "A Proposed Standard > specification is generally stable, has resolved known design choices, > is believed to be well-understood, has received significant community > review, and appears to enjoy enough community interest to be > considered valuable." > > It appears that even amongst the people of this WG, the terminology > and architecture are not well-understood. What can we expect when > people who did not help write the specification try to understand, > implement, and use it? > > I usually expect a specification being promoted to Proposed Standard > to be clear and unambiguous, and I don't see that level of document > maturity here. IMHO, the core problem is that we still do not differentiate between the software - most thinking syslogd - and the *protocol* syslog. It is NOT. If it were, the IETF would be the wrong place to standardize it. POSIX would be. I still find that the protocol definitions are clear. I agree it is not unambigous how to implement different parts, but that is not because of the on-the-wire architecture but because of existing API sets (and software architecture). I personally would not like to take up the challenge of standardizing the API set. I do not even find it desirable (from a software monoculture point of view). Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
