attachment

<html><body> <DIV> <DIV>The next WIMS Protocol concall will be 3 May at 1 PM EST. </DIV> <DIV> </DIV> <DIV>Dial In: 1-866-365-4406 Toll #: 1-303-248-9655 Passcode: 2635888# </DIV> <DIV> </DIV> <DIV>Subjects will be:</DIV> <DIV>1. Changes to address Stuart's and other questions. I have an outline of my responses and actions relative to Stuart's questions below. The modified draft document is posted at <A href="ftp://ftp.pwg.org/pub/pwg/wims/wd/wd-wims10-20060501.pdf">ftp://ftp.pwg.org/pub/pwg/wims/wd/wd-wims10-20060501.pdf</A>.</DIV> <DIV> </DIV> <DIV>2.  Proceed with Binding Document.</DIV> <DIV> </DIV> <DIV>Thanks,</DIV> <DIV> </DIV> <DIV>Bill Wagner Chairman WIMS WG/PWG</DIV> <DIV> </DIV> <DIV> WIMS Protocol Spec Questions<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p> <o:p> </o:p> General comment 1:  We added examples to section 4 not as a normative definition but as a general discussion to provide a sense of the capabilities and the flow. Indeed, although one inclination was to put Chapter 6 before the examples, it was considered that a general understanding of the flow would assist in understanding the finer details, while the reverse was not true. Further, the examples grew to the extent that they overwhelmed the actual purpose of Section 4, <A name=_Toc130790712></A><A name=_Ref117919377></A><A name=_Ref117919371>WIMS Object Model</A>. Ira�s suggestion about adding a comment that examples are informative is reasonable, but where to put it?<o:p></o:p> <o:p> </o:p> General Comment 2: This spec is of the abstract WIMS protocol. It is not intended to get into the actual definition of elements any more than a definition of SNMP would define the MIB objects. However, some representative elements have been used in examples of the protocol. Some of the confusion apparently related to the fact that these elements were not defined.<o:p></o:p> <o:p> </o:p> General Comment 3: The spec does not specify bindings. Therefore, examples are conceptual rather than specific wire examples.<o:p></o:p> <o:p> </o:p> Area Line 615<o:p></o:p> <o:p> </o:p> Q. Why is "target" used in the following section? Shouldn't target be "WIMS Managed Entity" instead?<o:p></o:p> <o:p> </o:p> A. The target object is always a Managed Entity (though not necessarily an entire managed system - the target might be a _job_ or _subunit_).<INS cite=mailto:William%20A.%20Wagner dateTime=2006-05-01T14:53><o:p></o:p></INS> <o:p> </o:p> R. Text changed to identify target as ManagedEntity<o:p></o:p> <o:p> </o:p> Area Line 645<o:p></o:p> <o:p> </o:p> Q.1  For a WIMS Agent in a proxy, what does the identification of Agent include?<o:p></o:p> <o:p> </o:p> A. 1 For reasons of privacy during fleet management, an Agent (in a Proxy or a leaf-node Managed Entity) need not expose its network <?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" /><st1:stockticker>URI</st1:stockticker> (hostname or IP address).  This senderReference parameter is of type ObjectAgentReference (defined in 'WimsType.xsd'), which is a sequence of (one or more of) agent integer id (e.g., SNMP Index value), agent name (e.g., Asset Number value), or agent <o:p></o:p> <o:p> </o:p> R 1  No change.<o:p></o:p> <o:p> </o:p> Q 2.  Stating that RegisterForManagement operation can include operations, actions, objects is confusing<o:p></o:p> <o:p> </o:p> A. 2. Actually the operation identifies supported operations, actions, objects.<o:p></o:p> <o:p> </o:p> R.2  Section reworded. <o:p></o:p> (3) WIMS Proxy, acting as a WIMS Agent, issues a RegisterForManagment operation, including identification of the agentPaths, objects, operations, and actions supported by the Agent.  Operation arguments also include the identification of Agent (sender Reference) and Manager (managerURI).<o:p></o:p> <o:p> </o:p> Q3. But aren't supported operations, actions, and objects also arguments of RegisterForManagement?<o:p></o:p> <o:p> </o:p> A3. Agreed - arguments should be clearly labelled as input or output<o:p></o:p> <o:p> </o:p> R.3 Section reworded.<o:p></o:p> (4) WIMS Manager accepts management association with WIMS Proxy by providing a RegisterForManagementResponse, specifying its own supported objects, operations, and actions, a PWG standard status of "SuccessfulOk", and an initial Schedule. In this example, the only Action in the Schedule is an UpdateSchedule, requiring that the Agent execute a GetSchedule operation at some specified later time.<o:p></o:p> Q 4. Confusion between operations and actions<o:p></o:p> <o:p> </o:p> R 4. Rewording<o:p></o:p> <o:p> </o:p> <o:p> </o:p> Area Line 663 <o:p></o:p>  Q. How is the specific Managed Entity identified<o:p></o:p> <o:p> </o:p> <H3 style="MARGIN: 8pt 0in 0pt; TEXT-INDENT: 0in; mso-list: none; tab-stops: 28.9pt">A.  As Identified in <st1:place>Para</st1:place> 6.4.1, the <A name=_Toc130790769></A><A name=_Toc93125874></A><A name=_Toc84239642></A><A name=_Toc77764313></A><A name=5_4_12>GetElements</A> action parameters are:<o:p></o:p></H3> GetElements (agentPaths : AgentPaths,      targetObjects : TargetObjects, requestedElements : Keyword,    vendorParameters : VendorParameters) <o:p></o:p> The end Agent Path and the Target Objects fully identify the Managed Entity.<o:p></o:p> <o:p> </o:p> R. Section reworded. Reference to Fig 4 should be Fig 3..<o:p></o:p> <o:p> </o:p> Figure 3 shows the Schedule-UpdateSchedule action-GetSchedule Operation sequence which is continually repeated. Acting on the UpdateSchedule action in the initial schedule, the WIMS Proxy contacts the Manager to get an updated schedule. In this example the schedule indicates that, at a specific time, the Proxy is to execute a SendReports operation sending to the Manager the Printer Marker Life Count data obtained from a specific Managed Entity.<o:p></o:p> <o:p> </o:p> Area  Line 751<o:p></o:p> <o:p> </o:p> Q. Figure 6. is to get the list of actual devices that are "fronted" by the proxy, right? I can find no explanation of ManagerAgentSupported.<o:p></o:p> <o:p> </o:p> A. That is not really the intent of the figure.. Fig 6 illustrates ExecuteAction operation with a GetElements action directed at elements contained within the Agent. This spec is of the protocol. It does not get into the actual definition of elements. The use of a ManagementAgentSupported element is perhaps unfortunate, although one may assume that such information must be available from a proxy.<o:p></o:p> <o:p> </o:p> R. Minor rewording.<o:p></o:p> <o:p> </o:p> Area  Line 770<o:p></o:p> <o:p> </o:p> Q. There is no description of the AgentInfo element in Figure 7.  What is a (mapped) Agent object? Shouldn't "reads" be "requests"?<o:p></o:p> <o:p> </o:p> A. Figure 7 illustrates an ExecuteAction Operation specifyingg a GetElements Action that requires the SNMP manager within a proxy to query  the Managed Entity for a MIB object.  Defining the mapping of the SNMP objects into XML elements is not within the scope of this protocol document.  The  example is used just to illustrate the protocol path.<o:p></o:p> <o:p> </o:p> <OL style="MARGIN-TOP: 0in" type=A start=18> <LI class=MsoNormal style="MARGIN: 0in 0in 0pt; mso-list: l0 level1 lfo2; tab-stops: list .5in">Section is reworded <o:p></o:p></LI></OL> (3) WIMS Manager acquires a description of the legacy agent by directing to the Proxy an ExecuteAction operation containing a GetElements action for an agent description element.<o:p></o:p> <o:p> </o:p> Area Line 784<o:p></o:p> <o:p> </o:p> Q. 1 Document says � Because a WIMS Proxy must contain a WIMS Agent, and may contain a WIMS Manager�.�  Doesn�t this conflict with the Imaging System Model (Figure 1). The Proxy in Figure 1 includes a Manager. This Manager is shown talking to both a WIMS Agent and a Legacy Agent. If it is talking to a WIMS Agent doesn't it need to be a WIMS Manager? If it is talking to a Legacy Agent, I guess it would not be a WIMS Manager. I think this section about chained Proxies requires that the Proxy in Figure 1 be modified to include both a WIMS Manager (connecting to the downstream WIMS agent) and a non-WIMS Manager (connecting to the downstream Legacy agent).<o:p></o:p>  may be used. <o:p></o:p> <o:p> </o:p> A. 1.  Figure 1 does not say the WIMS Proxy (being a WIMS Proxy because it includes a WIMS Agent Interface) contains a WIMS Manager. It merely uses the term Manager, with the understanding that it could be a WIMS or a Legacy manager depending upon the agent it communicates with.  With respect to Ira�s recommended addition, I have made the change, but do not agree that it is appropriate. The statement in para 4.6 does not define a proxy, but a possible characteristic of a proxy, and that characteristic allows chaining<INS cite=mailto:William%20A.%20Wagner dateTime=2006-05-01T15:36>.</INS><o:p></o:p> <o:p> </o:p> R. I have added to the description of a Proxy after Figure 1 and echoed this in para 4.6.<o:p></o:p> <o:p> </o:p> Q 2. What does "recovered Action information" from a schedule mean?<o:p></o:p> <o:p> </o:p> A.2 It means deterine the requested actions and associated information.<o:p></o:p> <o:p> </o:p> R2. Wording changed to <o:p></o:p> Implementations are free to decompose the schedule received by an agent and use the contents of that Schedule to create new schedule(s) to be passed on to downstream agents.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> Area �Figure 9<o:p></o:p> <o:p> </o:p> Q.  I understand from the text that agentPath (shouldn't it be agentPaths as listed in 6.1.1?) expands to include all agents in the entire chain. What exactly does this look like? Does the ManagerURI also expand in this same way? If this example included sample ManagerURI and agentPath strings, I think it would be substantially more understandable to me.<o:p></o:p> <o:p> </o:p> A.  Yes, it should be  AgentPaths.  The diagrams give conceptual examples. Wire examples of the actual strings may be include in the binding document. <o:p></o:p> <o:p> </o:p> Area Line 866<o:p></o:p> <o:p> </o:p> Q. What about the communication between a WIMS Agent and a WIMS Manager within a proxy?<o:p></o:p> <o:p> </o:p> A. That is  internal and not part of the WIMS protocol.<o:p></o:p> <o:p> </o:p> R.  Added here and at the start of 6:<o:p></o:p> Note that neither the internal communications between the WIMS Agent and the Manager within a WIMS Proxy, nor the communications between a Legacy Manager in a WIMS Proxy and the legacy agent in a managed entity are subjects of this standard and are therefore not addressed here.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> Area Line  870<o:p></o:p> <o:p> </o:p> Q. Unless port 80 is explicitly specified then port 4951 will be assumed and firewalls will block WIMS unless holes for 4951 are made. Do we really expect anyone will implement WIMS using 4951? <o:p></o:p> <o:p> </o:p> A. Works fine - HTTP Clients within the enterprise (to whit, WIMS Agents) open _outbound_ HTTP connections to port 4951 on the WIMS Manager at the fleet management vendor - firewalls will allow that (non-system) port outgoing by default - this is no different from IPP/1.1 requiring default operation over port 631 and disallowing operation over port 80 unless explicitly enabled by the system administrator - follows a rather firm IETF policy directive on the reuse of port 80 by non-web-browsers.<o:p></o:p> <o:p> </o:p> R. None<o:p></o:p> <o:p> </o:p> Area line 891 <o:p></o:p> Q. Text states �A WIMS <st1:stockticker>URI</st1:stockticker> MUST be represented in absolute form. If the 'path-absolute' element is not present in a WIMS <st1:stockticker>URI</st1:stockticker>,�<o:p></o:p> These are not in conflict?<o:p></o:p> <o:p> </o:p> A.  No - 'path-absolute' is AFTER the hostname - read RFC 3986 (replaces 2396), which changed the names of many of these ABNF productions.<o:p></o:p> <o:p> </o:p> R. None<o:p></o:p> <o:p> </o:p> Area  Figure 10.<o:p></o:p> Q. What is the intention of the double pointed arrow between the proxy and the other entity on the same side of the firewall.<o:p></o:p> <o:p> </o:p> A. That double-headed arrow is actually a WIMS or Legacy Manager (in the proxy) talking to a WIMS or Legacy Agent (in the bottom managed entity).<o:p></o:p> <o:p> </o:p> R. Proxy definition added<o:p></o:p> <o:p> </o:p> Area line 1002<o:p></o:p> <o:p> </o:p> Q. Confusion between operations and actions. These two lines (1005 and 1007) confuse me completely<o:p></o:p> <o:p> </o:p> R. Text added in 6.1 and elsewhere<o:p></o:p> <o:p> </o:p> <o:p> </o:p> Area Line 1032<o:p></o:p> <o:p> </o:p> Q. There is no example that I can find that shows what operations, response and actions parameters would actually look like. <o:p></o:p> <o:p> </o:p> A.  No -all encoding details will be specified in the future, separate WIMS Transport Bindings spec (just like IPP/1.1 RFC 2910), which is early work-in-progress.  <o:p></o:p> <o:p> </o:p> R. None<o:p></o:p> <o:p> </o:p> Area line 1142 <o:p></o:p> Q. Does Legacy Agent make sense here. How can a Legacy Agent be managed by a WIMS Manager?<o:p></o:p> <o:p> </o:p> A.  Managed entities with Legacy Agents may be managed by a WIMS Manager operating through a WIMS Agent/Legacy Manager proxy.<o:p></o:p> <o:p> </o:p> R. None.<o:p></o:p></DIV></DIV> <DIV> </DIV></body></html>