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@Hitachi-hkis.com]
> Sent: Thursday, November 15, 2001 9:07 PM
> To: 'Juergen Schoenwaelder'
> Cc: bwijnen@lucent.com; dbh@enterasys.com; IMcDonald@crt.xerox.com;
> Bergman, Ron; harryl@us.ibm.com; RCasterline@crt.xerox.com;
> pmp@pwg.org;
> paf@cisco.com; ned.freed@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@ibr.cs.tu-bs.de]
> Sent: Thursday, November 15, 2001 1:28 AM
> To: Ron.Bergman@Hitachi-hkis.com
> Cc: bwijnen@lucent.com; dbh@enterasys.com; IMcDonald@crt.xerox.com;
> Ron.Bergman@Hitachi-hkis.com; harryl@us.ibm.com;
> RCasterline@crt.xerox.com; pmp@pwg.org; paf@cisco.com;
> ned.freed@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
This archive was generated by hypermail 2b29 : Tue Dec 04 2001 - 10:54:13 EST