Hi, [posting as a contributor]
Tom mentions that we should not use the term entity here, because it conflicts with the SNMP usage of that term. Since this is a MIB module designed for use in an SNMP environment, that is a really good point. It would hurt us to have conflicts between the terminology used to describe syslog things, and the terminology used to describe SNMP things in this mib module. Which raises an interesting question. Is the terminology used for syslog and the terminology used for SNMP compatible? Could we make them more compatible (without modifying any of the other syslog documents?) One approach to consider would be to use the RFC3411 "descriptive" architecture to describe the syslog architecture. The processes of preparing messages, dealing with message security, and sending messages via different transports are all services provided by the "engine": +-------------------------------------------------------------------+ | SNMP entity | | | | +-------------------------------------------------------------+ | | | SNMP engine (identified by snmpEngineID) | | | | | | | | +------------+ | | | | | Transport | | | | | | Subsystem | | | | | +------------+ | | | | | | | | +------------+ +------------+ +-----------+ +-----------+ | | | | | Dispatcher | | Message | | Security | | Access | | | | | | | | Processing | | Subsystem | | Control | | | | | | | | Subsystem | | | | Subsystem | | | | | +------------+ +------------+ +-----------+ +-----------+ | | | +-------------------------------------------------------------+ | | | | +-------------------------------------------------------------+ | | | Application(s) | | | | | | | | +-------------+ +--------------+ +--------------+ | | | | | Command | | Notification | | Proxy | | | | | | Generator | | Receiver | | Forwarder | | | | | +-------------+ +--------------+ +--------------+ | | | | | | | | +-------------+ +--------------+ +--------------+ | | | | | Command | | Notification | | Other | | | | | | Responder | | Originator | | | | | | | +-------------+ +--------------+ +--------------+ | | | +-------------------------------------------------------------+ | | | +-------------------------------------------------------------------+ One engine can support multiple "SNMP applications". SNMP applications are the things that define the roles, e.g. a notification originator (Cf: a syslog sender), a notification receiver (Cf: a syslog receiver), and a proxy forwarder (Cf: syslog relay). The RFC3411 architecture also supports command generator (that makes requests) and command responder (that processes requests and responds) that do not apply to syslog. The "SNMP applications" describe functionality that is combined with other functionality provided by software or devices; to put this in syslog terms, the facilities would utilize the "SNMP application" style functionality to generate, receive, or relay messages. Since this is a MIB document, we could provide an introductory section that maps from the syslog terminology to the RFC3411 terminology. Most users of the MIB will already have some knowledge of the SNMPv3 concepts. We could use the picture above. modified to describe the syslog architecure: +-------------------------------------------------------------------+ | Syslog entity | | | | +-------------------------------------------------------------+ | | | Syslog engine | | | | | | | | +------------+ | | | | | Transport | | | | | | Subsystem | | | | | +------------+ | | | | | | | | +------------+ +------------+ +-----------+ | | | | | Dispatcher | | Message | | Security | | | | | | | | Processing | | Subsystem | | | | | | | | Subsystem | | | | | | | +------------+ +------------+ +-----------+ | | | +-------------------------------------------------------------+ | | | | +-------------------------------------------------------------+ | | | Application(s) | | | | | | | | +-------------+ +--------------+ +--------------+ | | | | | Syslog | | Syslog | | Syslog | | | | | | Sender | | Receiver | | Relay | | | | | +-------------+ +--------------+ +--------------+ | | | | | | | +-------------------------------------------------------------+ | | | +-------------------------------------------------------------------+ I think with the addition of entity and engine to the terminology, this picture does a good job of describing the syslog architecture, and would make it clearer what the "things" are that are modeled in the syslog mib module. It would however, only be clearer to a degree. The table in the mib document would likely model one or more *engines* (daemons that serve multiple applications) in a *NIX environment, but would model multiple *entities* in a Windows environment. And sometimes, the table would include multiple engines and multiple entities. We need to model the real world. As Tom points out, one way to avoid this is to develop a scalar mib module. Such a mib module would only model one engine at a time. It might be immaterial whether that engine services one or more applications. It could however be important to know that, so we might need to model the engine as a scalar, and supplement that with a table of applications (facilities?) serviced by the one engine, and statistics related to that usage. If a system had more than one syslog engine operating, a single SNMP engine could service them all, using different SNMP contexts to model them. But this brings us back to where we are now, with the reality that some engines are contained in complete entities, and some engines are not. <soapbox> I have a bias toward an approach using RFC3411. Not only am I one of the authors of RFC3411, I am trying to migrate SNMP, syslog, ipfix, and netconf to all use a common terminology, where possible, to describe their concepts and functionalities, so it is easier to compare, and possibly reuse, some design decisions. It might also be possible to reuse some specifications. All of these protocols are looking to utilize secure transports (e.g., SSH and TLS). It would be a good thing if they all used similar approaches, so operators only had to configure one secure transport protocol (e.g. TLS) in one consistent manner to secure all four NM protocols. All four protocols need data modleing capabilities, to different degrees, and if the IETF NM community could agree to all use, say XML for encoding, and XSD for modeling, it would be easier to reuse and/or correlate the data. Netconf is looking at a notification design that can carry syslog info and snmp info; if the syslog SDEs can be translated into XML, and MIB data can be translated into XML, and ipfix data can be transalted into XML, (e.g., via XSLT transform tools), then it might be much easier for operators to correlate the data of the four NM protocols. </soapbox> I am only suggesting here that we use a diagram and entity/engine terminology similar to RFC3411 terminology to make the MIB module easier to understand. Doing so would place no constraints on syslog designers, implementers, or users (except of course, the designers of this mib module). David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] > -----Original Message----- > From: tom.petch [mailto:[EMAIL PROTECTED] > Sent: Friday, December 15, 2006 9:18 AM > To: David Harrington; 'Glenn M. Keeni'; [EMAIL PROTECTED] > Subject: Re: [Syslog] Mib terminology and MIB design > > This is also tied up with the scalar/table question. If we > had a scalar MIB > module, then much of my difficulty would vanish. > > If we keep the table, then it should not be of entities. As > you point out, > SNMPv3 has given the word 'entity' a specific meaning and I > think it wrong to > re-use the word to mean something different in a MIB module > (it would be ok if > this were SMTP or BGP); I find the use of 'managed entity' in > DESCRIPTION > clauses especially confusing. I like 'daemon' (not seeing > that as being in any > way limited to a particular role) or 'device', which is > already in use in other > syslog documents. > > Tom Petch > > > ----- Original Message ----- > From: "David Harrington" <[EMAIL PROTECTED]> > To: "'Glenn M. Keeni'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Thursday, December 14, 2006 10:41 PM > Subject: [Syslog] Mib terminology and MIB design > > > > Hi, > > > > [speaking as coc-ahir] > > We need WG input on this. > > Please look at mib-11 and decide whether "entity" is appropriate. > > Glenn has changed the terminology in many places to be more > consistent > > than previous revisions. > > > > In the TLS document, Miao and Yuzhi tried to use a generic term for > > any role and WG consensus was to change the document to use the > > sender/receiever/relay/collector terminology. Does the same > thing need > > to be done here? > > [co-chair end] > > > > [speaking as contributor (and MIB Doctor)] > > I have mixed feelings on this issue. > > > > I personally think not having a generic term makes it > harder to write > > documents and design mib modules that can be applied to any of the > > roles. In SNMPv3, we deliberately moved away from different > processing > > for different roles and toward a common "entity" that could act in > > different roles. > > > > When designing a MIB module to encompass multiple roles as > one entity, > > it is very important to review the design from the > perspective of each > > of the roles. For example, it may make sense to count > messagesSent if > > you are implementing a sender or relay, but not if you are > > implementing a reciever or collector. It will be a poor MIB module > > design if it makes a great deal of sense for implementers to only > > implement some of the objects in a table that is > > mandatory-to-implement for compliance. Having objects that only make > > sense for certain roles and not others in one common table will > > encourage non-compliant implementations. > > > > On the other hand, defining the MIB module to contain four tables to > > model the sender configuration, and the receiver configuration, and > > the relay configuration, and the collector configuration, > even though > > all four tables would contain identical information is simply > > ridiculous design. > > > > I do not like having one set of terminology in the protocol > > specifications, and a different set of terminology in the management > > interface, because it makes it harder for operators to interpret the > > data in the MIB module. > > > > The WG needs to review the MIB module design and determine > what makes > > protocol sense. > > [contributor end] > > > > David Harrington > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > > > > > > +---------------------------------------------------+ > > > 1.1 > > 3) the terminology is not consistent with the > > > other WG documents. > > > Not fixed. Still a problem. The WG consensus was > > > to use sender, > > > receiver, relay, and collector. Other document were > > > required to change > > > to match this terminology. The MIB document uses entity, > > > which is a term not found in the protocol draft. > > > > > > I find this change in terminology makes it difficult > > > to interpret some objects in the mib module. > > > > > > Response: > > > We have a single MIB module for all the roles of a syslog > > > "entity" - sender, receiver, relay and collector. > > > I do not see any problem with this generic nature of the > > > MIB, as yet. > > > > > > Let me know about the specific objects that are difficult > > > to interpret. We may try the following: > > > Use the generic "syslog entity" when the discussion > > > applies to all the roles > > > Use the role(s) explicitly "syslog sender", "syslog > > > receiver", etc. when the discussion does not apply to > > > all the roles. > > > Add a statement to that effect in the early part of > > > the text. > > > > > > Any other suggestions? > > > > > > 1.2 > > 4) "roles a syslog entity maybe in" would be better > > > as "roles of a > > > > > syslog entity" (although then entity should be > > > changed according to > > > > > #3. > > > See #3. > > > Response: > > > See #1. > > > 1.3 > > 5) I concur with Bert that the citations in section 2 seem > > > > > inappropriate. > > > I suggest rewriting the introduction to use the same > > > terminology as > > > the protocol draft. See #3. > > > Response: > > > See #1. > > > > > > 1.4 > > 6) I find the references to SA-Li, RA-Rj confusing > > > since these are > > > not > > > > > used in the diagram. > > > Fixed, but replaced by "entity" which is a problem. See #3. > > > Response: > > > See #1. > > > > > > > > _______________________________________________ > > 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
