Hi Glenn, > 3.3 I still have difficulty understanding why default parameters > are listed in the MIB module. What is the use case that > requires these objects in the MIB module? > > Who decides what the default values should be? Since they are > read-write objects, I assume the purpose is to allow an NMS to > set the default values they want the sender to use. What happens > if there are multiple NMSs talking to the same sender? Then who > decides? If each NMS gets to decide, than you need a table in > which each row is "owned" by a particular NMS. I still don't > see why this would be needed however. > > If the sender decides, and the objects exist only so the > receivers can check and see what the sender will use for > defaults, then why are the objects read-write? Once an NMS > checks the defaults, what are they supposed to do with this > information? > > I question whether this deserves to be in the MIB module at > all, but if it kept, then at least the MIB module should > include a description of why it is there and how it should > be used. > > Response. > OK. I understand that there is a problem when several NMSs > are talking to the system. I will make this read-only. > These default values are set by some means at start up. > In general the default values will be used ( IPv4, UDP, > port 512 etc.) by syslog entities. > In these cases it is not necessary to specify the (default) > values for each row (representing a syslog entity) in the > syslogEntityControlTable. The values will be specified when > they are different from the defaults. > > Does that help ? >
Only to a degree. I think this reinforces some of my concerns (and Tom's). Why does this need to be made accessible in the MIB module? If it is read-write, you have the problem of multiple NMSs. If it is read-only, then no NMS can modify it. So all it does is reflect what default values are used. But if the table represents different engines (not different applications using a common engine), then those engines should probably operate on different ports, So it becomes a per-engine (per-entity) issue, not a global default issue. So it doesn't make sense as a scalar value, if it must be applied on a per-row basis. If the idea is to recommend what defaults should be used (IPv4,UDP,512), those can be specified as DEFVALS in the per-row managed objects (TransportDomain and syslogService) that can override such DEFVALs. You say that if the entity uses the defaults, it is not necessary to specify the values for each row. But the objects are defined a part of the row, and they are listed as mandatory-to-implement objects in the syslogEntityControlGroup. Why would we want to require implementers to implement these objects and then tell them they do not need to use them? (and when we go down that path, then I have some problems with "If no value is specified,..."). Different engines may have different ideas of what to use for defaults for severity and facility as well, so would it not make sense to have these defaults also specified on a per-row basis? If the engine and application are combined into a single entity, then surely that application has some idea of its own facility? But if I have a login facility and a ntp facility, why would I want the ability to use SNMP to set a default facility equal to uucp? It does not make sense to me to define these global defaults in a MIB module that supports multiple entities; or maybe I do not understand the use case, because you have lumped all sender/receiver/relay together as entities, and this is really only useful in certain situations. Are these designed to allow a receiver/collector to calculate and store a PRI for messages received from non-standard senders? Are these designed to allow a relay to calculate the PRI for messages received from non-standard senders, and to convert the message into a standard message format? Or are these designed for a standard sender to calculate the PRI for applications that don't specify their facility and severity when asking the sender to send a message? What are these defaults for? These defaults might make sense if the MIB represented one sender/engine and the table represented different applications (facilities) that utilized the message-sending capaibilities of the engine. Even there I would think the applications(facility) would be expected to identify its own facility category to a standards-compliant sender. If it is not a standards-compliant sender, then it is not our business to figure out how the application should talk to the sender, because that is not an on-the-wire issue. How a standards-compliant sender should deal with a non-standards-compliant facility that doesn't provide the facility and severity (e.g. refusing the request or substituting default values) is an implementation detail, not a standard detail. Note that I don't think there really is a non-standards-compliant application here, because we don't standardize implementation interfaces between an application and its sender/engine, but it seems pretty certain that if a sender needs to calculate a PRI, then it will need a facility and severity, and any application working with a standards-compliant sender would be expected to provide that info, so an application that doesn't provide them might be called non-standards-compliant, but that would really be stretching. It would probbaly b emore accurate to call the application non-standards-supporting. I do not understand the purpose of these defaults; I do not understand who uses them for what, and without understanding what the use case is, I **CANNOT** understand the implications of their designs, and why an implemneter is required to support them, or how an implementer is expected to utilize them. How can we possibly declare these to be part of an industry-wide standard? David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
