Web Based Monitoring and Management: RE: WBMM> Edits for wd-

RE: WBMM> Edits for wd-wims10-20040628.pdf

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Fri Jul 16 2004 - 20:00:08 EDT

  • Next message: Harry Lewis: "RE: WBMM> Edits for wd-wims10-20040628.pdf"

    Hi Bill,

    Thanks for all this work, Bill!

    About your two comments below in RegisterForManagement:

    (a) The parameters (which we already added) are critically
        necessary. Otherwise the WIMS Manager _cannot_ build
        a valid Schedule, that won't cause SendAlert results.

        (chicken and egg problem - WIMS Manager needs to do
        a GetElements action to query WIMSOperationsSupported
        on the Agent object, otherwise, but it's too late)

    (b) The returns (which I proposed below) are highly useful,
        because they allow negotiation between WIMS Agent and
        WIMS Manager on mutual support.

    (c) Bill - note that _both_ the Agent (in parameters)
        and the Manager (in returns) report ALL operations
        they support (in both WIMS Agent Interface and
        WIMS Manager Interface) - they simply support the
        opposite ends of the SAME operations (after the
        negotiated down-scoping in the Manager returns).
        The same is true for Objects and Actions. Both
        an Agent and a Manager must support an Action for
        it to be usable.

    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

    -----Original Message-----
    From: Wagner,William [mailto:WWagner@NetSilicon.com]
    Sent: Friday, July 16, 2004 6:09 PM
    To: McDonald, Ira; 'Harry Lewis' (E-mail)
    Cc: 'Wbmm (E-mail)
    Subject: RE: WBMM> Edits for wd-wims10-20040628.pdf

    Ira and Harry

    Sorry to take so long to get to these. I have, except as indicated below or
    where there appeared to be typos, included the changes identified in Ira's
    message. In some cases, I have rearranged text. I have not yet done the
    font-matter/standard format change. Nor have I added the high level
    explanation of multiple managers and multiple schedules which I believe are
    necessary.

    Although there are some places that the change from managed entity to agent
    are necessary, I want keep the idea of a Managed Entity distinct from
    Agent. I regard the WIMS Agent as an agent to allow the management of the
    Managed Entity. This is particularly necessary for the Legacy Managed
    Entity. Also, in discussing the effects of an action, it is unlikely that
    there will be a config change or state change in the agent, particularly if
    the agent is in a proxy. There may well be a change in the config or state
    of the managed entity.

    I also changed the definition of returned unsupported element definitions in
    Agent Operations.

    Thanks,

    Bill Wagner

    -----Original Message-----
    From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
    Sent: Thursday, July 08, 2004 8:29 PM
    To: 'wbmm@pwg.org'
    Subject: WBMM> Edits for wd-wims10-20040628.pdf

    Hi Bill, Thursday (8 July 2004)

    Here are the edits I suggest for your latest WIMS protocol spec draft
    'wd-wims10-20040628.pdf'. They are in addition to some typos we found
    during last week's telecon.

    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

    ----------------------------------------

    (0) Global
        - terminology
      * change 'pwg- WIMS:' to 'pwg-wims:'
      * change 'Managed Entity' to 'Agent' or 'WIMS Agent'
      * change 'Managed Entities' to 'Agents' or 'WIMS Agents'
      * change 'Management Station' to 'Manager' or 'WIMS Manager'

    (1) Section 5.1.4 RegisterForManagement
        - we can have both Agent and Manager exchange capabilities here -
    ><WW>< I know we talk about this, but I am concerned about the value versus
    the cost.><WW><

      * change method signature to

        RegisterForManagement (sourceURI : URI, targetURI : URI
            operations : WIMSOperationsSupported,
            actions : WIMSActionsSupported,
            objects : WIMSObjectsSupported) statusString : StatusString,
            operations : WIMSOperationsSupported,
            actions : WIMSActionsSupported,
            objects : WIMSObjectsSupported,
            schedule : Schedule

      * change highlighted Parameters to

        operations : pwg-sm:WIMSOperationsSupported
        - list of WIMS protocol operations supported by this WIMS Agent.

        actions : pwg-sm:WIMSActionsSupported
        - list of WIMS protocol actions supported by this WIMS Agent.

        objects : pwg-sm:WIMSObjectsSupported
        - list of WIMS objects supported by this WIMS Agent.

      * insert new Returns after statusString and before schedule

        operations : pwg-sm:WIMSOperationsSupported
        - list of WIMS protocol operations supported by this WIMS Manager.

        actions : pwg-sm:WIMSActionsSupported
        - list of WIMS protocol actions supported by this WIMS Manager.

        objects : pwg-sm:WIMSObjectsSupported
        - list of WIMS objects supported by this WIMS Manager.
    ><WW>< I indicated that the Manager actions and objects should be a subset
    of the reported Agent Actions and Objects. Manager operations are
    distinct.><WW><

    (2) Section 5.2.2 ExecuteAction
        - my mistake - I will fix Schedule to add the Action union element

      * change method signature to

        ExecuteAction (sourceURI : URI, targetURI : URI, action : Action)
            statusString : StatusString,
            unsupportedElements : UnsupportedElements

      * change Parameters to

        action : pwg-sm:Action
        - single action for immediate execution - this Action instance MUST
        conform to the XML Schema defined in the PWG Semantic Model [PWG-SM]
        module 'Schedule.xsd'.

    (3) Section 5.3 WIMS Monitoring Actions
        - editorial fixups to align with Schedule schema

      * change entire second paragraph to

        This section defines WIMS monitoring actions that are benign and
        intended not to disrupt the normal operation of the WIMS Agent.
        Therefore, support for WIMS monitoring actions is REQUIRED for all
        WIMS Agents and WIMS Managers. This does not preclude the local
        configuration of policies disallowing certain actions, particularly
        with respect to certain elements or values. For example, certain
        elements or resources may be may be regarded as private information
        and may be made inaccessible.

    (4) Section 5.3.2 GetResources
      * change method signature to

        GetResources (targetURIs : URI,
            requestedResources : RequestedResources,
            parameters : any)

      * change Parameters to

        requestedResources : pwg-sm:ActionRequestedResources
        - list of requested resources specified by ResourceId values (keys),
        ResourceName values (local names), and/or a resource filter (set of
        resource elements and values that all MUST be satisified for match).

    (5) Section 5.3.3 SubscribeForAlerts
      * change method signature to

        SubscribeForAlerts (targetURIs : URI, notifyrecipientURI : URI,
            notifyEvents : NotifyEvents, notifyElements : NMTOKEN,
            subsciptionElements : any, parameters : any)

      * change Parameters to

        notifyRecipientURI : xsd:anyURI
        - URI of the WIMS Manager to be notified - this value MUST use the
        'pwg-wims:' URL scheme and MUST conform to [RFC2396].

        notifyEvents : pwg-sm:NotifyEvents
        - list of event names to be delivered via SendAlert and defined in
        the PWG Semantic Model [PWG-SM] module 'Events.xsd'.

        subscriptionElements : pwg-sm:ActionElementAny
        - optional fully qualified names and strongly typed values of
        Subscription object elements defined in the PWG Semantic Model
        [PWG-SM] module 'Alert.xsd'. Support by WIMS Agents of 'visible'
        Subscription objects (can be queried with GetElements) is OPTIONAL.

    (6) Section 5.3.4 UnsubscribeForAlerts
        - editorial fixup to align with Schedule schema

      * change Description to

        Cancel subscription for event delivery via SendAlert. WIMS Agent
        MUST send a SendReport to the configured WIMS Manager.

    (7) Section 5.4
        - editorial fixups to align with Schedule schema

      * change title to

        5.4 WIMS Administration Actions

      * change beginning of first sentence to

        Each of the administration actions

      * change entire second paragraph to

        This section defines WIMS administration actions that all cause
        immediate state changes and may disrupt operation of the WIMS Agent.
        Therefore, support for WIMS administration actions is OPTIONAL for
        all WIMS Agents and WIMS Managers. These actions will result in an
        WIMS SendAlert operation only if the Schedule also includes a
        SubscribeForAlerts action specifying the corresponding state change
        events, or if the actions fail.

    (8) Section 5.4.1 Vendor
        - editorial fixup to align with Schedule schema
      * move entire section to section 5.5 WIMS Management Actions
        - to allow use of vendor extension operations _without_ support for
          any of the more powerful WIMS administration actions

    (9) Section 5.5

      * change title to

        5.5 WIMS Management Actions

      * change beginning of first sentence to

        Each monitoring action

      * change entire second/third paragraphs to

        This section defines WIMS management actions that may indirectly
        cause state changes or disrupt operation of the WIMS Agent.
        Therefore, support for WIMS management actions is OPTIONAL for
        all WIMS Agents and WIMS Managers. These actions all result in an
        WIMS SendReport operation to confirm action success or failure.

    (10) Section 5.5.1 SetElements

      * change method signature to

        SetElements (targetURIs : URI,
            targetElements : any
            mandatoryElements : NMTOKEN
            resetMode : restartMode
            parameters : any)

      * change Parameters to

        mandatoryElements : xsd:NMTOKEN
        - fully qualified names of the mandatory elements that MUST all be
        successfully set or else this SetElements action MUST fail.

        resetMode : pwg-sm:ActionRestartModeType
        - reset mode (none, current configuration cold boot, current
        configuration warm boot, previous good configuration, factory
        default configuration). If this parameter is missing or 'None',
        then the specified target elements are NOT reset to a previous
        configuration but are instead explicitly set to the newly requested
        values. This parameter supports reset of selected elements to their
        previous values without requiring a Restart of the WIMS Agent.

    (11) Section 5.5.2 DeleteResources
        - see section 5.3.2 GetResources above

      * change method signature to

        DeleteResources (targetURIs : URI,
            requestedResources : RequestedResources,
            parameters : any)

      * change Parameters to

        requestedResources : pwg-sm:ActionRequestedResources
        - list of requested resources specified by ResourceId values (keys),
        ResourceName values (local names), and/or a resource filter (set of
        resource elements and values that all MUST be satisified for match).

    (12) Section 5.5.3 SetResources
        - see section 5.5.1 SetElements above

      * change method signature to

        SetResources (targetURIs : URI,
            targetResources : TargetResources,
            targetElements : any
            mandatoryElements : NMTOKEN
            parameters : any)

      * change Parameters to

        targetResources : pwg-sm:ActionTargetResources
        - list of target resources specified by ResourceId values (keys),
        ResourceName values (local names), and/or a resource filter (set of
        resource elements and values that all MUST be satisified for match).

        targetElements : pwg-sm:ActionElementAny
        - fully qualified names and strongly typed values of target
        elements to be added or modified by this SetResources action.

        mandatoryElements : xsd:NMTOKEN
        - fully qualified names of the mandatory elements that MUST all be
        successfully set or else this SetResources action MUST fail.

    ----------------------------------------



    This archive was generated by hypermail 2b29 : Fri Jul 16 2004 - 20:00:40 EDT