Bert,
Our latest version MIB is now *finally* available at:
http://www.ietf.org/internet-drafts/draft-ietf-printmib-mib-info-11.txt
Unfortunately, the posted version is missing form feeds. Ira McDonald has a
version that contains the missing form feeds and is also planning to run it
through David Perkins' "mstrip" tool to extract the MIB. I can send to you
either the version with form feeds and/or the stripped MIB if don't want to
deal with unfriendly version that was posted.
Ron Bergman
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen at lucent.com]
Sent: Saturday, December 08, 2001 9:08 PM
To: Bergman, Ron; 'bwijnen at lucent.com'
Cc: 'schoenw at ibr.cs.tu-bs.de'; 'dbh at enterasys.com'; 'pmp at pwg.org'; Ira
McDonald (E-mail); Harry Lewis (E-mail); Ray Casterline (E-mail 2)
Subject: RE: Response to Printer MIB Comments of 15 Nov, 2001
I did not yet look at the new rev (too busy preparing for
IETF... and I bet Dave Harington is in same situation).
Why don;t you post the new draft as soon as repository opens up
again and then we'll review.
Bert
> -----Original Message-----
> From: Bergman, Ron [mailto:Ron.Bergman at Hitachi-hkis.com]
> Sent: Tuesday, December 04, 2001 5:03 PM
> To: 'bwijnen at lucent.com'
> Cc: 'schoenw at ibr.cs.tu-bs.de'; 'dbh at enterasys.com'; 'pmp at pwg.org'; Ira
> McDonald (E-mail); Harry Lewis (E-mail); Ray Casterline (E-mail 2)
> Subject: Response to Printer MIB Comments of 15 Nov, 2001
>>> Bert,
>> The Working Group has had extensive discussions relating to
> the five points that you presented on November 15. We have
> finally reached an agreement and propose changes for all 5
> issues.
>> Please let me know if you would like an updated draft
> immediately, or would like first to complete your review of
> the previous draft (version 10). I have not seen any
> comments on this version from either yourself or David or
> Juergen. Can we assume there are no further issues?
>> Please see the comments from the WG, prefixed by "WG>>".
>> Ron Bergman
>>> Original Message...
>> Ron... if you have it complete, maybe you can send us a prelimenary
> copy to quickly check if we are happy with it.
>> Juergen, that for checking with your nice little tool/toy.
>> More comments inline
>> Bert
>> > -----Original Message-----
> > From: Bergman, Ron [mailto:Ron.Bergman at Hitachi-hkis.com]
> > Sent: Thursday, November 15, 2001 9:07 PM
> > To: 'Juergen Schoenwaelder'
> > Cc: bwijnen at lucent.com; dbh at enterasys.com; IMcDonald at crt.xerox.com;
> > Bergman, Ron; harryl at us.ibm.com; RCasterline at crt.xerox.com;
> > pmp at pwg.org;
> > paf at cisco.com; ned.freed at mrochek.com> > Subject: RE: Print MIB 09
> >
> >
> > Juergen,
> >
> > Thank you again for the comments. I have just about
> > completed the draft, so
> > I should be able to incorporate any changes necessary in
> > version 10. See my
> > comments below prefixed by RB>>.
> >
> > Ron
> >
> > -----Original Message-----
> > From: Juergen Schoenwaelder [mailto:schoenw at ibr.cs.tu-bs.de]
> > Sent: Thursday, November 15, 2001 1:28 AM
> > To: Ron.Bergman at Hitachi-hkis.com> > Cc: bwijnen at lucent.com; dbh at enterasys.com; IMcDonald at crt.xerox.com;
> > Ron.Bergman at Hitachi-hkis.com; harryl at us.ibm.com;
> > RCasterline at crt.xerox.com; pmp at pwg.org; paf at cisco.com;
> > ned.freed at mrochek.com> > Subject: Re: Print MIB 09
> >
> >
> >
> > >>>>> Bergman, Ron writes:
> >
> > Ron> I believe that all issues are now resolved and I
> estimate we will
> > Ron> have a revised MIB by early next week.
> >
> > I did run the MIB through smidiff yesterday (a tool which
> computes the
> > changes between two MIB versions) and I found some things I
> wanted to
> > share.
> >
> > - There are some changes which, if you take the rules very strictly,
> > can turn compliant implementations to be non-compliant,
> even though
> > the document says:
> >
> > This draft supercedes and replaces RFC 1759. However, a
> compliant
>> I would also change "daft" in "document" so the text is still
> valid when
> it becomes an RFC.
>> WG>> This is a very good suggestion and will be changed.
> **************************************************************
> *********
>> > implementation of RFC 1759 is also compliant with this
> draft. The
> > following changes to RFC 1759 are included:
> >
> > For example, prtConsoleLightIndex changed from Integer32
> (0..65535)
> > to Integer32 (1..65535). Perhaps this just fixes a typo in the
> > original MIB - but it would be worthwhile to list changes such as
> > this explicitely.
> >
> > RB>> This was definitely a typo, since index values are
> never zero.
> > I will add this (and two other similar changes) to section 4.
> >
> Such changes would be good to list in the REVISION clause as well
>> WG>> We will add as suggested and review the remaining changes to
> determine if any others should also be included.
> **************************************************************
> *********
>> > Also, prtInputDefaultIndex changed from Integer32 (1..65535) to
> > Integer32 and prtMarkerColorantValue changed from (SIZE
> (0..63)) to
> > (SIZE (0..255)).
> >
> > RB>> prtInputDefaultIndex was also a typo, since this object allows
> > -1 per the description clause. This has been corrected.
> >
> It seems to me that maybe it should be:
>> Integer32 ( -1 | 1..65535)
>> You're no allowing any negative value, are you?
>> And how about the size extension?
>> WG>> In reviewing this issue we have determined that this is not a
> change compatible with RFC 1759, since the text in the
> description clause that indicates the use of -1 was not in
> RFC 1759. The WG has agreed to remove this added text and
> restore the range to (1..65535) as in RFC 1759.
> **************************************************************
> *********
>> > - The prtChannelIndex and prtAlertIndex both have a range
> > (1..2147483647) addded while all the other *Index objects seem to
> > prefer (1..65535). The wider range is from an architectural
> > standpoint better, but for consistency, the smaller range might be
> > better. What did people actually implement?
> >
> > RB>> I will change both to the smaller value to be consistent.
> >
> And the WG explicitly agrees with all this, right?
> If so, then I am OK with that, assuming that this is based on
> implementation experience.
>> In RFC1759 there was no limit, so (1..2147483647) was the range of
> valid values there.
>> WG>> The range for prtChannelIndex is OK as (1..65535). No printer
> will ever require more than this amount. However, we have found
> a problem with prtAlertIndex and will change this back to
> (1..2147483647).
>> There is also a compatibility problem with the smaller range for
> prtStorageRefIndex and prtDeviceRefIndex. To agree with RFC 2790
> (HR MIB) these will be changed to (0..2147483647). This change
> will also be noted in the REVISION clause.
> **************************************************************
> *********
>> > - Should you not use InterfaceIndexOrZero in prtChannelIfIndex? The
> > description also refers to RFC 1213 where it should refer to the
> > IF-MIB, currently in RFC 2863. This creates a dependency
> but I think
> > this is fine as the IF-MIB is already at Draft.
> >
> > RB>> Use of RFC 2863 was previously review by the WG and it
> was felt
> > this was likely to result in too many additional dependencies.
> > Use of InterfaceIndexOrZero also has similar problems.
> We would
> > prefer to not change since there have not been any
> implementation
> > problems reported in this area.
> >
> Ron... it seems that InterfaceIndexOrZero is exactly what you want.
> It is the most up to date way on how we specify these things
> these days.
> The TC is an Integer32 underneath that allows exactly the values that
> you want. And so there is no change on the protocol on the wire or
> on the data types that you send/receive.
> I strongly recommend to use InterfaceIndexOrZero.
>> WG>> We have reviewed this issue again and agree to change the SYNTAX
> clause to InterfaceIndexOrZero. Our previous concerns were based
> on this "tied" into RFC 2863. As long as we do not have to
> require RFC 2863, this is acceptable. (Most printer manufactures
> have incorporated purchased IP stacks and the cost and logistics
> of upgrading these stacks would be prohibitive at this time.)
> **************************************************************
> *********
>> Right now you agreed to recycle at PS. So it is a good time
> to do this.
> By the time you ever get to Draft or (full) Standard, MIB II (RFC1213)
> may have gone to historic, and then you need to change anyway.
>> Bert
>