WBMM> Couple Questions about Schedules

WBMM> Couple Questions about Schedules

WBMM> Couple Questions about Schedules

McDonald, Ira imcdonald at sharplabs.com
Wed May 5 10:09:42 EDT 2004

I agree again with all of Bill's points and reasoning.
I am strongly opposed to introducing the concept of
'negotiation' into Schedule transfers.  It doesn't exist
in any other NMS architecture I've seen.  
In WBMM/WIMS, the Manager says "do this" (via an 
embedded Action in a Schedule).  And the Agent either 
replies "fine by me" (with SendReport) or "Manager not 
authorized" (with SendAlert).
I think it's important that SendReport _never_ be used
to report an Action failure.  Only use SendAlert.
- 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 at sharplabs.com 

-----Original Message-----
From: Wagner,William [mailto:WWagner at NetSilicon.com]
Sent: Tuesday, May 04, 2004 10:43 AM
To: Harry Lewis; wbmm at pwg.org
Subject: RE: WBMM> Couple Questions about Schedules

This brings up  the question of  addressing policy, one of the issues that
remains outstanding  in the current  spec and one of  the aspects in the
responses   to operations.  We have touched  on it in the emails.
Certainly,  the  agent or the managed  entity operating though the agent
must  be able  to reject certain actions. (I had not  considered rejecting
certain values, such as two frequent  or  too  large... I think that is a
bit more complicated).  There  was  never any intent to negotiate  a
schedule. I think  the last suggestion  from  Ira was  that, in the case  of
an action that is prohibited  with respect   to a particular  managed
entity by site policy, the report dealing with that action  would   indicate
that  the action was disallowed. That is, the  response to  the schedule
does not  indicate  that an action is disallowed.  Rather, the report  on
the action would indicated that is  is disallowed, just as it may indicate
that the managed entity was down, or  was unable  to perform  the action
for  some  other reason..
 If  this  were a recurring action, the recurring  report  would  indicate
it was  disallowed.   The management station,  operating through the manager
could then modify the schedule,  but  it  does  not need to.   That is,
there may be a  generic schedule rather than a custom  schedule  developed
for  each   managed entity.
We would need  to consider whether we need to address  agent  rather than
managed  entity policies. That  would address  operations rather than
actions. My  first reaction is that  this is not necessary since the
Management Station  is a trusted and authenticated manager.  However,  it is
something worth discussing.  The simple solution is  that the agent  sends
reports  according to  it own  limiting policy if  the manager  demands
anything  exceeding that limit. What  would happen then is that the manger
would report the agent  for  being  non-responsive,   and  it would need to
be dealt with  outside  the protocol. With respect  to too many  elements, I
think any  action must have a response. If the action is not performed, or
all  elements identified  in the action are not  acted on,  then this should
be in the report with a reason.
Bill Wagner

-----Original Message-----
From: Harry Lewis [mailto:harryl at us.ibm.com]
Sent: Tuesday, May 04, 2004 12:55 AM
To: wbmm at pwg.org
Subject: WBMM> Couple Questions about Schedules

Couple questions / observations from internal review 

1.        Is there a way to negotiate a schedule? What if the agent thinks
the schedule is too frequent or the list of elements too large? 
2.        Can the agent refuse a schedule or a specific action in a schedule
(ex. PurgeJobs)? Is there a way to indicate this? 
Harry Lewis 
Chairman - IEEE-ISTO Printer Working Group
IBM Printing Systems 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/wims/attachments/20040505/e1205104/attachment-0001.html

More information about the Wims mailing list