Subject: JMP> Instantiation

From: Harry Lewis <[email-masked]>
Date: Thu, 29 May 1997 10:10:28 -0400

I had posted this topic earlier but I believe I only saw a response from one
person (Jay) who agreed with me that it does not make sense to instantiate
deviceAlertCode as soon as a job is "pending" because the device may never have
an alert while producing that job. This may have become a mute point following
our discussions about "printer-stopped" state etc.

But, I still think we need to clarify the thread which was weaving during
SanDiego which basically said... "mandatory attributes must be instantiated
when the job enters pending state". One of the key attributes for which this is
desired is jobOwner. This is due to the fact that "out of band" monitors will
rely heavily on job owner for job identification.

But, what should we do about multi-valued attributes like output bin? When the
job is pending, there is no way to determine how many instances of output bin
there will be!

I think we should investigate what is behind the "instantiation" rule and ways
to alleviate the problems it may
cause. Basically, I think we are trying to define a list of objects or
attributes that will never cause a GET (Varbind List) to fail. Correct? This
would allow the monitoring application to "pick and choose" among these
"mandatory, instantiated" attributes using an SNMP GET.

For the Job Table, I agree that a GET on a row should reliably return a value
for all objects in that row. I don't think it is necessary to achieve this
level of instantiation, however, for the Attribute Table because, the
monitoring application can use GET NEXT there, which will skip over any
non-instantiated attributes.

Based on this, I suggest we drop the "must be instantiated" rule as it relates
to any attributes in the Attribute Table.

Harry Lewis - IBM Printing Systems

---

From: "Caruso,Angelo" <[email-masked]>
Date: Fri, 30 May 1997 05:42:37 PDT

Harry,

I agree completely. Good MIB design should not center around 
 guaranteeing that GETs always succeed. This is why some SNMP protocol 
 guru's (Jeff Case, for example) preach that GET is evil, but GET NEXT 
 is good. 

Angelo

----------
From: [email-masked]
To: [email-masked]
Subject: JMP> Instantiation
Date: Thursday, May 29, 1997 12:00AM