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.