Hi folks, Saturday (17 November 2001)
Ron - thanks for all your hard work on the latest I-D of Printer MIB v2.
I believe that we have just introduced three technical errors into the
latest Printer MIB v2 I-D, while changing all the 'Integer32' objects
to give them explicit ranges in the MIB:
1) prtStorageRefIndex - SYNTAX Integer32 (0..65535)
- but in Host Resources MIB v2 (RFC 2790)
hrStorageIndex - SYNTAX Integer32 (1..2147483647)
- so Printer MIB v2 should have
prtStorageRefIndex - SYNTAX Integer32 (0..2147483647)
2) prtDeviceRefIndex - SYNTAX Integer32 (0..65535)
- but in Host Resources MIB v2 (RFC 2790)
hrDeviceIndex - SYNTAX Integer32 (1..2147483647)
- so Printer MIB v2 should have
prtDeviceRefIndex - SYNTAX Integer32 (0..2147483647)
3) prtAlertIndex - SYNTAX Integer32 (1..65535)
- but the highest alert index MUST have the exact value of
prtAlertAllEvents - Counter32
- SMIv2 (RFC 2578) explicitly prohibits range restrictions on
Counter 32 in section 9 'Refined Syntax'
- so Printer MIB v2 should have
prtAlertIndex - SYNTAX Integer32 (1..2147483647)
Cheers,
- Ira McDonald
High North Inc
-----Original Message-----
From: Bergman, Ron [mailto:Ron.Bergman at Hitachi-hkis.com]
Sent: Thursday, November 15, 2001 5:06 PM
To: 'Wijnen, Bert (Bert)'; 'Juergen Schoenwaelder'
Cc: dbh at enterasys.com; IMcDonald at crt.xerox.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
Bert,
I just sent it to "Internet-Drafts". Here is a copy also.
Ron
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen at lucent.com]
Sent: Thursday, November 15, 2001 2:54 PM
To: Bergman, Ron; 'Juergen Schoenwaelder'
Cc: bwijnen at lucent.com; dbh at enterasys.com; IMcDonald at crt.xerox.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
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.
> 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
> 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?
> - 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.
> - 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.
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