Web-based Imaging Management Services: WIMS> RE: Brief minut

WIMS> RE: Brief minutes from WIMS 8 June 2005

From: Richard_Landau@Dell.com
Date: Thu Jun 09 2005 - 16:17:37 EDT

  • Next message: McDonald, Ira: "WIMS> RE: Brief minutes from WIMS 8 June 2005"

    Bill, thanks for the historical perspective. I appreciate that, having
    been away from this business for a few (apparently interesting) years.
     
    My questions really stemmed from two fundamental concerns. (I will
    write real requirements later at some length.)
     
    1. I found it very difficult to grasp the document as it stands. I
    came away with the impression that only scheduled operations are
    supported, and I think that anyone but the most serious reader would
    make similar mistakes. Introductory information that describes usage
    models and message exchange sequences would be very helpful in this
    regard.
     
    2. I appreciate the need for a fleet management protocol, but not to
    the exclusion of other, simpler models. Two years ago when WIMS was
    conceived and written, web services were exotic and heavyweight. No
    longer true. Web services will be the new SNMP, eventually, in endpoint
    devices. They will be just another transport mechanism for the same
    management information in the device.
     
    Didn't early SNMP specs talk about proxy implementations? I haven't
    seen any new SNMP proxy implementations lately. Web services will
    follow the same path: there will be early proxy implementations to front
    for legacy devices, but they will migrate into endpoint devices -- and
    much more quickly than SNMP did.
     
    I would like to see the WIMS model *extended*, not changed, to embrace
    modest groups of printers/MFDs managed from within, which is still a
    much more common deployment in our experience. To support that model, I
    think we need to consider extensions such as polled management, event
    notification, service advertising, and resource discovery. Scheduled,
    reverse-communications (benign Trojan horse) operations suitable for
    fleet management can be entirely layered on top of such a simpler model,
    I believe.
     
    Enough tirade for one day. I apologize for its length.
     
    I cannot make the call this coming Wed., 6/15, sorry; out of town.
     
    rick
     
     

      _____

    From: Harry Lewis [mailto:harryl@us.ibm.com]
    Sent: Wednesday, June 08, 2005 22:59
    To: wamwagner@comcast.net
    Cc: McDonald, Ira; Landau, Richard; thrasher@lexmark.com; wims@pwg.org
    Subject: Re: Brief minutes from WIMS 8 June 2005

    Excellent response, Bill. I agree with getting the current Counter Spec
    (and WIMS... if possible) to CS w/o too much perturbation and building
    (into Enterprise mgt) from there... UNLESS... someone has some
    powerhouse recommendations that generate a great deal of new interest.
    ----------------------------------------------
    Harry Lewis
    IBM STSM
    Chairman - IEEE-ISTO Printer Working Group
    http://www.pwg.org
    IBM Printing Systems
    http://www.ibm.com/printers
    303-924-5337
    ----------------------------------------------

    wamwagner@comcast.net

    06/08/2005 05:46 PM

    To
    "McDonald, Ira" <imcdonald@sharplabs.com>, Harry
    Lewis/Boulder/IBM@IBMUS, "McDonald, Ira" <imcdonald@sharplabs.com>,
    thrasher@lexmark.com, Richard_Landau@Dell.com
    cc
    wims@pwg.org
    Subject
    Re: Brief minutes from WIMS 8 June 2005

            

    Rick's questions are interesting, and to an extent reflect the sort of
    capability that HP wanted to include in WIMS, before they withdrew.
      
    The answers to the questions are quite simply that WIMS was intended for
    fleet management, and was specifically aimed at increasing the
    efficiency and potential market of companies like Danka and Ikon (and
    the service arms of several MFD manufacturers), which account for a vast
    number of multifuntion products in place today. Indeed, it appears that
    most small and midsized companies and indeed many large enterprises do
    not buy or maintain MFD products with internal resources.
      
    It was recognized that some of the capabilities included in WIMS would
    be useful for enterprise level management as well, and some features
    were added to support this application. With HPs sudden withdrawal from
    what had been active participation, the remaining members of the WG
    decided to concentrate on the original scope.
      
    If Dell or any other companies would like to expand the WIMS scope, I am
    sure the WG would be happy to support this. However, I want to follow
    through with the objective of getting the basic WIMS ideas in some
    recoverable form, probably a candidate specification. The additional
    features could be addressed by a subsequent document.
        
    It has turned out that, for whatever reason, we have been unable to get
    active participation from those companies that would most directly
    benifit from WIMS. On the other hand, manufacturers appear more
    interested in pursuing private solutions with the intent of locking
    customers into using their products. It would seem that a company that
    sold products OEM'ed from multiple manufacturers would prefer a standard
    solution. At any rate, it is with the belief that a standard means of
    facilitating third-party fleet management is needed and that this need
    will be recognized eventually that we wanted to document the
    fleed-management WIMS.
      
    Because third-party fleet management concerns are not generally trusted
    with anything except the minimum information necessary to bill and
    maintain their equipment, many of the features that an enterprise
    management capability would want would need to be disabled for
    third-party fleet management.
      
    In direct answer to Rick's questions:
      
     (1) Why is the WIMS Protocol only explained in terms of the
    > Schedule and fleet management / firewall traversal?
     - In facilitating third party management, particularly for small
    sites, the intent was to utilize the existing network facilities and
    require a minimum installation activity. The approach taken was to use
    existing web access capability (with whatever protection the site
    normally provides for).
    - The schedule approach reflects the premise that all communication is
    to be initiated by from the site. This supports both the use of an
    unaltered web access facility at the side, and the requirement that the
    site retains control over what what the manager has access to.

    >
    > (2) Why isn't there a second top-level diagram showing the use
    > of WIMS _within_ an enterprise, specifically _without_ a
    > proxy (i.e., small network of WIMS-capable imaging systems)?
      
    -This was one of the scenarios that was proposed by HP. See
    ftp://ftp.pwg.org/pub/pwg/wbmm/white/Use_Cases_7.pdf
    <ftp://ftp.pwg.org/pub/pwg/wbmm/white/Use_Cases_7.pdf> , the basis for a
    requirements document, but now almost two years old. In refocusing the
    spec to the original intent, the operations that might be desirable to
    support this mode were dropped. Perhaps we should also have dropped any
    reference to the use of WIMS for internal management, but it was felt
    that WIMS does include features useful for this mode as well.

    >
    > (3) For WIMS within an enterprise, the model of direct admin
    > preconfiguration of lots of WIMS Agents doesn't work.
      
    - WIMS specifically did not include either service advertizing or
    discovery. The third party fleet model, such capabilities would be a
    security risk. The intent was that the right to obtain information from
    a service must be initiated at the site; indeed, all communication must
    be initiated from the site. For internal management, other protocols
    exist to allow discovery. SLP and LDAP might be good choices. UPNP would
    seem to be inapplicable.
    >
    > (3a) What protocols for service advertising (SLP, UPnP)
    > should a WIMS Agent use?
      
    >
    > (3b) What protocols for service discovery (SNMP Ping, LDAP,
    > DNS-SD, UDDI) should a WIMS Manager use?
    >
    > (4) How can a WIMS Manager immediately begin management of a
    > WIMS Agent (i.e., where is the Management Interface operation
    > 'BeginManagement')?
    - Again, the premise is that a manager cannot begin management of a
    device until that device has directly or indirectly (through a proxy)
    granted the manager that right.
      
    Bill Wagner, Chairman, WIMS
    -------------- Original message --------------

    > Hi,
    >
    > [This just _bounced_ from 'wims@pwg.org' - huh?]
    >
    > Only Rick Landau (Dell) and I called in today. While we waited
    > for ephemeral others, Rick asked some questions about the WIMS
    > Protocol itself:
    >
    > (1) Why is the WIMS Protocol only explained in terms of the
    > Schedule and fleet management / firewall traversal?
    >
    > (2) Why isn't there a second top-level diagram showing the use
    > of WIMS _within_ an enterprise, specifically _without_ a
    > proxy (i.e., small network of WIMS-capable imaging systems)?
    >
    > (3) For WIMS within an enterprise, the model of direct admin
    > preconfiguration of lots of WIMS Agents doesn't work.
    >
    > (3a) What protocols for service advertising (SLP, UPnP)
    > should a W! IMS Agent use?
    >
    > (3b) What protocols for service discovery (SNMP Ping, LDAP,
    > DNS-SD, UDDI) should a WIMS Manager use?
    >
    > (4) How can a WIMS Manager immediately begin management of a
    > WIMS Agent (i.e., where is the Management Interface operation
    > 'BeginManagement')?
    > (This assumes that an LDAP or Kerberos user identity (e.g.)
    > already exists for both the WIMS Manager and WIMS Agent.)
    >
    > Good questions that need clear answers in the spec.
    >
    > I'd like to note that Rick feels that Dell wouldn't consider
    > deployment of WIMS for enterprise service management based on
    > the Schedule-centric fleet management operations sequences.
    >
    > Rick volunteered to write paragraphs describing solutions to
    > some of the above questions for addition to the spec. At present,
    > Rick can't volunteer to be the principal editor of the WIMS spec.
    > > In the interests of encouraging actual deployment of WIMS, I
    > agree with Rick that the spec should support both models
    > (enterprise and fleet management)?
    >
    > Same time next week - Wednesday 15 June
    >
    > Call-in US Toll-free: 1-866-365-4406
    > Call-in International/Toll: 1-303-248-9655
    > Participant Identification number: 2635888#
    >
    > Cheers,
    > - Ira
    >
    >
    > Ira McDonald (Musician / Software Architect)
    > Blue Roof Music / High North Inc
    > PO Box 221 Grand Marais, MI 49839
    > phone: +1-906-494-2434
    > email: imcdonald@sharplabs.com
    >
    > Ira McDonald (Musician / Software Architect)
    > Blue Roof Music / High North Inc
    > PO Box 221 Grand Marais, MI 49839
    > phone: +1-906-494-2434
    > email: imcdonald@sharplabs.com
    >
    > -----Original Message-----
    > From: Harry Lewis [mailto:harryl@us.ibm.com]
    > Sent: Wednesday, June 08, 2005 3:33 PM
    > To: imcdonald@shar! plabs.com; thrasher@lexmark.com;
    wamwagner@comcast.net;
    > Richard_Landau@Dell.com
    > Subject: Sorry I missed WIMS call today - will be available next week
    >
    >
    >
    > Sorry, after posting my warning to you folks... I ended up in a
    strategic
    > customer briefing that I just could not escape from.
    > I have had to postpone my vacation for business reasons which should
    make me
    > available for a call on the 15th (I'd previously begged off that one).

    > Was there a call today? Minutes?
    > ----------------------------------------------
    > Harry Lewis
    > IBM STSM
    > Chairman - IEEE-ISTO Printer Working Group
    > http://www.pwg.org
    > IBM Printing Systems
    > http://www.ibm.com/printers
    > 303-924-5337
    > ----------------------------------------------



    This archive was generated by hypermail 2b29 : Thu Jun 09 2005 - 16:17:43 EDT