Hi Rainer, Let me explain the problem I am facing as co-chair. I don't know syslog very well. I have lots of experience chairing, but little experience with syslog.
I have a lot of experience in writing MIBs, and rule #1 is "you need to know what you are trying to model before you can model it in a MIB." But the WG does not seem to have consensus on what it is that we need to model. Glenn designed a MIB module that appears more complex than is needed. He models multiple entities in a system. I don't know what "entity" he is referring to. Maybe he is talking about multiple applications on a Windows box, each with its own syslog stack. Maybe he is talking about multiple software applications that all go through the same daemon. Maybe he is trying to cover both using the same model. I am trying to understand what Glenn has modeled and why, but I don't. Only one person has provided a review of the mib document from the syslog standpoint - Tom. But Tom talks about syslogd and devices, and he doesn't seem to have knowledge of non-UNIX configurations. And I cannot understand how Tom's model maps to the terminology and architecture of the protocol doc or to Glenn's mib. When we have only two people, and they have totally different understandings of what we need to model, we cannot very well achieve consensus. As co-chairs, Chris and I need to try to understand what each is saying, and where the disconnect exists. Unfortunately, the terminology and architectural concepts are so muddled, I cannot tell what each person is saying clearly. We have not provided unambiguous terminology that allows us to clarify the discussion. When Tom says application and Glenn says application, I cannot tell if they are referring to the same thing or totally different concepts. But "application" is at the core of all our definitions. Maybe we don't need all the complexity of Glenn's MIB. Maybe a MIB like the one Tom asked for would be fully adequate for fault, performance, and configuration monitoring. I just don't know. If we define a simple MIB that only works for some use cases but not others, then we lose interoperability if we have to define another MIB for different use cases. ********* Additional syslog voices would be tremendously helpful in determining this. ********* Have YOU reviewed the mib document? Is the complex design that Glenn used appropriate? Is the simple design that Tom would prefer enough? Would the counters in Glenn's MIB be useful to understand the operation of the two syslog implementations that you work on? Would the configuration information in Glenn's MIB be useful to understand the operation of the two syslog implementations that you work on? How about the other implementers? How appropriate is Glenn's mib to model your product? How appropriate is Tom's? What needs to be modeled to make your product manageable in a vendor-neutral way? dbh > -----Original Message----- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 10, 2007 4:17 PM > To: David B Harrington; [EMAIL PROTECTED] > Subject: RE: [Syslog] Doubts on definitions > > 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
