Lloyd has published the schedule for completing our work on getting RFC
1759 advanced from Proposed to Draft Standard. In order for this to happen
..
(1) The Co-Chairs, Lloyd and I, put together a package to send to our Area
Directors. The package includes:
(a) our interoperability test results
(b) a list of all the required changes and their justification
(c) the revised draft document with the changes incorporated
(2) The Area Directors then review it and decide to pass it on to the
IESG, or send it back to us for more information, clarification,
modification, etc.
(3) If approved by the IESG, the document is submitted to the RFC editor.
The RFC editor has a great backlog, so it is taking about six months from
submission to the reappearance of the document as an Internet Draft
Standard.
The document that provides the guideline or framework for this activity is
RFC 2026. No, you don't have to read it, but the Chairs have to follow it,
and we continually reference it so everyone understands the purpose for
these activities.
Since the Printer MIB interoperability testing in February, 1997 at
Stardust until the present, we have all been working on clarifying the
areas of ambiguity and inconsistency that were uncovered. Fortunately
there were not very many, but some, like the Top 25 Alert Table and the
associated values, were difficult to hammer out and clearly specify.
Please consider that our intended audience for getting to Draft Standard is
our Area Directors and the IESG. They are going to look at our report and
give equal weight to all the items specified in the documents, and they
will scrutinize the implementation experience. We do not want to submit
our report to them with unresolved issues. For this reason, I have been
going over all the reports and documents to find anything that, in my
judgment, has not been satisfactorily resolved according to their
standards. In case it is not obvious, I will add that it is better for us
to find these items and resolve them *prior* to submitting our package,
then for the ADs to find these items and reject advancing the RFC to Draft
Standard.
There are still a few more that need to be resolved. One of these is
traps. Thanks to everyone who pointed out that their printer needs to be
explicitly configured to send a trap to a particular destination. My email
to Harry and the PMP incorrectly stated that the trap receiver is
automatically specified with the IWL Test Suite. Sorry for the error. On
the report to the ADs, I am going to add a footnote to this entry that
states "the test instructions did not clearly specify that this set of
tests were for traps and that the device under test had to be configured to
make the test generation device the trap receiver." That will explain the
results. Now, how do we prove that we have two interoperable
implementations for traps?
I do think it would be fine for Jay Martin to do some trap testing with a
manager, but I have a bad feeling that this is going to confirm that
everyone who did implement traps did so in a slightly different way.
It seems the consensus is that the majority of you want to retain traps in
the RFC, so I've tried to make a list of ways that we could do that, and
still get to Draft Standard:
(1) Explain that traps are "implementation dependent", that in the absence
of any standard way to do this in SNMP, each vendor did his own unique
implementation. When trap mechanisms are standardized by the IETF for all
MIBs, then the Printer MIB group will modify their implementations to be
consistent.
(2) The RMON2 MIB included a trap mechanism and definition in their
RFC2021. See http://ds.internic.net/rfc/rfc2021.txt There is a section
called "Trap Destination Table" on pages 98-101. They have defined:
trapDestIndex
trapDestCommunity
trapDestProtocol
trapDestAddress
trapDestOwner
trapDestStatus
Of these two alternatives, I don't know if (1) above will be acceptable,
although I will ask. For (2), I have email in to the RMON2 group to ask
them how thoroughly they tested this in their last interoperability testing
(to prove it works). If we are going to incorporate something like this,
then the question will be how did we test it. NOTE: I am not recommending
that we *reference* the RMON2 MIB. Heaven knows we certainly don't want to
do anything to make us dependent on someone else's MIB again. Rather, that
we just use what they have already developed, modified appropriately for
printers.
Please provide comments, or alternatives. Thanks.
Chris Wellens President & CEO
Email: chrisw at iwl.com Web: http://www.iwl.com/
InterWorking Labs, Inc. 244 Santa Cruz Avenue, Aptos, CA 95003
Tel: 408.685.3190 Fax: 408.662.9065