Subject: PMP> FW: Review of Printer MIB Draft

From: [email-masked] (Filion,Joe)
Date: Fri, 21 Mar 1997 13:17:45 PST

Here are my comments on the Printer MIB Draft released on the 18th.  

JLF

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

Pg. 17. First paragraph refers to the Host MIB.  At the bottom of every 
 page of the Host Resources MIB it says Host Resources MIB, not Host 
 MIB.  Also, on pg. 20 (middle of the page) it is called Host Resources 
 MIB(RFC 1514).  It would be nice to be consistent throughout.  This 
 appears throughout the document.

Pg. 18. Last paragraph refers to the "alert alert" but I have seen no 
 other mention of this anyplace else in the document.  Shouldn't this 
 be alertRemovalOfBinaryChangeEntry?

Pg. 21. I am a bit confused by the second paragraph which says "it 
 would be appropriate to add a standby enumeration to hrDeviceStatus."  
 It is sounding like a suggestion, but doing this would violate 
 conformance to Host Resources MIB.  I would be afraid that someone 
 implementing an agent for the first time may not understand the 
 implications and would do what is being suggested.

Pg. 26. Fourth and fifth paragraphs - all of a sudden the term simple 
 alert is used instead of unary alert.  It would be nice to stay consistent.

Pg. 28. Number 2 - "... i.e., not a "PostIt".  ..." I believe PostIt is 
 a registered trademark.  Elsewhere in the document you use (tm).  I 
 don't know what is appropriate here but this doesn't look right.

Pg. 36. The comment for PrtGeneralResetTC says that it is a type-3 
 enumeration.  This does not seem right to me.

Pg. 57. The value for prtAlertLocation should say that -2 means unknown.

Pg. 64. Should the phone:, fax: and email: tags be used in non 8-bit 
 environments?  How about in non-English environments?

Pg. 66. As much as I dislike the tags used for 
 prtGeneralCurrentOperator and prtGeneralServicePerson, it seems the 
 MIB should be consistent and do the same thing for 
 prtGeneralAdminName.  Also, I don't think you will be able to put a 
 string into a PresentOnOff value.

Pg. 66. prtGeneralSerialNumer can not be PresentOnOff.  Also, the Host 
 Resources MIB description for hrDeviceDescr says that it optionally 
 includes its serial number.  This object may be a bit redundant 
 (although I generally don't like overloading objects as suggested by 
 the hrDeviceDescr description).

Pg. 69. This is more of a typo than anything else, but I think it is 
 the result of using Word to create the document.  Throughout the 
 doucment are bad single quotes as in the description for 
 prtLocalizationEntry.  In my printout the first single quote looks 
 like `.  This happens throughout the document (three times on pg. 90). 
  A search and replace of this character should be done.

Pg. 71. prtStorageRefSeqNumber SYNTAX is 0..65535.  Because this is 
 used as an index for a table, it allows a zero index which is widely 
 frowned upon in SNMP.

Pg. 71. prtStorageRefIndex is defined as Integer32(0..65536).  It says 
 it holds the hrDeviceIndex which is defined as INTEGER(1..2147483647). 
  These should match.  Also, by allowing zero you are allowing zero as 
 an index.

Pg. 72. prtDeviceRefSeqNumber SYNTAX is 0..65535.  Because this is used 
 as an index for a table, it allows a zero index which is widely 
 frowned upon in SNMP.

Pg. 72. prtDeviceRefIndex is defined as Integer32(0..65536).  It says 
 it holds the hrDeviceIndex which is defined as INTEGER(1..2147483647). 
  These should match.  Also, by allowing zero you are allowing zero as 
 an index.

Pg. 98. The description for prtMarkerSuppliesIndex is not a complete 
 sentence.  It was in rfc1759.

Typos/formatting:

Pg. 6. "choosing printing properties , routing..." should not have 
 space before comma after properties.

Pg. 7-8. Diagrams look real bad.

Pg. 9. Middle of page - "...various sub- units are...", should not have 
 space after -.

Pg. 9. Last paragraph - "... until the condition that caused critical 
 alert...." should be "until the condition that caused the critical alert..."

Pg. 10. Just before figure - "sub- units" should not have space.

Pg. 10. Figure should all be on one page.  Need to force a page break.

Pg. 13. No apparent reason for page break.

Pg. 19. Middle of page - "printer.These named..." needs spaces after period.

Pg. 26. Second paragraph - "...the leading edge entry may cause     the 
 unary change..." has too many spaces between cause and the.

Pg. 34. First paragraph - "...as one or      more ..." has too many 
 spaces between or and more.

Pg. 34. Third paragraph - "... is intended forstandards that..." is 
 missing a space between for and standards.

Pg. 48. DESCRIPTION clause of PrtOutputStackingOrderTC - "...back of 
 the previous page.'lastToFirst' means..." should have some spaces 
 after the period.

Pg. 50. Indentation of PrtMarkerSuppliesTypeTC is not consistent.

Pg. 53. Indentation of PrtInterpreterTwoWayTC and PrtConcoleColorTC 
 objects need work.  Also, PrtAlertSeverityLevelTC on pg. 54, 
 PrtAlertGroupTC on pg. 56, and PrtAlertCodeTC on page 58.

Pg. 62. Type definitions from prtGeneralStartupPage to 
 prtAlertAllEvents are not lined up nicely.

Pg. 72. Comments describing the Input Group are formatted funny.

Pg. 74. The indenting of prtInputType and prtInputDimUnit are different 
 from each other.

Pg. 77. (PrtCapacityUnitTC). should not be allowed to wrap onto a line 
 by itself.

Pg. 77. The table starting at the bottom of the page should start at 
 the top of the next page.

Pg. 86. The figure starting at the bottom of the page should start at 
 the top of the next page.

Pg. 91. The description for prtOutputDecollating says "supports supports."

Pg. 91. The description for prtOutputOffsetStacking says "supports supports."

Pg. 123. Second from last line - Ttap should be trap.

Pg. 126. description of prtAlertGroup - "...are examples ofprinter 
 model..." should have space between of and printer.

Pg. 126. description of prtAlertGroupIndex - "...sub-unit caused the 
 alert.; for example,..." should not have period after alert.