RE: Re: Comments on Mail Monitoring MIB version 2 (8-1-93)

[develop![e-mail]]

Ned,

Thanks for your quick and clear responses.  I do have three followups I'd
like to pursue:

>>   5) I like the mtaGroupTable, but shouldn't the Network Services Monitoring
>>      related info be in an applGroupTable?  Database and File System servers,
>>      e.g., could usefully group association information by host.
>
>I'm not quite sure what you are driving at here. Are you asking for the MIB
>to maintain a separate table of the connections associated with each group?
>
Specifically, I'm suggesting that the Network Services Monitoring MIB should
contain an applGroupTable and the related fields (*Association *Activity)
should be moved from the Mail Monitoring MIB mtaGroupTable to the Network
Services Monitoring MIB applGroupTable.  I'm assuming 1) that there are
applications which fit the Network Services Monitoring MIB mold but not
the Mail Monitoring MIB mold and 2) some of those applications can benefit
from the grouping capabilities.

>>   6) Is anyone else interested in information about the precedence/priority
>>      of messages?  We are.
>
>I thought about this as well. There are four options as far as I can tell: (1)
>Store the highest and lowest message priorities for each group. (2) Count how
>many messages are at each priority in each group, using separate variables for
>each priority. (3) Use different groups for different priorities (this is a
>special case of (1), really). (4) Monitor things on a per-message basis, with
>all that entails.
>
>I didn't see the high/low stuff in (1) as particularly useful unless you go all
>the way to (3). But we cannot mandate (3), since many MTAs  don't support
>priority-based processing. But even if we mandated use of separate groups for
>different priorities you really cannot make assumptions about how this affects
>group processing order. There are just too many implementations out there that
>have totally ideosyncratic behavior...  And priority values are not all that
>universal, so I don't see (2) as being viable.
>
>Per-message information, on the other hand, is a real nightmare. I have quite
>intentionally avoided getting into this since I think it would make the MIB
>both unimplementable and unmanageable. In short, this is a slippery slope I
>refuse to slide down!
>

I sympathize with your concerns about the slippery slope.  However, I think
it is useful to do (1) alone.  Simply put, it tells operations how high their
blood pressure should rise when they detect a problem.  Congestion with routine
traffic and congestion when mission critical messages are delayed can elicit
quite different responses.  More formally, I believe the information in (1)
can directly affect the alarm level when problems are noted.  Read on, however.

>I therefore decided to punt on priorities. But not having specific priority
>information doesn't mean you cannot group things by priorities -- a specific
>implementation might elect to use different appropriately labelled groups for
>different priorities.
>
I like this solution.  Grouping per priority per host would meet our needs
very nicely without changing the MIB.  The only drawback I see is that we
would have to do some customization on the management station.   No COTS
management station software would be able to interpret our grouping in a way
that sets off the correct alarms.  Unless others want to take up the cause,
I'm content to leave this issue to your judgement.

>>      different programs where presentations can be associated with more than
>>      one delivery and deliveries can be associated with more than one
>>      presentation.  Only the deliveries map well back to the applTable in the
>>      Network Services Monitoring MIB.
>
>Maybe I'm missing something, but I don't see why this is so. The text is quite
>explicit that groups can be used for different purposes that don't necessarily
>involve all of the group variables. For example, there will be implementations
>that use one set of groups for incoming mail processing, another set for
>storage, and a third completely separate set for outgoing processing.
>
>I originally thought of having separate tables for incoming, storage, and
>outgoing processing. But when you try to map this out you end up with all sorts
>of wierd overlaps between the tables. I eventually decided to have just one
>table with the union of all the variables in it.
>
>>      It's possible to map information from
>>      presentations to the corresponding delivery but it would be nice to
>>      represent information about network-related applications that don't
>>      directly have inbound and outbound associations.  Is this kosher?
>
>Absolutely. There is language in the MIB that explicitly says so.

I'll try to clarify my question.  It is clear from the MIB that entries in
the mtaGroupTable don't have to use all the counters and that unused counters
should equate to zero.  However, the applIndex is part of the key to the
mtaGroupTable.  Null key fields make me nervous so I was asking 1) is it
the intent of the MM MIB that entries in the mtaGroupTable are permitted to
have a NULL applIndex? and 2) if they are not supposed to have a NULL applIndex
is it the intent of the NSM MIB that entries in the applTable are permitted
that never have any inbound or outbound associations?

By the way, even if the mtaGroupTable permits a NULL applIndex I would prefer
to have an entry in the applTable because I want to know the applOperStatus
for these entities.  So your answer to (2) is more important to me.
>
>Thanks again for the feedback.
>
My pleasure.  Thanks for the good (and hard) work you've put in to this.

Marty

Martin Robb
AT&T Santa Barbara Lab
[e-mail]