Tom (and Ang),
I disagree with Joe that these extra tables "go a long way" towards solving
our problems. I only see them solving a narrow problem of being able to
acquire a column of data (the same attribute for multiple jobs). This in
not what we do in the normal course of monitoring a single job. We acquire
rows of data and the mirror table does nothing to help that problem. The
support bit vector provides a small degree of help in that we know for sure
which attributes NOT to look for. It is no guarantee that a given attribute
actually does exist though.
Mike
> -----Original Message-----
> From: Filion, Joseph L
> Sent: Friday, June 25, 1999 2:00 PM
> To: Elvers, Mike
> Subject: FW: JMP> FW: Document Action: Job Monitoring MIB - V1 to
> Informat ional
>>>>> -----Original Message-----
> From: Filion, Joseph L
> Sent: Friday, June 11, 1999 8:18 AM
> To: Hastings, Tom N; Filion, Joseph L; Caruso, Angelo
> Cc: jmp
> Subject: RE: JMP> FW: Document Action: Job Monitoring MIB - V1 to
> Informat ional
>>> Tom (and Ang),
>> Yes, the attribute support bit vector and the mirror table do
> go a long way towards solving our problem. I guess I
> understood Angelo's proposal to mean that a description of
> the structure of the model would be written independent of an
> instance of that model; so I wouldn't expect to see a
> description of the Job Monitoring MIB V2 in that description.
> Would you think the paper being proposed would include
> descriptions of the attribute vector and mirror tables?
>> JLF
>> -----Original Message-----
> From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
> Sent: Thursday, June 10, 1999 2:55 PM
> To: Filion, Joseph L; Caruso, Angelo
> Cc: jmp
> Subject: RE: JMP> FW: Document Action: Job Monitoring MIB - V1 to
> Informat ional
>>> Joe,
>> What about the Job Monitoring MIB V2 that has the attribute
> support bit
> vector and the mirror table? Don't they solve your problem?
>> I would assume that such a paper would also include the
> description of Job
> Monitoring MIB V2 as well.
>> Thanks,
> Tom
>> -----Original Message-----
> From: Filion, Joseph L
> Sent: Thursday, June 10, 1999 11:51
> To: Caruso, Angelo; Hastings, Tom N
> Cc: jmp
> Subject: RE: JMP> FW: Document Action: Job Monitoring MIB - V1 to
> Informat ional
>>> Tom and Ang,
>> Maybe publishing a separate stand-alone document describing
> the new model
> would help (or would have helped), but let's not loose sight
> of some of the
> real issues with the model itself. One issue that continues
> to bother me is
> if you want to get all the information that a printer knows
> about a job it
> is real easy to get from a MIB that uses this model; but if
> you want to get
> two or three specific attributes for all of the jobs, it is
> very difficult
> to do efficiently with this model. Let's face it, we can all think of
> management side applications that want to do exactly this,
> and they cannot
> be done without retrieving every bit of data from the table. I am not
> saying that this model is not without its merit; I would just
> like to make
> sure that all the pros and cons are on the table.
>> Thanks,
> JLF
>> -----Original Message-----
> From: Caruso, Angelo [mailto:Angelo.Caruso at usa.xerox.com]
> Sent: Thursday, June 10, 1999 8:54 AM
> To: Hastings, Tom N; jmp
> Subject: RE: JMP> FW: Document Action: Job Monitoring MIB - V1 to
> Informat ional
>>> Tom,
>> Perhaps the IETF is taking issue with the fact that we invented a new
> information model, built on top of SNMP/SMI, and then just
> went ahead and
> implemented the first instance of this new model, all in one
> MIB module.
> Perhaps we should have published a generic definition of the
> new model first
> as a stand-alone document, and then published the JMP MIB as
> an example
> implementation.
>> Thanks,
> Ang
>> -----Original Message-----
> From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
> Sent: Wednesday, June 09, 1999 7:29 PM
> To: jmp
> Subject: JMP> FW: Document Action: Job Monitoring MIB - V1 to
> Informational
>>> The PWG Job Monitoring MIB has been approved by the IESG to
> be sent out as
> an
> Informational RFC. However, the IESG doesn't approve of our
> modeling of
> management information. By this I assume they mean the
> attribute mechanism
> that we invented to handle the great variability between
> implementations.
>> They also don't recognize the PWG as a standards making body
> according to
> the note.
>> Tom
>> -----Original Message-----
> From: The IESG [mailto:iesg-secretary at ietf.org]
> Sent: Wednesday, June 09, 1999 3:02 PM
> Cc: RFC Editor; Internet Architecture Board; pmp at pwg.org> Subject: Document Action: Job Monitoring MIB - V1 to Informational
>>>>> The IESG has approved the Internet-Draft 'Job Monitoring MIB - V1'
> <draft-ietf-printmib-job-monitor-07.txt> as an Informational
> RFC. This
> document is the product of the Printer MIB Working Group. The IESG
> contact persons are Keith Moore and Patrik Faltstrom
>>> Note to RFC Editor:
>> The IESG requests the following text be included as an IESG Note:
>> This MIB module uses an unconventional scheme for modeling
> management information (on top of the SNMP model) which is
> unique to
> this MIB. The IESG recommends against using this document as an
> example for the design of future MIBs.
>> The "Printer Working Group" industry consortium is not an IETF
> working group, and the IETF does not recognize the Printer Working
> Group as a standards-setting body. This document is being
> published
> solely to provide information to the Internet community regarding a
> MIB that might be deployed in the marketplace. Publication of
> this document as an RFC is not an endorsement of this MIB.
>