Subject: RE: PMP> FW: Print MIB 09

From: "McDonald, Ira" <[email-masked]>
Date: Tue, 6 Nov 2001 14:27:20 -0500

Hi Ron,                                        Tuesday (6 November 2001)

Below are my responses to Dave Harrington's comments preceded by 'ira:'.

Separately, we should review and disposition all the errors and warnings
in the extensive 'smilint' comments on Printer MIB v2 that I posted
yesterday - this will take a little while.

There's an Internet-Drafts blackout in two weeks, due to the IETF
plenary in December, so we should be realistic about making that
deadline or just proceeding as fast as we can with edits.

Cheers,
- Ira McDonald
  [email-masked]
  906-494-2434 (work until later this week)
  608-257-0466 (home/work in Madison, WI next week)

------------------------------------------------------------------------

The Working Group has review your comments and is sending the
following response.  Unfortunately, many of your comments are 
issues relating to the original Printer MIB (RFC 1759) and changes
cannot be made that affect interoperability.

Our responses below are preceded by "WG.."

<original message>...

David [[email-masked]]
Sent: Monday, October 29, 2001 3:32 PM
To: Bert Wijnen (E-mail); [email-masked]'
Subject: Print MIB 09
Hi, 
comments on printmib 09 
I didn't run this through a compiler to check syntax. 

0) The overuse of TCs makes it way more difficult to work with this mib
than it needs to be.  The single-use TCs should be eliminated.

WG.. The addition of the TCs was a decision by the Working Group
   to allow these values to be imported into other MIBs.  The
   Finisher MIB presently uses some of these TCs and most others
   are used in private MIBs.  

ira: (We could ask Harry Lewis if IBM could bear to have most of the
'private' TCs made back into simple objects? - it would in fact not hurt
Xerox - because we already had private equivalent TCs for all of them)

My copy of -07- is truncated at prtChannelInformation, so I've reviewed
everything beyond that point afresh.

1) line 2644 "with" should be "which" 

*** I cannot locate this !!! HELP???

ira: (I can't find it either - in the '.txt' or in the 'mstrip'
extracted '.mib' file - we need some more context or a quote to find
Dave's reference)

2) prtChannelInformation concerns me. It is a constructed octet string.
This type of constructed string is an invitation to vendors to use it
to pass proprietary information, which somewhat defeats the goal of
standardization.

WG.. We have actually defined very specific formats for this 
   object.  Pages 116 and 117 provide very explicit details 
   regarding the encoding rules for this object.  Also, the
   PrtChannelTypeTC (pages 36 to 45) provides specific rules
   for this object far each channel type.

ira: Agree - suggest changing your second line above to:

   object.  Pages 116 and 117 define machine-parseable details

3) prtInterpreterTable has an empty description clause. The description
is contained in comments instead.  I believe it is considered
appropriate to put the description in the description clause.  Some
tools strip the comments away, and the mib becomes much less useful
if the descriptions are in the comments.  An example would be a
management application that imports description clauses and generates
help screens from them.  Machine parsing won't recognize that the
comments contain the description.

WG.. This will be corrected in the next draft.

4) prtInterpreterIndex - could this be tightened up so the values are
guaranteed to be persistent across reboots?

WG.. This description is identical to RFC 1759.  The exact reason
   for this wording has been lost in time but it basically allows
   a major upgrade to the functionality of the printer, either
   through a firmware or a hardware upgrade, which essentially
   creates a new printer.  In practice this seldom occurs.

ira: we should correct the weak wording in all six affected
     table index objects ...
        prtLocalizationIndex
        prtOutputIndex
        prtMarkerColorantIndex
        prtMediaPathIndex
        prtInterpreterIndex
        prtConsoleDisplayBufferIndex

     for example, current description of 'prtInterpreterIndex':
        "A unique value for each PDL or control language for which there
        exists an interpreter or emulator in the printer. The value is
        used to identify this interpreter. Although these values may
        change due to a major reconfiguration of the device (e.g. the
        addition of new interpreters to the printer), values are
        expected to remain stable across successive printer power
        cycles."

     should change the last lines to:
        addition of new interpreters to the printer), values SHOULD
        remain stable across successive printer power cycles."

5) prtInterpreterFeedAddressability and other objects have no defined
ranges.

WG.. Do ranges make sense here?

ira: All integer MIB objects must have ranges, per SMIv2 (RFC 2578).
     Regression loss - Gary Gocek discovered before with a MIB compiler.
     My apologies Ron - the following edits will take a while
     (I deskchecked the entire MIB - the following list is accurate).

     We revise ALL of the many deficient objects which currently say:
        SYNTAX     Integer32            -- with no range specified

     change
        SYNTAX     Integer32 (0..2147483647)
     for the following two objects:
        prtConsoleOnTime
        prtConsoleOffTime

     or
        SYNTAX     Integer32 (2..2147483647)
     for the following one object:
        prtMarkerColorantTonality

     or
        SYNTAX     Integer32 (-1..2147483647)
     for the following one object:
        prtAlertGroupIndex

     or
        SYNTAX     Integer32 (-3..2147483647)
     for the following four objects:
        prtInputCurrentLevel
        prtInputNextIndex
        prtOutputRemainingCapacity
        prtMarkerSuppliesLevel

     or
        SYNTAX     Integer32 (-1..65535)
     for the following two objects:
        prtInputDefaultIndex
        prtOutputDefaultIndex

     or
        SYNTAX     Integer32 (0..65535)
     for the following two objects:
        prtChannelCurrentJobCntlLangIndex
        prtChannelDefaultPageDescLangIndex

     or change all other affected objects (most) to:
        SYNTAX     Integer32 (-2..2147483647)

6) prtInterpreterDefaultCharSetIn and prtInterpreterDefaultCharSetOut -
define 2 as the DEFVAL?

WG.. The DEFVAL clause will be added and the text modified.  The
   CodedCharSet (TC) will also be modified to add "unknown(2)".

7) prtConsoleLightTable has an empty description. 

WG.. This will be corrected in the next draft.

8) prtConsoleOnTime/OffTime - this may be a standard practice in
printers.  It seems to me that it might be simpler to have one object
for on/off and another for blink rate, rather than requiring that both
of these objects be retrieved to determine that the light is off or on.
Couldn't this be done with an enumeration on/off/blinking plus a blink
rate?  Why are these read-write?  Do you anticipate an external
application adjusting the blink rate of a light, or turning the lights
on/off?  If an external application was to read the values, how would
they be used?  Are these values likely to change faster than network
latency allows the values to be retrieved?  Are blink rates likely to
vary for a given light?

WG.. This model is from RFC 1759 and must be maintained for
   compatabilty.  We agree that the model is clumsy.  The objects
   are read-write to allow a remote application to either enable
   or disable the lamps.  In almost all implementations these are
   read-only objects.  Some implementations may use blinking vs
   continuous on to indicate if the problem is critical or non-
   critical.  In this case, the remote app could look for this 
   state to determine the criticality of the condition.  Although
   this information more likely obtained from the alert table.  In
   all known implementations, the blinking rates do not vary.

9) Comments that "Implementation of every object in this group is
mandatory." may not be a good idea because the compliance clauses may
change at some point, and it might be ambiguous which took precedence.
Using the compliance clauses should eliminate the need to include such
comments.

WG.. All statements that define if the group is mandatory or 
   optional will be removed in the next draft.  The compliance
   clauses will provide the only definition.

10) prtAlertTable has an empty description 

WG.. This will be corrected in the next draft.

11) Various table entry definitions do not describe the entry, but only
that a row may exist for each device of type printer.
It would generally be better to include meaningful information in the
descriptions, such as row persistence or what a row represents.  This
can be helpful in the future as objects get added or deprecated to
ensure that the meaning of the row isn't changed inadvertently.

WG.. ?

ira: I suggest that I work with Ron and Ray Casterline to write
     better DESCRIPTION clauses for some/all of 'xxxEntry' objects.
     This will take a while.

12) I have concerns about the prtAlertTable. There are ways to help
the application avoid re-reading the entire table after a change.
RMON uses a timefilter; other tables use various mechanisms to record
the number of deletes done, or the last time the table was changed, and
so on.  This table could benefit from some of these techniques.

WG.. The objects prtGeneralConfigurationChanges,
   prtAlertCriticalEvents, and prtAlertAllEvents provide a global
   view of the table.  Also, hrDeviceStatus, hrPrinterStatus, and
   hrPrinterDetectedErrorState are used by a management app to
   determine if a problem exits that require examination of the
   table.

ira: Out of our hands - we really cannot start adding more objects to
     Printer MIB v2 five years after the first implementations.

13) The reliability of information from the prtAlerttable concerns me.
The resetting index could make it easy to overlook that a reset
occurred, and to ignore the current #1 in favor of the #1 I already
retreived before an undetected reset.  It might be more appropriate to
use a non-resetting (persistent across reboots) TestAndIncrement to
generate the indexes here, or to use an RMON timefilter in the index.

WG.. This is very implementation dependent.  On low cost printers
   it can be very expensive to add non-volatile memory to support
   this requirement.  Most high end printers do have the necessary
   memory and do not reset the index during a reboot.  Note that
   the alert table architecture is from RFC 1759 and must be
   maintained to achieve interoperability.

ira: Out of our hands - we cannot start revising syntax or adding
     objects to the 'prtAlertTable' - it has been shipping in printers
     for six years.

14) prtAlertTrainingLevel - There is still the style problem of
over-using TCs.  It makes it very difficult to really understand the
syntax of an object when you have to go elsewhere to lookup a TC to
see what the syntax is.  Use of TCs is very appropriate when the same
behavior is repeated for multiple objects, and you want to define the
convention only once.  But when only one object in the mib is defined
using that convention, it is better to define the syntax in the object
itself.  Just to review the document, I kept two computers displaying
the document, one to keep track of where I was in the review, and
another to keep jumping around in the document looking up TCs.  This
was mentioned in the original reviews by both me and Bert.  It is bad
practice!!!!

WG.. We agree.  When the enums were moved to TCs this issue was
   considered.  Only those enums were moved that were to be used
   in the Finisher MIB or were requested for Private MIBs.

ira: (See point (0) above - how about collapsing all/most of the
     single-use TCs back into the objects themselves, unless they
     appear in the IMPORT section of Finisher MIB??)

15) prtAlertGroupIndex -
    "An index of the row within the principle table in the
    group identified by prtAlertGroup that represents the sub-unit
    of the printer that caused this alert."

- huh???  What's a principle table?  Again the overuse of TCs also
made this difficult because you couldn't see what the possible
enumerations were for the values that would have made it clearer.  When
the pointers get complex, it is imperative that the text be clear and
easy to read, not buried away in some distant TCs.

WG.. ?

ira: Agree - we should change the first lines of the DESCRIPTION to:
    "The low-order index of the row within the table identified
    by prtAlertGroup that represents the sub-unit of the
    printer that caused this alert, or (-1) if not applicable.

16) prtAlertTime - Given the issues I raised with the alert table,
making the AlertTime optional seems silly.

WG.. This also is identical to RFC 1759 and must maintained for
   compatibility.

ira: Jurgen Schoenwaelder specifically requested that we correct
     this object to the original (RFC 1759) OPTIONAL, because
     to change it (as we had done earlier) was an illegal change
     to a published MODULE-COMPLIANCE macro with an assigned OID.

17) printerV1Alert - Bert, you worked on the coexistence rules.
Is this the way traps should be handled in mibs?

WG.. This section was provided to the group by Steve Waldbusser.

ira: (Agree - this is Steve Waldbusser's work in RFC 1759).

18) The references section is rather different than normal. I'd prefer
to see it following the normal formats, and I'd like to see the
"unused" entries removed.

WG.. This section will be edited and the "unused" entries removed.

ira: (Ron - see section 10 'References' of SNMPv3 Arch (RFC 2571),
     which Dave Harrington wrote, for what he wants as 'normal')

my $.02 
dbh 
David Harrington 
Director, Network Management Architecture 
Enterasys Networks, Inc. 
[email-masked]

---

From: "Bergman, Ron" <[email-masked]>
Date: Wed, 7 Nov 2001 14:11:32 -0800

Ira,

I will be reviewing your comments this afternoon.  I also plan to look at
the smilint info.

	Ron

-----Original Message-----
From: McDonald, Ira [mailto:[email-masked]]
Sent: Tuesday, November 06, 2001 11:27 AM
To: 'Bergman, Ron'; McDonald, Ira; Casterline, Ray; [email-masked]'
Cc: [email-masked]'
Subject: RE: PMP> FW: Print MIB 09

Cheers,
- Ira McDonald
  [email-masked]

<original message>...

     change

     or

     or

     or

     or

     or

WG.. ?

15) prtAlertGroupIndex -

WG.. ?

my $.02 
dbh 
David Harrington