Since the Mirror table is optional, I do not have a real problem with it
either added or removed. But Harry does have a good point and it probably
best that it not be included in version 1.0. This would also be a better
position for us with the IETF.
Anyone else have comments?
Ron Bergman
Dataproducts Corp.
On Fri, 8 Jan 1999 harryl at us.ibm.com wrote:
>>> Tom. This is a much better proposal. I only have one concern.
>> The System Group was supposed to enable applications to determine whether
> or not the (optional) mirror table was supported. Perhaps 1.0 should just
> be the first PWG standard Job MIB (as agreed initially) and the (new)
> internal version (basis for next external) should have the mirror table and
> Systems Group.
>> Harry Lewis - IBM Printing Systems
>harryl at us.ibm.com>>>> "Hastings, Tom N" <hastings at cp10.es.xerox.com> on 01/07/99 07:35:31 PM
>> To: jmp <jmp at pwg.org>
> cc: Harry Lewis/Boulder/IBM, Ron Bergman <rbergma at dpc.com>
> Subject: RE: JMP> Ballot on Xerox Job MIB comments
>>>>>> Harry,
>> I think that we (Xerox) can agree to forwarding the JMP MIB to the IETF now
> with the System Group being entirely removed as you and Ron have suggested.
>> We can also agree that we should make the second EXTERNALLY published
> version of the MIB AFTER an interoperability test and any updates needed
> from the interpretability test, as you proposed. Currently, the
> interoperability test is anticipated to be some time next summer.
>> However, we need to be able to build something with the System Group in it
> NOW, rather than waiting until after the interoperability test (next
> summer). So could we also produce NOW an INTERNAL PWG working draft with
> version 2.0 that does have the MANDATORY System Group in it? This internal
> PWG working draft would NOT be forwarded to the IETF for publication as an
> Information RFC until after the interoperability test and any updates that
> the interoperability tests show were added.
>> Thus the interoperability test would be for both version 1.0 products
> without the System Group and for version 2.0 products with the MANDATORY
> System Group. It is straightforward for any testing client software to
> tell
> the difference between the two by just querying the System Group and
> getting
> back no such object or not.
>> So for process as a result of the PWG Last Call, after Maui I would forward
> the current JMP MIB document with the OPTIONAL Mirror Table but without the
> System Group to the IETF as an Internet-Draft. Ron prefers that we call it
> 1.0 (with a January 1999 date), rather than 1.3 so that we don't confuse
> the
> IETF. They have only seen the 1.0 spec from February 1998. If it looks
> ok,
> Ron will then request the RFC Editor to publish it as an Informational RFC.
>> Secondly, next month I would take the current 1.3 version with the
> MANDATORY
> System Group and rename it to be version 2.0. Then implementers that want
> to can implement it for the Interoperability Tests. However, it would NOT
> be forwarded to the IETF until after the interoperability test.
> Implementers at the interoperability test could bring 1.0 or 2.0 conformant
> products.
>> If new attributes are proposed and agreed to, I can add them to both the
> 1.0
> and 2.0 specs until we make version 2.0 an EXTERNAL spec as published by
> the
> IETF and an Informational RFC. After that we only need to keep maintaining
> the 2.0 spec.
>> How does that sound?
>> Thanks,
> Tom
>> >-----Original Message-----
> >From: harryl at us.ibm.com [mailto:harryl at us.ibm.com]
> >Sent: Thursday, January 07, 1999 10:56
> >To: jmp at pwg.org> >Subject: RE: JMP> Ballot on Xerox Job MIB comments
> >
> >
> >
> >
> >A few days ago, I stated my lack of support in Ron's ballot request...
> >
> >>I am requesting a formal ballot regarding the recent request
> >>from Xerox to expand the object jmSystemAttributeSupport to
> >three objects.
> >
> >I should elaborate that I do not object to the particular
> >jmSystemAttributeSupport changes proposed by Xerox but to the
> >entire notion
> >of submitting an updated version of the Job MIB to the IETF if
> >that version
> >has new mandatory objects which were not part of the agreed
> >PWG standard,
> >closed months ago, and which is the basis of all prototypes and
> >implementations thus far.
> >
> >The existing PWG Job MIB standard (v1) has been intended for
> >submission to
> >the IETF for consideration as an RFC. (It has been debated whether this
> >would
> >be standards track with the Printer MIB, Informational,
> >Experimental etc...
> >but, nonetheless, the Job MIB would be submitted).
> >
> >Recently, there have been proposals, resulting from
> >prototypes, which have
> >been discussed and agreed to be improvements. I agreed to the
> >addition of
> >an optional "mirror table" as part of the IETF submission
> >because it was
> >optional. Later there was the notion of a "system table" to
> >differentiate
> >Job MIB versions. This would be a new mandatory table.
> >Finally, there are
> >proposed modifications in the details of the objects in this table.
> >
> >While I welcome and have been very willing to discuss spec
> >changes to the
> >standard, I feel the PWG process recognizes a v1 PWG Job MIB
> >standard which
> >is in PWG maintenance mode. I believe this should be
> >considered the most
> >stable version and the one that is published to the IETF. A
> >SECOND updated
> >PWG Job MIB standard is entirely feasible but I don't believe
> >it is valid
> >to publish new mandatary objects in the first EXTERNAL version of the
> >standard.
> >
> >I highly recommend at least one coordinated interoperability
> >test prior to
> >declaring the second major version of the Job MIB standard.
> >
> >Harry Lewis - IBM Printing Systems
> >harryl at us.ibm.com> >
> >
>>>>