Hi Stuart,
I'm forwarding this thread to the WIMS WG list, because these were
comments during a Formal Vote, and Bill put them on the agenda for
tomorrow's WIMS telecon.
All - Stuart's experience reading this spec and lacking tools to read the
schema (formatted) indicate that we need to:
(a) do more work on our specs;
(b) find better tools; and
(c) discuss our migration from binary protocols (eg, IPP) to XML
schema based protocols - which are excruciatingly verbose in
schemas and completely opaque (untyped) in instances.
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 at sharplabs.com
-----Original Message-----
From: McDonald, Ira
Sent: Saturday, April 22, 2006 2:09 PM
To: 'Stuart Rowley'; wamwagner at comcast.net; Harry Lewis; McDonald, Ira
Subject: RE: [more replies to Stuart] WIMS Protocol Spec Questions
Hi Stuart,
More replies inline below as <ira-2>
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 at sharplabs.com
-----Original Message-----
From: Stuart Rowley [mailto:Stuart.Rowley at ktd-kyocera.com]
Sent: Friday, April 21, 2006 5:53 PM
To: McDonald, Ira; wamwagner at comcast.net; Harry Lewis
Subject: RE: WIMS Protocol Spec Questions
Hi Ira,
Thanks for your quick comments (and for not chewing me out for waiting so
long to comment).
I included some responses to your comments as SR> bla bla
It seems that the main problem is that I did not review the schema. I tried,
but they may as well be in hieroglyphics when viewed in Word or Notepad. I
do not have XMLSpy (it is $499). I tried downloading XMLFox, but it was just
no help at all. I guess it would have made considerably more sense if I had
been able to adequately review the schema. Can you suggest a way for me to
review the schema?
Best regards,
Stuart
_____
From: McDonald, Ira [mailto:imcdonald at sharplabs.com]
Sent: Friday, April 21, 2006 1:24 PM
To: Stuart Rowley; wamwagner at comcast.net; Harry Lewis
Subject: RE: WIMS Protocol Spec Questions
Hi Stuart,
By sheer luck, I just logged on to check my email - so below are some
replies inline.
To avoid further confusion, read the operation definitions and the _schema_
first and then look at the less rigorous and informative examples and
diagrams.
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 at sharplabs.com
-----Original Message-----
From: Stuart Rowley [mailto:Stuart.Rowley at ktd-kyocera.com]
Sent: Friday, April 21, 2006 3:33 PM
To: McDonald, Ira; wamwagner at comcast.net; Harry Lewis
Subject: WIMS Protocol Spec Questions
Dear Authors,
I will start with an apology. It must be aggravating to receive this email
at the 11th hour, 59th minute. Or actually past that, because these
questions should have been made during last call. Therefore, it would be
completely understandable for you to just ignore this ill timed email.
All of you have spent zillions of hours working over this spec and on con
calls, etc. While I have struggled to find just 5 to 10 hours to thoroughly
review the spec. For this I apologize.
I was finally guilted into reviewing the spec, although I have been on
crushing internal deadlines, because it just doesn't seem fair for me to not
vote or to abstain. I value your efforts on these specs and I want to be
informed enough to not give just a rubber stamp vote.
Unfortunately, after my review, I am still not sure I understand it well
enough to make a thoroughly informed vote :-(. Therefore I have included the
questions below to help me understand this spec.
If I were to implement this spec, I think I would definitely need an
implementers' guide with actual examples.
Best regards,
Stuart
Stuart Rowley, Network Product Mgr.
stuart.rowley at ktd-kyocera.com 925 849-3306 925 849-3399 (fax)
Kyocera Technology Development Inc.
1855 Gateway Blvd. Suite 400
Concord, CA 94520
WIMS Protocol Spec Questions
Why is "target" used in the following section? Shouldn't target be "WIMS
Managed Entity" instead?
615 GetElements: get value of specified elements from the target at
specified time and issue a
616 SendReports
617 SubscribeForAlerts: monitor target for specified alert conditions and
issue SendAlerts when they
618 occur
619 UnsubscribeForAlerts: stop specified alert condition monitoring
620 UpdateSchedule: issue a GetSchedule at specified time.
621 Aside from the UpdateSchedule action, by which a WIMS Manager schedules
the time at which the
622 WIMS Agent executes a GetSchedule operation, most other actions require
the Agent to interact with
623 the target.
<ira> The is editorial legacy - the target object is always a Managed Entity
(though not necessarily an entire managed system - the target might be a
_job_ or _subunit_).
645 (3) WIMS Proxy, acting as a WIMS Agent, sends RegisterForManagment
request, including supported
646 objects, operations, and actions. Operation arguments include
identification of Agent (sender
647 Reference) and Manager (managerURI).
Identification of agent? The agent is in the Proxy. Is the device
identified?
<ira> Sorry - which 'device' do you mean? The Agent object occurs (usually
once) on every managed system - there is a peer System object (MIB-II,
HR-MIB, and prtGeneralEntry) that is pointed to by the Agent - the Agent URI
includes a hostname.
SR> So for a WIMS Agent in a proxy, what does the identification of Agent
include?
<ira-2> For reasons of privacy during fleet management, an Agent (in a Proxy
or a leaf-node Managed Entity) need not expose its network URI (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 URI. Bill Wagner championed this requirement for hiding the
customer's enterprise network toplogy.
663 Figure 4 shows the GetSchedule-Action sequence which will be continually
repeated. The WIMS
664 Proxy contacts the Manager to get an updated schedule. In this example
the schedule indicates that,
665 at a specific time, the Proxy is to execute a SendReports operation
sending the Manager the Printer
666 Marker Life Count data obtained from a specific Managed Entity.
How is the specific Managed Entity identified?
<ira> The datastructure 'ActionTargetObjects' (see 'Schedule.xsd')
identifies exactly the target Managed Entity. This element is present and
REQUIRED in EVERY action definition.
Figure 2
RegisterForManagement
(senderReference, managerURI,
agentPaths,operations,
actions, objects )
and associated comment
645 (3) WIMS Proxy, acting as a WIMS Agent, sends RegisterForManagment
request, including supported
646 objects, operations, and actions. Operation arguments include
identification of Agent (sender
647 Reference) and Manager (managerURI).
Argh, RegisterForManagement is an operation right? Why is it described as a
request that can include operations? This makes the example very hard to
understand. What operations can a RequestForManagement include?
OK, I get it now. It is supported operations. Maybe I am dense, but this was
very hard for me to follow, especially with this text, "Operation arguments
include ..."
The following would be more understandable to me:
RegisterForManagement
(senderReference, managerURI,
agentPaths,supported operations,
supported actions, supported objects )
<ira> Ok, we could have improved the tags of these parameters, but they're
meaning is quite clear in the actual operation signature (from page 42 of
the PDF spec):
6.2.1RegisterForManagement
RegisterForManagement (senderReference : AgentReference, managerURI :
URI agentPaths : AgentPaths,
operations :WIMSOperationsSupported,
actions : WIMSActionsSupported, objects : WIMSObjectsSupported),
statusString : StatusString, operations :
WIMSOperationsSupported,
actions : WIMSActionsSupported, objects : WIMSObjectsSupported,
schedule : Schedule
645 (3) WIMS Proxy, acting as a WIMS Agent, sends RegisterForManagment
operation, including supported
646 objects, operations, and actions. RegisterForManagment arguments include
identification of Agent (sender
647 Reference) and Manager (managerURI).
But aren't supported operations, actions, and objects also arguments of
RegisterForManagement?
<ira> They _are_ inputarguments - see the operation signature above.
SR> If they are all input arguments, then listing them separately in the two
sentences in 645 - 647 with only identification of Agent and Manager
identified as arguments is confusing.
<ira-2> Agreed - arguments should be clearly labelled as input or output.
And actually, the term parameters is universally used in the schema for
arguments (the construction 'output parameter' makes more sense).
ManagerAgentSupported
I am having a tough time understanding Figure 6. This is to get the list of
actual devices that are "fronted" by the proxy, right? I can find no
explanation of ManagerAgentSupported.
<ira> Nope - you have to read'WimsBase.xsd' - all of the details of the WIMS
multifunction objects that will be added to the SM/2.0 release are defined
ONLY in the schema - we rejected writing an awful IPP-style thousand-page
spec.
In Figure 7, I just don't get this. I can find no description of the
AgentInfo element. What is a (mapped) Agent object? Shouldn't "reads" be
"requests"?
770 (3) WIMS Manager reads description of legacy agent by sending
ExecuteAction request containing
771 GetElements action for AgentInfo element in (mapped) Agent object.
<ira> See above - read 'WimsBase.xsd' - AgentInfo is the description of the
Agent, consistent with 'printer-info' attribute of an IPP Printer object. We
used the verb 'reads' here because these are examples - NOT the normative
definitions of operations and objects.
784 may be used. Because a WIMS Proxy must contain a WIMS Agent, and may
contain a WIMS
785 Manager,
I think this sentence does not match 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).
<ira> Bad terminology. There is no such thing as a first-class WIMS Proxy
object. A WIMS Manager control ONLY a downstream WIMS Agent (using WIMS
protocol). A WIMS Agent in a _proxy_ system talks to its upstream (parent)
WIMS Manager and forwards operations to one or more downstream WIMS Managers
and/or Legacy Managers. Bill would say that an intermediate layer WIMS
Manager could also speak SNMP to target devices - this is modelling purity
issue.
SR> Are you agreeing with my point?
<ira-2> YES - I'm agreeing with your point that the terminology here needs
cleanup - for clarity, we should describe a WIMS Agent (in a WIMS Proxy
system) as forwarding operations to WIMS Managers (for downstream WIMS
protocol) and Legacy Managers (for SNMP, IPP, etc.). BUT - the abstract
object Manager models a unified WIMS Manager and Legacy Manager and can
represent adjacent upstream Agents (ManagerParentAgentSupported list),
adjacent downstream Agents (ManagerAgentSupported list) and multi-hop paths
to Managed Entities (ManagerAgentPathSupported list).
790 Proxies. Implementations are free to decompose the schedule received by
an agent and use the
791 recovered Action information to create a new schedule to be passed on.
What does "recovered Action information" mean?
Figure 9:
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.
<ira> Yes, it _is_ AgentPaths in all the Action definitions in Schedule.xsd.
We added these extensive examples after last call comments - but the
examples lay the reader open to various misunderstandings - the whole
chapter should begin "The following examples are informative - anywhere they
disagree with the normative Operation and Action definitions, the normative
definitions take precedence."
866 * In the WIMS Agent Interface, the WIMS Agent always initiates the
connection and sends
867 operation requests to the superior WIMS Manager.
What about the communication between a WIMS Agent and a WIMS Manager within
a proxy?
<ira> Internal implementation detail - I wrote a proposal a year agoto
define the operation forwarding API between a WIMS Agent and its co-located
WIMS Manager in a proxy system, but there was strong pushback to abandon it.
SR> This text just seems like it needs a qualifier because a WIMS Agent in a
proxy also communicates by some out of band method to the proxy WIMS
Manager.
<ira-2> So, perhaps we should append to the end of the sentence above
"...superior WIMS Manager and forwards operation requests to co-located
subordinate WIMS Managers and Legacy Managers (by an implementation-defined
method)."
870 5.2 Associated Port
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?
<ira> 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.
SR> I am aware of the IETF policies. I believe that the default operation of
all firewalls is to allow outbound connections on port 80 and to block
outbound connections on ports 631 or 4951 (that is how my corporate firewall
is configured). The theory is great, but in practice we know that getting
organizations to punch holes in firewalls is much more difficult than having
a non-conforming default implementation that uses port 80. This is of course
why port 80 is so over used. Unless firewall vendors can be convinced to
open port 4951 outbound as part of a default configuration, I would bet that
every vendor implementing WIMS will default to port 80. However, I am not
suggesting any changes to the spec :-)
<ira-2> Strong disagreement - every vendor had better default to 4951 and
_allow_ the administrator during installation to enable 80 (just like
conforming IPP/1.1 implementations) - otherwise they are non-conforming and
people like US NIST and various government agencies are going to notice and
NOT buy those products. Also,
there is a profound difference between 631 (a kernel-only system port) and
4951 (an IANA-registered application port). Good quality firewalls allow
outbound connections to non-privileged application ports by default
(although they may examine the content) - that's how CUPS works
out-of-the-box with port 8631 for an End User.
891 A WIMS URI MUST be represented in absolute form,
910 If the 'path-absolute' element is not present in a WIMS URI,
These are not in conflict?
<ira> No - 'path-absolute' is AFTER the hostname - read RFC 3986 (replaces
2396), which changed the names ofmany of these ABNF productions.
Figure 10.
What is the intention of the double pointed arrow between the proxy and the
other entity on the same side of the firewall? I think this would be
interesting to include in this diagram. Does the Proxy implement separate
WIMS Agent and WIMS Manager interfaces to communicate to downstream WIMS
agents and managers?
<ira> Argh! We shouldn't have included all these diagrams! 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).
1002 Each "interface" consists of a set of "Operations" that the Agent or
Manager can initiate. Some of the
1003 operations invoke "Actions" by the Agent. The operations and actions in
the following paragraphs are
1004 defined in the form:
1005 OperationName (OperationParameters) Responses, and
1006
1007 ActionName (ActionParameters)
I am having amazing trouble understanding the relationship between
Operations and Actions. These two lines (1005 and 1007) confuse me
completely. See the following text snippets.
650 PWG standard status of "SuccessfulOk", and an initial Schedule. In this
example, the only Action in
651 the Schedule is a later GetSchedule operation.
657 scheduled actions usually is that the WIMS Proxy contacts the WIMS
Manager with a GetSchedule
658 request.
In this example, the WIMS Manager needs to work with the information 660
provided in
661 RegisterForManagment to develop a plan for managing the Object (the
ManagedEntity). The initial
662 schedule therefore includes only a scheduled GetSchedule action.
663 Figure 4 shows the GetSchedule-Action sequence which will be continually
repeated. The WIMS
In these sections, GetSchedule is described as an action, a request, an
operation, and an operation included in an action. Wow. I think it is
critical to understand the relationship between actions and operations, and
frankly I am having a tough time with it.
<ira> These are remaining typos (to be FIXED, Bill) in the spec - the name
of the Action is UpdateSchedule (see Schedule.xsd), whichcauses a mandatory
GetSchedule operation (in a timely manner after the UpdateSchedule action
triggers).
1032 objects : WIMSObjectsSupported
1033 List of objects supported by this WIMS Agent in the case of Agent
Operations, and by this WIMS
1034 Manager in the case of Manager Operations.
There is no example that I can find that shows what it would actually look
like. I am guessing the text in the actual operation would be something
like: objects : WIMS_object1, WIMS_object2, WIMS_object3;
Shouldn't it describe this? I assume it is described by reference to some
accepted format, but it is not obvious to me.
<ira> 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. After Jerry asked for specific SOAP examples during the
last call, we renamed this spec to "WIMS Abstract Protocol" and removed
transport binding details.
1142 1. Managed Entities to be identified as being manageable by the
specified WIMS Manager through
1143 a WIMS Agent or Legacy Agent,
I don't think Legacy Agent makes sense here. How can a Legacy Agent be
managed by a WIMS Manager?
<Ira> Nope - makes sense here -some AgentPaths can terminate in a Legacy
Agent URI (e.g., 'snmp://example.com:161').
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.4.5/321 - Release Date: 4/21/2006
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.4.5/321 - Release Date: 4/21/2006
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.4.5/321 - Release Date: 4/21/2006
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.4.5/321 - Release Date: 4/21/2006
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.4.6/323 - Release Date: 4/24/2006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/wims/attachments/20060425/af67edfd/attachment.html