Bert,
I appreciate the quick response. (Wish I was able to reply faster!)
The WGs original goal was to advance the MIB to DS, but our current
understanding is that will not be possible due to the number of changes from
RFC 1759. We accept a recycle at PS.
See my answers below.
Ron
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen at lucent.com]
Sent: Monday, November 12, 2001 6:12 AM
To: Bergman, Ron; 'dbh at enterasys.com'; 'bwijnen at lucent.com'
Cc: Ira McDonald (E-mail); Harry Lewis (E-mail); Ray Casterline
(E-mail); 'pmp at pwg.org'; Patrik Fältström; Ned Freed; Juergen
Schoenwaelder
Subject: RE: Print MIB 09
Thanks Dave for the review.
Thanks Ron for the responses.
Ron... are you still shooting to advance to DS or is this
now targeted for a recycle at PS?
My comments inline
Bert
> -----Original Message-----
> From: Bergman, Ron [mailto:Ron.Bergman at Hitachi-hkis.com]
> Sent: Thursday, November 08, 2001 11:41 PM
> To: 'dbh at enterasys.com'; 'bwijnen at lucent.com'
> Cc: Ira McDonald (E-mail); Harry Lewis (E-mail); Ray Casterline
> (E-mail); 'pmp at pwg.org'
> Subject: RE: Print MIB 09
>>> David,
>> The Working Group has carefully reviewed your comments and is sending
> the following response. Unfortunately, some of your comments are
> issues relating to the original Printer MIB (RFC 1759) and changes
> cannot be made that affect interoperability.
>> In addition, we located Bill Fenner's smiLint index and found some
> additional items that we plan to correct in the next draft. smiLint
> found four issues:
> 1) Empty description clauses (which you already pointed out)
> 2) Use of INTEGER instead of Integer32 in PrtSubUnitStatusTC
> 3) Object, type, and enumeration strings longer than 32 characters
> 4) Notification object error (prtAlertIndex is not-accessible)
>> The first two we will correct. The third issue, since it is legal
> with all modern compilers and many printer vendors have been shipping
> the MIB for several years, will not be changed.
>The LE 32 character limit is a recommendation. The more formal limit
is 64 characters (as per RFC 2578, sect 3.1, 2nd para on page 13).
So as long as you are less than 64, I am OK with that.
Ron>> We are aware of this limit and all are well within 64.
(I believe the longest is 38 characters.)
> The fourth issue is more complicated but we have decided to change
> this object to read-only so that users do not have to edit the MIB
> to obtain an error-free compile. This issue was also noted by
> Juergen Schoenwaelder in his review dated June 7, 2001. At that
> time the WG felt that we should maintain compatibility with RFC 1759.
> The group now believes that it would be better to have an error
> free compile. Your comments on this subject would be appreciated.
>I think that the fix is not to make it read-only access. It is an
INDEX object, and those index objects should be not-accessible.
I would think that the suggested solution by Juergen has been
to remove the prtAlertIndex object from the OBJECTS clause of
the printerV2Alert notification. The index already comes
as part of the other objects in that notification. I.e. the
prtAlertSeverityLevel wil have an OID of which the index part
is exactly the prtAlertIndex value!!
So... if you make any change at all, it should be to remove
the prtAlertIndex from the notification. And that probably means
that you better deprecate/obsolete the current notification and
define a new one, and that means recycle at PS.
But... I understand the backward compatibility issue with 1759.
And I think Juergen suggested that we could allow the "compile
error/warning" since this was already in 1759.
Since Juergen seems fine with that, and since DBH also seems
fine with it, I can live with that, assuming this is the WG
concsensus too.
The doc still has to go through an IETF wide Last Call and
people may still object to this, and so we'd then have to
evaluate any such comments.
Ron>> The WG has discussed the alternatives and believes that, due
to the original bug in RFC 1759, a bug will remain. The
change to Read-Only was suggested since most compilers require
this change to prevent errors. The WG agreed that since we
must be wrong, it would be better to be wrong and not have to
hand edit the MIB. (I have read Juergen's subsequent emails.)
We would appreciate your comments on this justification.
> I hope you can review these comments quickly so that we only need
> to do one more revision of the document. This MIB has been in the
> queue for about five years (most of this time was due to the HR MIB
> update) and the WG is becoming very impatient. Many vendors have
> been shipping the MIB for several years and would like to be able
> to reference a "standards" document.
>> We do appreciate the time and effort that you have expended in
> the review of this document.
>> For the PrintMIB Working Group,
> Ron Bergman
> Hitachi Koki Imaging Solutions
>>> Our responses below are preceded by "WG.."
>> <original message>...
>> From: Harrington, David [dbh at enterasys.com]
> Sent: Monday, October 29, 2001 3:32 PM
> To: Bert Wijnen (E-mail); 'Ron.Bergman at Hitachi-hkis.com'
> Subject: Print MIB 09
>> Hi,
>> comments on printmib 09
>> I didn't run this through a compiler to check syntax.
>> 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.
>> My copy of -07- is truncated at prtChannelInformation, so
> I've reviewed
> everything beyond that point afresh.
>> 1) line 2644 "with" should be "which"
>> WG.. Several members of the WG have attempted to locate this
> occurrence.
> Could you provide more details regarding its position in
> the document?
>> 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 machine-parseable 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.
>> 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. However,
> we have agreed to change the text to: "... values SHOULD remain
> stable across successive printer power cycles."
> This change will be made for prtLocalizationIndex, prtOutputIndex,
> prtMarkerColorantIndex, prtMediaPathIndex, prtInterpreterIndex,
> and prtConsoleDisplayBufferIndex.
>> 5) prtInterpreterFeedAddressability and other objects have no defined
> ranges.
>> WG.. The Working Group agrees to add ranges to all objects with a
> SYNTAX of integer32.
>> 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.
>If things are clumsy, and if you feel they better get removed, then
once way to do that and allow for backward compatibility is to
deprecate or obsolete the objects. That way you still have them so
that old implementations can continue to interoperate with new ones.
But at the same time you tell new implementations that they no
longer need to implement them.
I am not saying you have to make this change, I am just explaining
that you can tell new (agent) implementations that they do not
need to implement this, while managers would continue to be able
to read depreacated objects.
Ron>> The clumsy-ness is only in conceptual understanding. It works
very well in implementations. The WG does not believe any
changes are necessary.
> 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.. We will provide better DESCRIPTION clauses for some/all
> of 'xxxEntry'
> objects.
>> 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. This structure was defined during the development of
> RFC 1759 by Steve Walsbusser and our other advisors. These objects
> and the Alert Table are presently incorporated in thousands of
> printers installed throughout the world. The WG cannot consider
> any changes in this area.
>> 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. Again, 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.
>Maybe you can add some text to explain this.. It may help when
we go through IETF Last Call, so that people can see why you
did these things
Ron>> Good idea!
> 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.. Agreed - we will 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. 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.
>Dave, maybe you are confused with the label ...V1Alert.
I think what they are doing is make sure that the one-but-last subID
of the notification OID is zero. That looks fine to me.
> 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. We will also add the required references from the
> MIB boiler plate.
>> my $.02
> dbh
>> David Harrington
> Director, Network Management Architecture
> Enterasys Networks, Inc.
>dbh at enterasys.com>