Subject: Re: PWG> Re: PMP> Alert table thoughts

From: JK Martin <[email-masked]>
Date: Wed, 2 Apr 1997 11:57:21 -0500 (EST)

I have read Matt's excellent message on his issues with the Alert Table
portion of the new Printer MIB draft, as well as the replies from Bill
Wagner, Harry Lewis and Angelo Caruso.  Seems as if there is relative
consensus to most of the issues, then, namely:

  - There should not be a "trailing edge" event called "coverClosed"
    that is implicitly mapped to a previously posted "coverOpen" alert.
    Instead, "coverClosed" should only be used in those rare cases in
    which a cover must be closed for the printer to operate normally;
    as such, coverClosed is a binary event that is removed from the
    Alert Table when the condition is no longer present (ie, the target
    cover has been reopened).  (For what it's worth, I vote for retaining
    the original RFC 1759 term "coverOpen" rather than "coverOpened",
    particularly since the PWG apparently did not make a conscious decision
    to change the name.)

  - The title of section 2.2.13.3 should be changed to "Alert Table" to
    more accurately reflect reality; that is, we don't want anyone to
    believe that there may be multiple Alert Tables in any given
    implementation of the Printer MIB.  (Note that to be a bit "prettier"
    we might want to change the title to "The Alert Table".)

  - Alerts should be categorized as being either "unary" or "binary".
    Any reference to a "simple" alert should be changed to "unary" alert.
    Consistency is important, particularly for a mechanism as complex as
    the Alert Table.

Matt, part of your message included:
 
> 2) In the internet-draft, the section that talks about the alert table
> has a paragraph that talks about unary alerts (included for reference). 
> The paragraph gives an example of a unary alert then goes on to talk
> about not knowing when to remove unary alerts from the table.  The
> clarification I am adding talks about multiple unary alerts of the same
> type on the same subunit replacing each other.  This makes the example
> not demonstrate waht it was intended to do.  What do you guys think?

Are you referring to section 2.2.13.3?  If so, then I can't find the
paragraph to which you refer.  On the other hand, if you're referring
to section 2.2.13.14 (Alert Table Management), then I'm still confused,
as that section does indeed talk about how to remove a unary alert,
including a suggested algorithm for doing so.  Is there something else
going on here that you would like clarified?

Also, you say:

  "This makes the example not demonstrate what it was intended to do."

To which example are you referring?  Are you instead referring to the
fact that the current draft states:

  "It is not obvious how long to keep [unary] change event entries
   in the Alert Table.  If they were never removed, the Alert Table
   would continue to grow indefinitely."

I believe these two sentences should be removed, as the paragraph
following these sentences appears to say what is necessary.

Matt, your message mentioned "The clarification I am adding...".  Did you
post your clarification text to the list already?  (If so, then I missed
it somehow.)

	...jay