JMP Meeting - 1/8/97 - Albuquerque Review of IETF Charter The IETF has combined PMP and JMP groups into one “Printer MIB Working Group”. The new IETF charter will make it clear that the MIBs are distinct and separate. The JMP will petition for a proposed draft in August - Submit to the IESG - Takes 6 months for the Editor to build a draft at that time. Issues from the IETF JMP Presentation Quantify the “Busy” requirement - Estimating “time to completion” has been an intractable problem in other working groups - How busy is the printer? - How much data vs. how much time - Percent vs. discrete representation - Accuracy may vary. Metrics are intended to give an idea. - Grocery or Bank line analogy. You can choose the shortest line but it may take you longer - Because we can’t tell exactly, are we better off without this information? No, the information is still useful - Current metrics, number of jobs, size of each job. - Action - Paragraph telling how to estimate least busy printer - Tom Hastings How to associate the job with the printer when there are multiple printers to a server? - hrDeviceIndex - Resolved (initial statement by Ron Bergman) - Separate queue for each printer or “print farm” scenario - Printer MIB instance index is not the same as hrDeviceIndex - need to fix name. - For a job printing on a particular printer, mgt. app needs to know hrDeviceIndex for the printer handling that job to determine status of that job. How and when is Job information removed from the Completed group? - Agent takes it out according to internal policy OR - Accounting application sets status in the Job MIB to “REMOVE” marking that job as a candidate for removal by the agent. - Have a r/w policy object Printer could stop accepting jobs if table was full as one policy Printer could delete jobs from the table as needed as another policy - Action - Send alternatives for removing jobs to the e-mail reflector - Tom Hastings Confusion about “requested” vs. “used” in the Resources group - Resource Enums Requested Used Requested/Used (number of sides) - Action - Resources that are requested/used need to be separated or clarified during the line by line review. Refine criteria as to what belongs in what group and justify. - Difficult to understand why things are partitioned the way they are (IETF). - Action - Need clarifying text - Tom Hastings What is required to be implemented in the Resources Group - Tom has updated document to require only 3 - all to review Tom’s proposal - Action Interpreters (requested/used) Sheets completed Processing time. - These all seem to be more accounting than end-user. Is that the goal? Measure jobs in Kbytes to avoid the 64 bit counter problem - Agreed since SNMPv1 does not have 64 bit counter. - Round UP so less than 1K does not = 0. - Round (Octets completed) down until the job is completed. - Rounding method can be a choice. Do we really need the complexity of two methods for rounding? Define bindings to the Printer MIB - Two ways for the management app to find the printer Look at printer name in the job MIB Maps to administrative assigned name in the Printer MIB or hrDeviceID hrDeviceindex jmDeviceIndex will = 0 if there’s no associated Printer MIB - Agent for the Job Monitoring MIB is either in the printer or in the server, not both places. Jeff Case volunteered to find models for directed trappings - Job Monitoring MIB has no trapping at the moment - polling only. - Potentially lots of clients and accounting apps - traffic - SNMPv2 - directed trapping (party MIB) - died - RMON came up with directed trapping scheme which set the precedence for a MIB to have it’s own directed trapping mechanism - We don’t need to do same as RMON. - Could send traps only to clients that have outstanding jobs. - Do we want to tackle Traps and/or notification? YES More clients - polling worsens as things get busy. Trap may never arrive. With traps, you would still poll at more relaxed rate in case traps get lost. Does SENSE solve the problem? Why hasn’t SENSE focused on Traps (apparently). Or has it? What other methods exist for registering and sending notification? As an alternative, can we define a standard way to register for traps? Currently it’s all vendor specific for the printer MIB. Any work in this area should be coordinated with the Printer MIB. Clarify that there are only 36 objects in the whole MIB - 36 Mandatory - 7 conditional mandatory - Need to remove Resources Group? Issue initially raised by Jay Martin. Consensus reached at meeting. NO do not remove the group. Ron indicated that Jay is now in sync with this consensus although Jay was not present at the meeting. HP Job Monitoring MIB Presentation Bob Pentecost presented the HP Laserjet 5si Mopier Enterprise Job MIB Netware solution. Bob’s presentation was labeled HP proprietary but the group was assured this information was not “HP Confidential”. Bob plans to post the presentation to the JMP FTP site if possible. The PWG, JMP wants to thank Bob and HP for taking this initiative. We hope more participants will openly share their private job monitoring implementations in an effort to correlate and drive the set of JMP job objects to closure. Client Software Job Monitor - Show all jobs or only your jobs - Show only completed jobs or also jobs in process. - Job name, status, owner, size - Status icon - Highlight job and click on properties to get: Status - Pages printed, copies, percent gauge (based on bytes processed), destination. Queue - Which Server, Queue name, jobs currently in that Queue. - Tool looks at Queue on the server as well as jobs in the printer - Essentially a Queue on the server and one in the printer. DocWise - Indicates n-up etc. - Where job ended up Object Comparison Bob presented side-by-side lists of HP and JMP Job monitoring objects - No attempt to correlate - Obtain copy of presentation for details. HP can trap every time the Current-Job_Parsing-ID changes (Equiv. of adding a row). This could be a problem if the job MIB crosses printers. Outputbin can be logical or physical to accommodate configurations such as linked bins. Job INFO Objects return job specific info which has been added to the clients print job via PJL, after submission, by the de-spooling process. PJL could also be added by Server or Client anywhere among the way. JetDirect card pre-pends PJL and some information from the server. Attributes can’t be modified once pre-pended. PJL extension for job attribute = xxx. Where do these attributes come from? Jet direct card uses info it gets from the Novell system and merges it in. - Time job was submitted to the server - Attributes used to identify and correlate print job Source I/O (string) Always Netware Queue Server in Novell environment SourceServerName SourceQueue JobID. (when job is submitted to the server) - Mgt. app uses this info to determine which row in the job table to look at. Then manages off the “local id”. - Some of the attributes won’t be filled in for other environments. Jet direct card is in printer but pulls job from Novell system and knows this information so appends it prior to going across the MIO slot. In other environments, this could be PUSH and added by the driver. Netware API’s used to talk to the Netware server - since no SNMP agent there today. Discussion on HP Job MIB HP can’t depend on all file servers providing all the info so they feel they have to get the job information from the printer. Debate about the fact that it seems HP has a management path both to the server and the printer. This looks like a model we deleted (2B). JMP Proposal - eliminate (JMP) path from server to printer (SNMP). Mgt. apps, however, can get information (via SNMP) both from server and printer agent. This way, eliminate upstream/downstream etc. How about an object in the server saying he implements a proxy and should be the focal point (Warp server model). What about printers driven by multiple servers or no server? UNIX systems - less information (unknown), but all jobs are in the job table. IPP should solve the problem of sever vs. printer but legacy systems may or may not be completely resolved in terms of total printer and print queue status. Put configuration 2B back in, but it needs work - should not hold up current work. End of HP Job MIB topic Review of new JMP Job ID Objects Ron - proposed revision - Remove jmClientID, JobUpStreamID, jmJobCurrentID and jmJobDownstreanID - Add jmJobIdName, jmJobIdNumber - Approved User (client) management app “talks” to the job MIB agent. That agent can be in the server or the printer. For the agent to be in both server and printer would require us to re-write the JMP spec. jmJobIDName (string) and jmJobIDNumber (Integer) - use either or both. These are assigned on the client (submission) side. JodIDName can be Queue name. Why not just point to the prtChannelInformation? If you have hrDeviceIndex and prtChannelIndex then you’ve got it. If user submits job to server, how do they determine which printer the job went to? Management app has to be able to find the right printer. How? - Server can be queried for printer assigned - how long must the server keep the information? - Ideally, Pserver won’t delete the job from the server until it knows the job is printed. - Job started trap - how do we know who to send trap to? - Action - map to existing print subsystems - Unassigned Action - Poll all the private job MIB implementations (voluntarily). - Submit your analysis to the DL by 1/17 - Conference call 1/23 - appx 1,2,3,4 o’clock (set up by Lloyd and or Ron) - Also need OS participation - Goal - post (your private MIB objects vs. JOB MIB) by end of next week. - Tom will make a table with all JMP objects and folks can edit in their comments. - Analyze objects as well as data types. - Sign-up to analyze current job-monitoring implementations Lexmark - Lloyd Young OS/2 Warp - Keith Carter IBM - Harry Lewis QMS - Mabry Dozier HP - Bob Pentecost DataProducts - Ron Bergman NDPS - Open NT - Open Xerox - Tom Hastings or Angelo Caruso Unix’s - Open Mapping of job id’s to protocols will actually become part of the JMP spec. Is it conforming to implement the job MIB but not the printer MIB? Is it conforming to implement either job or printer MIB to not implement hrMIB. We agreed, if doing job MIB in printer then printer should do printer MIB and so should do hrMIB We agreed if doing job MIB in server no need to do printer or hrMIB. Review of Recommended Changes to JMP Objects Add object for correlation with hrDeviceIndex - Done Replace jmCompletedIndex with jmJobIndex - Withdrawn (some printers can print jobs out of sequence) Remove jmSourceChannelInformation - Done. - May need to add similar object for Sever - Tom Hastings. Project Plans For now, not doing MIF. Draft MIB schedule - Tom will add today’s revisions, accept all outstanding revisions, convert to MIB and publish for review - Keep 2B as crossed out for now - Line-by-line review - who on first draft? Keith Carter Bob P HP Ron DP Harry Tom Hastings - MIB will be ready for review in 2 weeks - Teleconferences used for line-byline review - Attempt updated draft for next meeting. - End of March - post Internet draft for discussion at meeting in Memphis. JMP object mapping to job submission protocols - JobIDNumber and Name - How do these correlate to existing job submission protocols. Same people assigned. Other items to be included in the MIB document? Open. Table of Issues 1. Are the definitions of job and document OK? Closed - OK. 2. Change terms from printer to device? Use DEVICE and explain up front what it refers to. 3. How are T(63) strings localized? Follow the printer MIB method whereby the administrator sets overall localization. The printer should never be expected to “translate” anything that flows TO it! Processing Message and Resource Name were the only attributes we could find in a quick review that might be concerns. The printer cannot be expected to ever translate from one language to another. We concluded NONE 4. How is code conversion done for strings, if at all? Not an issue that we are going to address - typically handled by site policy. Datatype will be Octet String (63) 5. Is the name jmMIBInstanceIndex OK? Reason for this index is for disjoint sets of jobs vying for disjoint sets of printers Ex. One server, 2 queues So call it jmJobSetIndex? Also proposed jmJobServerIndex and jmJobQueueIndex How to distinguish separate printer devices? Leave it as jmJobSetIndex now. 6. Do we really need the jmJobDownstreamID? Eliminated jmJobDownstreamID 7. Should jmJobTypes be something that a job submitted can specify? Not an issue we care to address 8. Is the parent job type the or of the child jobs? Not an issue we care to address 9. What is the difference between jmJobName and jnClientID? No longer an issue 10. Combine jmJobTotalOctestHight and Low and count by K? Done 11. Make jmJobStateReasons a bit string? Will run out of reason space Yes Octet string 0-63 Not SNMPv1 compatibly 12. Combing jmJobOctectsCompletedHIgh and Low and count by K? Done 13. Add jobTotalPagesSpooled, jobTotalPagesSentToDevice, and jobTotalPagesPrinted? jobTotalSheetsPrinted is already there. Add jobTotalPagesSentToDevice Add jobTotalPagesSpooled Also add (based on HP presentation) jobTotalPagesProcessed 14. Always have separate resource types for requested versus used. PDLs - No - Value is 0 if not used Fax phone numbers - Do not Separate - Change to Fax phone number (singular) - Value is 0 if not used - Requires greater than 63 bytes because of Unicode 15. OK to use the string names, instead of enemas for the printer interpreter lang. family? Change data type to enum and don’t represent level and version, necessarily, unless these become registered by the printer MIB later. In general, level and version information is too granular for the context of this application.