An architecture is very useful for me as long as it captures the essence of the engineering being architected, and this I am becoming increasingly unclear about.
My use case is masses of dumb devices that just about support syslog (with a struggle) feeding a small number of powerful servers. Others on the list talk of servers as senders while the existence of relays is highly plausible. I now know of the Windows case of multiple applications each as its own sender but you now seem to be extending that to a host (to use the IP term) with multiple syslog processes each of which can be sender/relay/collector; and that seems an over-complication which noone is asking for. We already have an architecture - sender, relay, collector - which allows for a combined collector/relay and sender/relay (as defined in -protocol). I think we need a good reason to move away from that. Note in passing that -protocol uses the terms 'application' and 'system' Tom Petch ----- Original Message ----- From: "David Harrington" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, December 15, 2006 7:23 PM Subject: RE: [Syslog] Mib terminology and MIB design > 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 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
