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 [email protected] https://www1.ietf.org/mailman/listinfo/syslog
