ISSUE 1
> Figure 2 references rfc1213 for the interfaces MIB. Should this be
> updated to RFC 2863?
> 
> Yes, I would like that.
> In fact I would prefer that in figures they do not use RFC numbers but
> MIB names or table names.
> 
The working group agrees to the use of table names within MIBs (System and 
Interfaces table in IETF MIB-II).

The working group does NOT agree to update references, so that Interfaces table 
says RFC 2863 (Interfaces Group MIB) which is an IETF Draft Standard and
does NOT update or obsolete IETF MIB-II (IETF Internet Standard status)
according to the latest RFC Index.

ISSUE 2
> 2.2.1.1. specifies I18N names versus non-I18N by the variable name.
> Shouldn't this be done by the SYNTAX clause, using T-Cs? Control codes
> are allowed IF specified in the DESCRIPTION clause. This makes it very
> hard for applications to know what to expect. Using a T-C would make
> this decision machine-parseable.
> 
> The Localization table is being used to control the localization
> information used to display info. I think this is mixing the "agent" and
> application responsibilities. Since an operator console is historically
> local to the system that implements the agent, this distiction may not
> seem important, but for an application remote from the agent, it should
> be the application that determines its capabilities for display, not the
> agent. The agent should simply support UTF-8.
> 
> I am also disturbed by their use of international character strings.
> In fact, in the new MIB, they now import DisplayString which they
> did NOT use in the RFC1759 version. And we've been pushing other
> MIBs to move from DisplayString to the use of UTF-8 based strings
> (Textual Conventions).
> 
The working group agrees that the seven 'xxxDescription' objects with their 
'charset' controlled by the value of 'prtGeneralCurrentLocalization' SHOULD 
have their SYNTAX (and their SEQUENCE clause) changed to a textual convention
that makes this explicit, for example "LocalizedDescriptionString".

We have already changed this section to state that the other string
objects (about 25) SHOULD be UTF-8 (RFC 2279) - given the many shipping
implementations of Printer MIB v1 (RFC 1759) that use legacy character
sets in some of these objects, this is the best we can do and remain
backward compatible.

The SNMPv3 WG has rejected changing old 'DisplayString' objects in the
System group to 'SnmpAdminString' (UTF-8).  Any such change in the
Printer MIB would be far worse and would NOT be a semantically
compatible change.

ISSUE 3
> 2.2.4 recommend changing "A printer contains one or more output
> mechanisms. The Output Group in the model represents these." to "The
> Output Group in the model represents the one or more output mechanisms
> contained by a printer."
> 
Agreed we should make this change.

ISSUE 4
> 2.2.13.1 the list is inconsistent in sentence structure. clause 3 needs
> a verb.
> 
Agreed.  Change "(3) Alert codes reported in the Alert Table." to "(3) Alert 
codes are reported in the Alert Table." 

ISSUE 5
> 2.2.13.4 "must" s/b MUST if an RFC2119 must.
> 
The WG Agrees to the following changes to correct this problem...
- Fix the first 'must' by editing the two sentences as follows:
(old)
  "When the table is full and new alerts need to be added, old
   alerts must be removed.  An alert to be deleted should be chosen
   using the following rules:"
(new)
  "When the table is full and new alerts need to be added,
   an old alert to be deleted should be chosen
   using the following rules:"
- Fix the second and third 'must' as follows:
(old)
  "In the event that a critical binary alert must be managed out of the
   alert table; when space allows and the alert condition still exists,
   the alert must be re-added to the alert table even if there was no
   subsequent transition into the associated state."
(new)
  "In the event that a critical binary alert has been deleted out of the
   alert table; when space allows and the alert condition still exists,
   the alert should be re-added to the alert table even if there was no
   subsequent transition into the associated state."

ISSUE 6
> 2.4.1 the text has been changed in a way that seems to allow
> modifications in a way that is not consistent with IETF/SMI rules, which
> RFC1759 did not allow.
> 
The WG agrees we should restore the original text verbatim from RFC 1759.
The additional explanatory information in the latest Printer MIB v2
draft (9 August 2000) is ambiguous and susceptible to misinterpretation.

ISSUE 7
> 3.4.x recommends modifications to the usage of the Host resources MIB
> that may not be consistent with design of the Host resources MIB. This
> could lead to interoperability issues for applications which manage
> printers and other hosts simultaneously. This section should be reviewed
> closely by an expert in the Host resources mib design. It may be
> desirable to upgrade the Host Resources MIB printer to better reflect
> the nature of existing printers.
> 
> Nor sure I read it the same way... but it is text that indeed may need
> some more review.
> 
The working  has agreed to DELETE sections 3.4, 3.4.1, 3.4.2, and 3.4.3
entirely.  They were NOT present in RFC 1759.  

ISSUE 8
> CodedCharset description removed information about SNMP encoding. Is
> this needed?
> 
> Yep I agree... it contains info that seems useful
>
A normative reference to BCP 19 (RFC 2278 "IANA Charset Registration
Procedures") was added to this section.  The original text in RFC 1759 on
character set usage (especially the use of the BOM in Unicode/ISO-10646) 
was just plain WRONG and was agreed to be removed by the working group.

ISSUE 9 
> PrtChannelStateTC description doesn't quite match with enumerations.
> This could lead to interoperability problems if implementors interpret
> differently.
> 
> I agree that it could at least use some clarification
> 
The working group agrees that the DESCRIPTION is ambiguous and will be 
changed as follows:
(old)
        "The state of this print job delivery channel. The value
        determine whether control information and print data is allowed
        through this channel."
(new)
        "The state of this print job delivery channel. The value
        determines whether print data is allowed
        through this channel."

ISSUE 10
> PrtChanneltypeTC seems so all-inclusive that it might not be useful.
> 
The working group totally agrees with your statement.  With the exception of 
several new enumerations and the change to a textual convention, this is 
identical to RFC 1759.  When RFC 1759 was drafted, the group attempted to define 
every possible channel type.  Implementation experience has shown that a number 
of these channel types will never be used and many will only be used only by a 
few vendors.  To reduce some of the confusion in this set of enumerations, a 
number of them have been deprecated.  SNMP rules do not allow a real cleanup of 
this group.  

ISSUE 11
> The enumeration types for each TC is specified in a comment. Would it be
> better to make it part of the description to ensure the update semantics
> are considered part of the object semantics?
> 
This, again, is formatted as in RFC 1759.  Although the working groups agrees
the suggestion would be an improvement, we decline to make such an extensive 
editorial change.

ISSUE 12
> Yep... but ... I also wonder why we need to define all
> these TCs. The new MIB has 31 TCs compared to 5 in RFC1759.
> 
> That bothered me as well. Just because you can doesn't mean you should.
> 
The embedded enumerations were carefully examined by the working group to 
determine which could be used in related MIBs.  The additional 26 TCs were 
agreed to be created.  Several of these TCs are NOW being used by the Finisher 
MIB.

ISSUE 13
> PrtOutputPageDeliveryOrientationTC expects different interpretations in
> different locales; thsi will probably lead to interoperability issues
> between applications, and could confuse users. I recommend this be
> changed to use terms that are not interpreted differently per locale.
> 
The text in question was taken directly from the corresponding object in
RFC 1759.  

ISSUE 14
> PrtConsoleDisableTC allows variable interpretation; this will likely
> lead to interoperability issues.
> 
These new enumerations were requested to be added as a result of the 
interoperability test by one of the participants.  Unless there is an 
indication that these values have been included in an imlementation,
these values will be removed from the MIB TC.

ISSUE 15
> PrtAlertGroupTC is declared as being both type 1 and type 2 enumeration.
> Isn't this just a type 2 enumeration? if not, I question whether this is
> consistent with SMI rules.
> 
This should be just a type 1 enumeration.  Values defined in other MIBs
require conformance to type 1 rules in those documents.  Remove "...type 
2 enumerations and are..."  

ISSUE 16
> I am concerned that many objects have so many unrelated enumerations. It
> seems that it would make more sense, and be easier for applications to
> deal with, if more objects were created which represented different
> aspects of printer management. PrtAlertCodeTC is one item that
> demonstrates this use of one object where multiple objects might be a
> better choice.
> 
This would be a fundamental change in the architecture of RFC 1759.  In
practice the alert table is conceptually very clean and practical.  (Note 
that this architecture was proposed by one of the ADs for RFC 1759.)   

ISSUE 17
> PrtGeneralEntry has had new columns added to each row; shouldn't this
> require a name change? This could be done using augments to not violate
> SMI rules, couldn't it?
> 
This comment applies to the Auxiliary Sheet Group, the Administrative
section, and the General Alert Table section.  These objects have been
included in many implementations they must stay in the 'prtGeneralTable' 
at their current OIDs.  There is strong consensus within the WG that these 
columns NOT be moved to a separate table that AUGMENTS 'prtGeneralTable'.
Some implementations of the Printer MIB v2 have been shipping for over two 
years.  The WG prefers to change the MODULE-COMPLIANCE and OBJECT-GROUP 
macros to define new compliance groups for these new objects.

> Is it legal to change the types in an Entry to a TC?
> 
> As long as the underlying data type stays the same and the semantics
> don't change, then I think it is OK.
> 

ISSUE 18
> prtGeneralConfigChanges changed semantics, btu used the same name and
> OID. I am also concerned that the semantics are ambiguous - it should be
> incremented if an output tray is added, but not when an input tray is
> removed?
> 
> This one is questionable? If they call out consensus, that it is a
> clarfification, then I might accept.
> 
> Note that if they do not explain it that way, and if it indeed is a 
> change in semantics, then ecven if they recycle at PS, it would
> still mean that they need top deprecate this object and define
> a new one with the new semantics
> 
> Compare the following descriptions:
> RFC - "Counts configuration changes that change the capabilities of a
> printer, such as the addition/deletion of input/output bins, the
> addition/deletion of interpreters, or changes in media size.  Such
> changes will often affect the capability of the printer to service
> certain types of print jobs."
> 
> draft - "Counts configuration changes within the printer. A
> configuration change is defined to be an action that results in a change
> to any MIB object other than those that reflect status or level, or
> those that act as counters or gauges. In addition, any action that
> results in a row being added or deleted from any table in the Printer
> MIB is considered a configuration change. Such changes will often affect
> the capability of the printer to service certain types of print jobs."
> 
> In the original, MIB objects and tables aren't even mentioned. 
> In the draft, that is how to determine what to count.
> 
> In the original, it counts "... changes that change the capabilities
> ..."
> In the draft, "Such changes will often affect the capability..."
> 
> These appear to be counting different, but overlapping or related sets
> of things.
> 
This object was extensively discussed by the working group and the changes
were intended to clarify the use of the object.  No change in semantics is
intended.  You have, however, pointed out a remaining ambiguity.  We will 
change "...input tray is removed..." to "...input tray is temporarily 
removed to load additional paper..."  This statement was not intended to 
imply a permanent removal of the tray.  

ISSUE 19
> prtGeneralCurrentLocalization has semantic changes.
>
This object has only a slight wording change intended as a clarification.
No semantic changes were expected.  We will also add a reference to the 
new textual convention 'LocalizedDescriptionString'(proposed in issue 2).

ISSUE 20
> prtGeneralReset has semantic changes.
> 
Wording was added to explain the use of the enumerations.  There was no
intent to change the semantics.  

ISSUE 21
> prtAlertCriticalEvents and prtAlertAllEvents - the description seems to
> imply a zero-based counter, rather than an SNMP-style counter.
> 
You are correct.  This operation is desired to allow a management application
to be able to better track printer alerts.  If this value is less than the
previous value observed, it would indicate that the printer has been power
cycled and the alert table has been reset.  If these values were not 
initialized, the starting value could indicate to the management app that
a large number of alerts were generated on the printer since it last queried
these values.  This is important since printers can be frequently power 
cycled.  A new datatype would involve a change in semantics.

The WG believes this is LEGAL behavior, per section 7.1.6 of RFC 2578:
  "Counters have no defined "initial" value, and thus, a single value of
   a Counter has (in general) no information content.  Discontinuities
   in the monotonically increasing value normally occur at re-
   initialization of the management system, and at other times as
   specified in the description of an object-type using this ASN.1 type"


ISSUE 22
> prtCoverIndex is ambiguous as to whether it should remain consistent
> across reboots.
> 
Many modern printers can be upgraded with new features such as additional
input trays and finishing units.  The installation of these features almost
always requires power to be off.  While this does not happen often, it can
happen.  A management station should be aware of this possibility.  

ISSUE 23
> prtCoverStatus - check whether TC matches original semantics.
> 
The only change is that "door" was changed to "cover" in enumerations 3 and
4.  This was agreed to be a clarification.  

ISSUE 24
> prtLocalizationLanguage and prtLocalizationCountry - changed semantics -
> maybe, depending on ISO 639 and ISO 3166.
> 
The only change here is the use of "DisplayString" in place of "OCTET
STRING".  This will be reverted back to the original.  

ISSUE 25
> prtStorageRefSeqNumber and prtStorageRefIndex and prtDeviceRefSeqNumber
> and prtDeviceRefIndex changed range, without changong name or OID.
> 
The working group agreed that 0 would never be a valid index value and
was not appropriate, so the lower value was changed to 1.  Since this is
an illegal change we will restore the value to 0.  

ISSUE 26
> PrtInputEntry has new columns added per row.
> 
This comment applies to "prtInputMediaLoadTimeout" and "prtInputNextIndex".  
See issue #17.

ISSUE 27
> prtInputMediaDimFeedDirChosen semantic differences?
> 
This appears to be identical to RFC 1759.  The format of the text in the
Description clause has been fixed.  

ISSUE 28
> prtInputMediaName - does the REFERENCE constarin valuesa and thus change
> semantics?
> 
There is no intention to change the semantics of this object.  This appendix
was also present in RFC 1759.  This appendix lists the ISO/IEC 10175 
standardized names, but there is no requirement that these must be used.

ISSUE 29
> prtInputSerialNumber changed OCTET STRING SIZE. Applications may be
> broken by the expanded size.
> 
We will change this back to the original value of 32.  (page 73)

ISSUE 30
> prtInputMediaType - semantics change
> 
This was believed to be a clarification.  Since the object contains a
string that is intended to be displayed, it was always believed that 
the values shown in the Description were examples.   

ISSUE 31
> prtInputMediaColor - semantics change (effectively an enumeration
> extension)
> 
> This one I do not see? Dave can you explain?
> 
> In the RFC, there is an enumeration of fixed strings, and the ability
> for vendors to add extensions. Assuming the fixed strings enumerated by
> the other standards have some common meaning, it is important to avoid
> name space conflicts with vendor-specific names.
> 
> The RFC specifies the standard list with the words "which are:", which
> implies that is is a non-changing list. Vendors could therefore feel
> free to add their own names, such as "ivory". The separation of
> namespaces is guaranteed by the fixed list of standard colors.
> 
> The draft changes "which are:" to "such as:" which implies that the
> standard list may grow. If the ISO 10175 added "ivory" after a vendor
> did so, and the underlying color definition differed between the "ivory"
> of the vendor and the "ivory" of the ISO 10175 spec, then there is an
> interoperability problem due to the ambiguity caused by the name
> conflict.
> 
> I suspect that for 90+% of the printing community a vendors's "ivory"
> and the standard "ivory" will be close enough that such a conflict won't
> matter. However, I assume the reason why this is even in the mib is to
> ensure the ability to control the input to a print job remotely with a
> reasonable expectation that the input media color will be a specific
> color. For a high-quality print job, the distinction between the two
> ivories may be significant.
> 
> If the new text had existed at the time of PS review, it might have led
> a reviewer to request a change to the object design to better ensure
> name space diferentiation. The text as specified in the RFC has the
> necessary differentiation. The draft does not. If "such as:" was the way
> the text had read for the advancement to PS, and I had been the reviewer
> then, I think I would have questioned the issues related to name space
> collision. If the text had been "which are:", I think I would have found
> that adequate to protect against name space collision. I most certainly
> would have wanted to see "such as:" discussed in the WG.
> 
> I think this is a semantic change. I am concerned about the name space
> collisions that could occur, and the potential for interoperability
> problems in the future. Whether it is enough to justify deprecation is a
> judgement call of the WG, the chairs, and the AD.
> 
We will change "such as" back to "which are".  

ISSUE 32
> prtOutputMaxDimFeedDir - DimUnits versus MediaUnits ?
> 
Good catch!  This should be PrtMediaUnitTC.  (Also applies to 
prtOutputMaxDimXFeedDir, prtOutputMinDimFeedDir, and
prtOutputMinDimXFeedDir.)  


ISSUE 33
> prtOutputMaxDimFeedDir - SYNTAX changed to TC, which includes additional
> semantics
> 
Don't understand this comment.  No syntax changes are in this object.

ISSUE 34
> prtOutputPageCollated and prtOutputOffsetStacking - clarificiation or
> semantics change?
> 
The changes in both of these object Description clauses is intended to
provide a reference to the glossary.  These terms are well known in the
printer industry and the change was merely to help others.  

ISSUE 35
> prtMarkerLifeCount - semantic change?
> 
This change is only a clarification.  CounterUnit was changed to 
prtMarkerCounterUnit, which is the full name of the appropriate object that
defines the units.  

ISSUE 36
> prtMarkerSuppliesIndex - is "successive printer power cycles" the same
> as "successive power cycles"?
> 
Yes, but "printer" should not have been removed and will be restored.  

ISSUE 37
> prtMarkerSuppliesColorantIndex - semantic change?
> 
This is a clarification from the interoperability test.  

ISSUE 38
> prtMarkerColorantIndex - semantic change
> 
The deleted text was not intentional and will be restored.  

ISSUE 39
> prtMarkerColorantValue - semantic change
> 
This change was made to clarify that the list was not exhaustive and any
additions to ISO 10175 and ISO 10180 are allowed.  

ISSUE 40
> prtMarkerColorantTonality - no range specification in syntax
> 
This specification is unchanged from RFC 1759.  

ISSUE 41
> The Print Job Delivery Channel Group commented text differs from
> original - does this result in a semantic change?
> 
The added text was determined by the working group to be required for
clarification.  No change is semantics is intended.  Two examples were
removed from the text since they were determined to be redundant and
are now deprecated.  

ISSUE 42
> prtChannelIndex - range changed; same name, OID
> 
The range added was assumed to be the defined range for an index.  We will
remove the added range to avoid confusion.   

ISSUE 43
> prtChannelCurrentJobCntlLangIndex and prtChannelDefaultPageDescLangIndex
> - range change per decsription
> 
The added text is intended to be a clarification.  Implementations that
participated in the interoperability test were conformant and requested the
additional text to be added.  

ISSUE 44
> prtConsoleLightIndex - range change; weasel words added - stanadrd or
> not?
> 
Again this is a clarification.  See issue 22.  

ISSUE 45
> prtConsoleOnTime and prtConsoleOffTime - semantic change
> 
This again is a clarification.  The original description had no way of 
indicating the light was on and not blinking.  

ISSUE 46
> prtAlertIndex - semantic change to range and access-type
> 
The range added was assumed to be the defined range for an index.  We will
remove the added range to avoid confusion.  The syntax was changed to read-
only since the traps return this oid and it was our understanding that the
oid could not be not-accessible.   We will restore the access-type to
not-accessible.   

ISSUE 47
> prtAlertLocation - semantic change
> 
This change is a clarification from the interoperability test.  

ISSUE 48
> printerV1Alert - should this be object-type or pbect-identity?
> 
This is unchanged from RFC 1759.  The WG also believes that this is correct 
usage - this is not the definition of the SMIv1 translated TRAP-TYPE, just 
the base arc for translation.

ISSUE 49
> prtGeneralGroup, prtChannelGroup, prtAlertTableGroup - changed objects
> required for conformance
> 
The working groups agrees to add new OBJECT-GROUP macros for these new 
objects and also to include additional MODULE-COMPLIANCE macros
for the conformance packages.  None of the new objects will be made
MANDATORY for conformance to the MIB (an error in the current draft).

ISSUE 50
> prtAlertTimeGroup - needs official status of deprecated, not just
> comment.
> 
Will change as suggested.  

ISSUE 51
> References - refers to internet drafts and out-of-print books.
> 
This is a consequence of this document being in the queue for almost 5 years.
This section will be updated as appropriate.  

> I'd hope the authors can find decent responses to the above.
> 
> In addition I found:
> 

ISSUE 52
- You must mention in abstract that this doc obsoletes RFC1759
- These days we want the MIB boilerplate as found on the
  www.ops.ietf.org web page. You can see many other MIB
  documents that have it.
- I am missing an appendix with list of changes (I know some other
  AD will worry about it). 

The document changes are already present in section 4 "Differences from
Previous Version" ('Previous Version' will be changed to 'RFC 1759').
The other two items will be corrected.  


> - This MIB cannot advance to DS. They for example add a set of
>   objects, and so they need to recycle for that.
> - If the semantics of some of these objects and TCs have changed, 
>   then the names (and OIDs for objects) need to change also. The old
>   ones then need to be deprecated or obsoleted.
> - There seem so many changes that I wonder if we can do this without 
>   resurrecting the PRINTMIB WG. Or is the external PWG group 
>   trying to do this work. In that case, we need like a 4-week IETF Last 
>   Call (even to recycle at PS).... but we need to see answers first.
> 

ISSUE 53
> - I see SMICng compile error/warning:
>   W: f(printmib.mi2), (4494,1) Item "printerV2Alert" is not contained in 
>        any group  defined in the current module
>   This needs to be fixed.
> 
> - Need the LAST-UPDATED and REVISION clauses to use 4-digit
>   years as specified in RFC2578.
> 
> - They need to add REVISION clauses. And the changes also need to
>   be  documented in such a clause. See RFC2863 as an example.
The above will be corrected.  

ISSUE 54
> - quite a set of requirements and or compliance related statements
>   are made throught the document. I believe that a lot of those can
>   actually be captured in the MODULE-COMPLIANCE statement
>   (maybe we need multiple such statements).
>   For example, if you have a pre-req that the system group of MIB-II
>   is implememented, then you can add to the MODULE-COMPLIANCE
>   this clause:
> 
>         MODULE SNMPv2-MIB
>                   MANDATORY-GROUPS { systemGroup }
> 
The above will be corrected.  

ISSUE 55
> - You cannot ADD objects to a MODULE-COMPLIANCE statement
>   after the MIB is published as PS. So if you want to add new
>   objects (even if you recycle at PS) then you must add another
>   new MODULE-COMPLIANCE statement. You can deprecate 
>   or obsolete the old one.
> 
This will be corrected.  

> > Some of your comments could be responded to with "we claim they are
> > clarifications". I guess I'd be willing to accept that, but in order to
> > do so I would want to see an explicit call for consensus that such is 
> > indeed agreed upon.
> 
> Yes, some may simply be clarifications.
> 

Comments compiled by:
Ron Bergman
Hitachi Koki Imaging Solutions