Re: [Syslog] Mib terminology and MIB design

["tom.petch" <cfinss@dial.pipex.com>]

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" <ietfdbh@comcast.net>
To: "'Glenn M. Keeni'" <glenn@cysols.com>; <syslog@ietf.org>
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
> dharrington@huawei.com
> dbharrington@comcast.net
> ietfdbh@comcast.net
>
>
> > +---------------------------------------------------+
> > 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