From: Wijnen, Bert (Bert) [bwijnen@lucent.com]
Sent: Monday, February 26, 2001 3:01 PM
To: Bergman, Ron; ggocek@crt.xerox.com; harryl@us.ibm.com;
rturner@2wire.com; Chris Wellens
Cc: ned.freed@innosoft.com; Patrik Fältström; David Harrington
Subject: RE: Status of Publication Request Printer MIB

All,
I have copied former PRINTMIB WG chair (Chris was it just you or
did you also have a co-chair) And I have copied authors.

David, thanks for you review.

Unfortunately, I then went in myself as well, and then
had some emails with David and Patrik and then did not follow
through to send the comments to the authors. So my appologies.
I had intended to go into detail about each of th issues... but
maybe it is better if you can first give a reaction.

The finishing MIB doc still needs to be revieuwed. 
Ron, maybe if you see the below, you can already think of
things that need to be fixed in the finishing MIB doc too?

So here we go.

- Summary
  - The Printer MIB document can not advance to Draft Standard 
    as is
  - In fact, the MIB document violates a few SMI rules so that it
    cannot even recycle at Proposed Status. You made some
    changes that are not allowed.
The reasons are that you make semantic changes to objects.
You cannot do that. If you need to make such changes, then
you must deprecate or obsolete the existing object and create
a new object with the new semantics.

As you can see from the detailed comments below, Dave
Harrington and I do not exactly agree yet on which ones are 
indeed semantic changes and which ones could be explained
as "clarifications"... but in any event, I see far too many of these.

I am attaching the detailed comments intertwined with some
response I gave to Dave... so you can see where there is
still more discussion needed. But I would like to see a response
from you on all these issues.

- Detailed comments in email between Dave and myself:

> ----------
> From: 	Wijnen, Bert (Bert)
> Sent: 	Tuesday, January 02, 2001 10:51 PM
> To: 	'dbh@enterasys.com'
> Cc: 	'Patrik Fältström'
> Subject: 	RE: FW: Publication Request for Printer MIB and Finisher MIB
> 
> My comments inline.
> 
> Bert
> 
> ----------
> From: 	David Harrington[SMTP:dbh@enterasys.com]
> Reply To: 	dbh@enterasys.com
> Sent: 	Thursday, December 28, 2000 7:16 PM
> To: 	Wijnen, Bert (Bert)
> Subject: 	Re: FW: Publication Request for Printer MIB and Finisher MIB
> 
> Hi Bert,  
> 
> I have reviewed the printer MIB. It has been updated in ways that
> violate the SMI rules.
> 
> Yep I found that too.
> 
> The MIB really needs to be sent back to a working group for thorough
> review and correction to be compliant with the SMI rules of updating
> object semantics. There are also some comments about the text portion of
> the document.
> 
> 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.
> 
> Text Portion:
> 
> Figure 2 references rfc1213 for the interfaces MIB. Should this be
> updated to RFC 2863?
> 
> You, I would like that.
> In fact I would prefer that in figures they do not use RFC numbers but
> MIB names or table names.
> 
> 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).
> 
> 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."
> 
> 2.2.13.1 the list is inconsistent in sentence structure. clause 3 needs
> a verb.
> 
> 2.2.13.4 "must" s/b MUST if an RFC2119 must.
> 
> 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.
> 
> 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 MIB ---
> 
> CodedCharset description removed information about SNMP encoding. Is
> this needed?
> 
> Yep I agree... it contains info that seems useful
> 
> 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
> 
> PrtChanneltypeTC seems so all-inclusive that it might not be useful.
> 
> 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?
> 
> Yep... but ... I also wonder why we need to define all
> these TCs. The new MIB has 31 TCs compared to 5 in RFC1759.
> 
> 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.
> 
> PrtConsoleDisableTC allows variable interpretation; this will likely
> lead to interoperability issues.
> 
> 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.
> 
> 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.
> 
> 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?
> 
> 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.
> 
> 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
> 
> prtGeneralCurrentLocalization has semantic changes.
> prtGeneralReset has semantic changes.
> 
> prtAlertCriticalEvents and prtAlertAllEvents - the description seems to
> imply a zero-based counter, rather than an SNMP-style counter.
> 
> prtCoverIndex is ambiguous as to whether it should remain consistent
> across reboots.
> 
> prtCoverStatus - check whether TC matches original semantics.
> 
> prtLocalizationLanguage and prtLocalizationCountry - changed semantics -
> maybe, depending on ISO 639 and ISO 3166.
> 
> prtStorageRefSeqNumber and prtStorageRefIndex and prtDeviceRefSeqNumber
> and prtDeviceRefIndex changed range, without changong name or OID.
> 
> PrtInputEntry has new columns added per row.
> 
> prtInputMediaDimFeedDirChosen semantic differences?
> 
> prtInputMediaName - does the REFERENCE constarin valuesa and thus change
> semantics?
> 
> prtInputSerialNumber changed OCTET STRING SIZE. Applications may be
> broken by the expanded size.
> 
> prtInputMediaType - semantics change
> 
> prtInputMediaColor - semantics change (effectively an enumeration
> extension)
> 
> This one I do not see? Dave can you explain?
> 
> prtOutputMaxDimFeedDir - DimUnits versus MediaUnits ?
> 
> prtOutputMaxDimFeedDir - SYNTAX changed to TC, which includes additional
> semantics
> 
> prtOutputPageCollated and prtOutputOffsetStacking - clarificiation or
> semantics change?
> 
> prtMarkerLifeCount - semantic change?
> 
> prtMarkerSuppliesIndex - is "successive printer power cycles" the same
> as "successive power cycles"?
> 
> prtMarkerSuppliesColorantIndex - semantic change?
> 
> prtMarkerColorantIndex - semantic change
> 
> prtMarkerColorantValue - semantic change
> 
> prtMarkerColorantTonality - no range specification in syntax
> 
> The Print Job Delivery Channel Group commented text differs from
> original - does this result in a semantic change?
> 
> prtChannelIndex - range changed; same name, OID
> 
> prtChannelCurrentJobCntlLangIndex and prtChannelDefaultPageDescLangIndex
> - range change per decsription
> 
> prtConsoleLightIndex - range change; weasel words added - stanadrd or
> not?
> 
> prtConsoleOnTime and prtConsoleOffTime - semantic change
> 
> prtAlertIndex - semantic change to range and access-type
> 
> prtAlertLocation - semantic change
> 
> printerV1Alert - should this be object-type or pbect-identity?
> 
> prtGeneralGroup, prtChannelGroup, prtAlertTableGroup - changed objects
> required for conformance
> 
> prtAlertTimeGroup - needs official status of deprecated, not just
> comment.
> 
> References - refers to internet drafts and out-of-print books.
> 
> I'd hope the authors can find decent responses to the above.
> 
> In addition I found:
> 
- 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). 
> - 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.
> 
> - 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.

> - 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 }
> 
> - 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.
> 
> Dave, thanks again for your detailed review.
> 
> Bert
---------------------- here follows an answer from David to my email above

> ----------
> From: 	David Harrington[SMTP:dbh@enterasys.com]
> Reply To: 	dbh@enterasys.com
> Sent: 	Friday, January 05, 2001 6:53 AM
> To: 	Wijnen, Bert (Bert)
> Cc: 	Patrik Faltstrom
> Subject: 	Re: FW: Publication Request for Printer MIB and Finisher MIB
> 
> 
> 
> "Wijnen, Bert (Bert)" wrote:
> > 
> 
> > 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.
> 
> > 
> > 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.
> > 
> > > 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.
> 
> > > 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.
> 
> > 
> > Dave, thanks again for your detailed review.
> 
> Glad to help.
> 
> > 
> > Bert
> David Harrington            Network Management Standards Architect
> dbh@enterasys.com           Office of the CTO
> +1 603 337 2614 - voice     Enterasys Networks
> +1 603 332 1524 - fax       Rochester NH, USA
> 
> 
> 
> 
>