WIMS> WIMS Concall 17 January 12 Noon EST

WIMS> WIMS Concall 17 January 12 Noon EST

WIMS> WIMS Concall 17 January 12 Noon EST

William A Wagner wamwagner at comcast.net
Tue Jan 15 11:21:51 EST 2008


Next WIMs/CIM concall is Thursday 17 January at  12 Noon EST.

Dial In: 1-866-365-4406
Toll #: 1-303-248-9655
Passcode: 2635888# 

Agenda 

1.	Review of the Minutes of the 10 January
ftp://ftp.pwg.org/pub/pwg/wims/minutes/cim_080110.pdf
2.	Consideration comments to the Imaging System State and Counter MIB
v2 (see below)
  ftp://ftp.pwg.org/pub/pwg/wims/wd/wd-wimscountmib20-20080107.pdf
We want to get WG consensus so that this can be posted for PWG last call
before Feb F2F. Please look through the document, post comments or have some
ready for the meeting.
3.	CIM Activities

Thanks,

Bill Wagner



1. Line 1582 onward- Usage information/notes for times gives three possible
derivation sources.  As discussed last week, the three  possible derivations
(sysUpTime, hrSystemUpTime and printer-up-time in IPP/1.1 Model) do not all
necessarily correspond to time that the service is up, although the
distinction may not be significant. My suggestion was that only sysUpTime be
referenced, since that is virtually guaranteed to be supported and would
ensure consistent implementation. But this should be discussed.

2. Line 1872 - The usage description for  icMonitorMemoryAllocWarnings,
taken cold, seems a bit off. 
        "Usage:  This counter is intended to support increasing available
        memory on an Imaging System before job failures occur."
If a usage comment is needed at all, I would suggest something like:
	"Usage:  This counter provides a measure the safety margin in memory
capacity, to indicate that inadequate Imaging System memory capacity should
be increased before job failures occur."

3. Line 1901 - A similar comment with regard to
icMonitorStorageAllocWarnings

4. Line 2622 and 2640 - I think I have a problem with the usage information
in icTrafficInputMessages and icTrafficOutputMessages.
	"System input messages may be mapped from ifInUcastPkts"
In the Counter Spec, we defined 
"Message - A single application protocol request or response (that may
consist of multiple application protocol data units) received or sent by
Service such as EmailIn or FaxOut."

Even neglecting the question of how one associates ifInUcastPkts to a
specific protocol, it does not strike me that there is a clear correlation
between message and unicast packets.

5. Line 3876: two section breaks?





More information about the Wims mailing list