attachment

<html><body> <DIV>I will take a crack at implementing these changes to the document so that they can be considered in context. Should have this posted by the weekend. Would apprecaite review by WG members so that we can have detailed discussion on 15 Feb. But if you have comments to Ira's message earlier, please send them.</DIV> <DIV> </DIV> <DIV>Feb 8 WIMS protocol concall remains cancelled. I have not seen  any messge from Pete on SM call in that spot.</DIV> <DIV> </DIV> <DIV>Bill Wagner</DIV> <DIV> </DIV> <BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">-------------- Original message -------------- From: "McDonald, Ira" <imcdonald@sharplabs.com> > Hi folks, Tuesday (7 February 2006) > > Below are proposed WIMS Protocol spec and WIMS XML schema updates for > support of multi-level (or 'chained') WIMS Proxy configurations that we > discussed at the January PWG face-to-face and last week's WIMS telecon. > > Basically, in _every_ Action _except_ UpdateSchedule, replace the > (one-level) 'agentReferences : AgentReferences' parameter with a > (multi-level) 'agentPaths : AgentPaths' parameter (see below). > > UpdateSchedule MUST NOT be forwarded and MUST still use a single-valued > 'agentReference : AgentReference' parameter that MUST resolve to the > local (receiving) WIMS Agent. > > > The processing model is simple: > > (1) WIMS Proxy receives incoming 'Action' from adjacent upstream WIMS > Manager (via running Schedule or ExecuteAction request). > (2) WIMS Proxy rewrites 'ActionAgentPaths' of 'Action', removing the > _first_ WIMS Agent reference (to itself) in each agent path in the > array of paths. > (3) WIMS Proxy forwards rewritten 'Action' to the adjacent downstream > WIMS Agents via ExecuteAction requests and/or Legacy Agents via > legacy protocol requests (e.g., SNMP Set). > (4) Recursion of steps (1) to (3) leads to final WIMS Agents or Legacy > Agents (nearest to actual managed entities). > (5) Upstream ExecuteAction or legacy protocol responses convey resulting > status back to original WIMS Proxy who conveys resulting status > back via SendReports request or ExecuteAction response to original > WIMS Manager. > > > Note: ExecuteAction is used here for operation forwarding downstream in > order to preserve ! the 'imm ediate' nature of a triggered Action in a > Schedule. It would be possible to forward operations via downstream > Schedule objects, but vastly more complicated to correlate the responses > and not faithful to an 'immediate' trigger. > > Comments? > > 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 > > ------------------------------------------------------------------------ > [WIMS Protocol spec] > > > [diagrams and notes in section 4] > > [change] > agentReferences > [to] > agentPaths > > > [definition in section 6.1.1 - note plural 'Paths'] > > [change] > agentReferences : AgentReferences > [to] > agentPaths : AgentPaths > > [change] > References to the WIMS... > [to] > Paths to the WIMS... > > > [definition in section 6.1.3 - note plural 'Paths'] > > [change] > agentReferences : AgentReferences > [to] > agentPaths : AgentPaths > > [change] > References to the WIMS... > [to] > Paths to the WIMS... > > > [RegisterForManagement in section 6.2.1 - note plural 'Paths'] > > [change] > agentReferences : AgentReferences > [to] > agentPaths : AgentPaths > > > [UnregisterForManagement in section 6.2.2 - note plural 'Paths'] > > [change] > agentReferences : AgentReferences > [to] > agentPaths : AgentPaths > > > [actions in sections 6.4, 6.5, and 6.6 - note plural 'Paths'] > > [change] > agentReferences : AgentReferences > [to] > agentPaths : Agen! tPaths > > > ------------------------------------------------------------------------ > [WIMS Message schema] > > > [RegisterForManagement and UnregisterForManagement requests] > > [change] > RequestAgentReferences > [to] > RequestAgentPaths > > > ------------------------------------------------------------------------ > [WIMS Type schema] > > > [add two new types] > > <?xml:namespace prefix = xsd /><xsd:complexType name="ObjectAgentPath"> >  >  > <xsd:sequence> > <xsd:element name="ObjectAgentReference" > type="ObjectAgentReference" > minOccurs="0" maxOccurs="unbounded"/> > </xsd:sequence> > </xsd:complexType> > > <xsd:complexType name="ObjectAgentPaths"> > <xsd:sequence> > <xsd:element name="ObjectAgentPath" > type="ObjectAgentPath" > minOccurs="0" maxOccurs="unbounded"/> > </xsd:sequence> > </xsd:complexType> > > > ------------------------------------------------------------------------ > [WIMS Schedule schema] > > > [delete unused 'ActionAgentReferences' element] > > > [add new 'ActionAgentPaths' element] > > <xsd:element name="ActionAgentPaths" > type="ObjectAgentPaths"/> >  >  >  > > > [modify each action in WIMS Schedule schema, for example] > > <xsd:element name="ActionGetElements"> > <xsd:complexType name="ActionGetElements" > <xsd:sequence> > <xsd:element > minOccurs="0" m! axOccurs ="1"/> > <xsd:element > minOccurs="0" maxOccurs="1"/> > <xsd:element > minOccurs="0" maxOccurs="1"/> > <xsd:element > minOccurs="0" maxOccurs="1"/> > </xsd:sequence> > </xsd:complexType> > </xsd:element> > > > ------------------------------------------------------------------------ </BLOCKQUOTE></xsd:element></xsd:element></xsd:element></xsd:element></xsd:element></xsd:element></xsd:element></body></html>