Subject: PMP> Why were MIN-ACCESS clauses added to Printer MIB v2?

From: "Gocek, Gary" <[email-masked]>
Date: Thu, 28 Sep 2000 16:35:14 -0400

Way back in the first draft (1997) of the new Printer MIB following RFC
1759, all objects with a MAX-ACCESS of read-write were given a MIN-ACCESS of
read-only.  Previously, only two objects had a MIN-ACCESS clause, but in the
latest draft of Printer MIB v2 there are 51 such objects.  There is a short
note about this change in the document "changes_to_rfc_1759.pdf".

In a recent discussion with my colleagues, we wondered why these MIN-ACCESS
clauses were added.  Of course, we can implement read-write objects if we
want to, because that's what the MAX-ACCESS clauses state.  But we don't
understand why the MIN-ACCESS clauses were added.  We see cases where
read-write access is helpful, such as during a remote printer installation.

Agent implementations that are compliant with RFC 1759 have the objects
implemented as read-write, since there are no MIN-ACCESS clauses in 1759
that allow read-only.  New agent implementations of the v2 MIB would be
compliant with read-only access, but might break old management or other
apps that expect to be able to set all those values.

Can anyone think of a good defense for the new MIN-ACCESS clauses?

Thanks,
Gary Gocek, Xerox Corp.

---

From: "Harry Lewis/Boulder/IBM" <[email-masked]>
Date: Fri, 29 Sep 2000 10:47:07 -0600

Gary, I'm not sure the genesis of documenting MIN-ACCESS. I guess I 
considered it a formality. 

Our interpretation of the spirit of the change to specify MIN-ACCESS was 
to reflect that, in some cases, the printer can more accurately and/or 
reliably sense the value. Example - level of paper in tray is R/W because 
some printers are unable to sense. This allows an "operator" to load media 
and use a software application to SET the current level. However, if the 
device automatically detects dynamic changes in paper level... it seems 
appropriate and desirable to disallow the SET.  If the printer's own 
measurements give an accurate, up-to-date value for an OID, then making it 
R/W could actually reduce accuracy.

For OIDs like General and Console localizations, I agree, it doesn't seem 
too practical to have specified MIN-ACCESS. Perhaps it would make sense if 
the printer could only support one language (or one language at a time... 
with re-boot required). This seems pretty far fetched. 

Harry Lewis
IBM Printing Systems

"Gocek, Gary" <[email-masked]>
Sent by: [email-masked]
09/29/2000 06:46 AM

        To:     "[email-masked]'" <[email-masked]>
        cc: 
        Subject:        RE: PMP> Why were MIN-ACCESS clauses added to Printer MIB v2?

I made my point a little too broadly.  We can see how MIN-ACCESS clauses
ease the implementation burden.  However, we noticed a couple of cases
(prtGeneralCurrentLocalization and prtConsoleLocalization in particular)
where we feel that the new MIN-ACCESS clauses fundamentally change the
printer MIB, and we wonder if there is a justification for adding those
particular MIN-ACCESS clauses.  There might be a few more instances, but 
not
all 51.

Thanks again,
Gary

> -----Original Message-----
> From: Gocek, Gary [mailto:[email-masked]]
> Sent: Thursday, September 28, 2000 4:35 PM
> To: [email-masked]'
> Subject: PMP> Why were MIN-ACCESS clauses added to Printer MIB v2?
>
>

---

From: "Gocek, Gary" <[email-masked]>
Date: Fri, 29 Sep 2000 12:59:20 -0400

Harry answered part of the question.

The concern revolves around the belief that some scenarios require
read-write access for certain values, and that prior management apps
expecting read-write access (the norm for 1759) might get read-only access
(allowed by v2).  For example, a remote install task wants to write a few
values, such as the localization values, the current operator and service
person values, and maybe a few more.  If a vendor claims to be compliant
with the printer MIB, but the mandatory service person info can't be set by
the customer, that seems pretty broken.  Maybe the word "fundamental" is too
strong, but it's been a source of conversation for a few days here at Xerox.

In fact, for MOST objects, we can see how the MIN-ACCESS clause will ease
the implementation work (as Harry says), but it seems like the MIN-ACCESS
clauses were added without considering each object individually (as Harry
implies).

On that note, we now notice that of 53 objects with a MAX-ACCESS of
read-write, 51 have a MIN-ACCESS of read-only.  The two without MIN-ACCESS
are prtGeneralReset and prtInputMediaDimXFeedDirDeclared, and we don't know
why they were chosen to be left without a MIN-ACCESS value.

And yes, I was the final editor for the v2 draft, but I (and we at Xerox)
didn't notice this MIN-ACCESS issue until now.

Thanks,
Gary Gocek, Xerox

> From: Ron Bergman [mailto:[email-masked]]
> Sent: Friday, September 29, 2000 12:05 PM
> To: Gocek, Gary
> Cc: [email-masked]'
> Subject: Re: PMP> Why were MIN-ACCESS clauses added to Printer MIB v2?
> 
> 
> Gary,
> 
> Could you please explain why you feel "the new MIN-ACCESS clauses
> fundamentally change the printer MIB"?
> 
>     Ron Bergman
>     Hitachi Koki Imaging Solutions
> 
> 
> "Gocek, Gary" wrote:
> 
> > particular MIN-ACCESS clauses.  There might be a few more 
> instances, but not
> > all 51.
> >
> > Thanks again,
> > Gary
> >