Mmm I agree that management, SNMP or any kind, is only possible once we have agreed a model - at some level - of what we are managing. But I have no problems with the model in RFC3164 that has been carried across into the current I-D - except one, which is for me the core of the problem.
So what is wrong with RFC3164? I don't see it. It does describe things I have not seen in practice but have no problem with accepting that they exist and should appear in the I-Ds. I do find it telling that Rainer has a more limited definition of process than I do ie I am happy to use it in the singular as a generic term for the various bits of executing software in a something that emit a syslog message on the wire whereas Rainer says no, that is several processes, we cannot refer to it as a process singular. Ditto device; RFC3164 ey seq. use it to describe something that emits a syslog message on the wire and I will go along with that in the context of syslog. So when, David, you say you cannot map my terminology, of device (and syslogd) onto that of the I-Ds, I am mystified. I think I am using, and only using, the terminogy of the I-Ds. And if we cannot agree on this, then we cannot beign to specify how to manage it, whatever it may be. Tom Petch ----- Original Message ----- From: "David B Harrington" <[EMAIL PROTECTED]> To: "'Rainer Gerhards'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, January 12, 2007 2:06 AM Subject: RE: [Syslog] Doubts on definitions > 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 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
