OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ws-dd message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [ws-dd] Understanding WS-Discovery operational modes - WS-D Primer

Hi Vipul,
thanks for the document.
Following are some questions/feedback on the WS-D Primer.
1.2.1 “. In this mode the protocol messages are sent multicast on the network. “
Not all the protocol messages are sent multicast on the network in ad-hoc discovery mode. ProbeMatch and ResolveMatch are sent unicast. It would be more appropriate to say protocol messages are sent multicast to Target Service.
Figure 3 – The scenario illustrated in this diagram does not quite fit the scope defined by ws-discovery, or seem practical in real world. DP acts more like proxy defined in ws-discovery remote extension document.
Figure 4: This figure shows a client receiving unicast Hello: it should probably be mentioned in the bullet points above the figure, since it is not strictly ad-hoc mode messages, or removed and placed in section 3.3 instead.

2.2 the agent mentioned in this section should be described with more details
section 4 Discovery Proxy
"Additionally it can be configured to act as a multicast suppression agent"
According to 1.1 (and in a lot of people's mind) it is the first of three things that a DP does (or the main thing a DP does). That's why this sentence doesn't seem to be a good choice. (it make it sounds like it's an additional benefit, instead of a core benefit)
There should be a section about security, and particularly things like man in the middle attacks
Is Managed Mode applied uniformly to all Target Services, Clients and Discovery Proxies on a network? If so it should be mentioned as such. If not, then a DP can be in Managed Mode and a TS/Client may not be, and therefore the DP can receive multicast Hellos/Byes/Probes/Resolves, and that should be indicated in Figure 7.

Section 4.2: What is the wsd:Types of a Discovery Proxy when it advertises itself?

Section 4.2, line 145-147: “It then offers the Clients to query this information via managed mode….” Does this mean the DP running in ad-hoc mode can let Clients query it as if in managed mode? Does this mean DP is converting itself to ad-hoc mode, or just that Clients get converted to managed mode and DP stay in ad-hoc mode?

5.1. Typo in step 12: Target Service 2 is projector, not scanner.

line 147: it could be helpful to clarify what exactly is the "managed mode endpoint"
Line 150-154: This bullet point should clarify that the Probe the DP is listening for is a Probe for DP wsd:Types, not a Probe for TargetServices
Figure 9: the figure is difficult to read... it could help if the numbers were ordered.
- if a service gets aware of the presence of a DP on the network (for example through DHCP) should it switch to managed mode and talk only to this DP (through unicast)?
- How can a client be sure that DP always provides up-to-date information of all the TARGET SERVICE, for instance, what if a DP responds to a client’s Probe, but not to a TARGET SERVICE’s Hello?
- How can a Target Service verify whether DP is responsive? In managed mode, a TARGET SERVICE sends unicast Hello to a DP once its metadata has been changed. If a DP is not responsive, a TARGET SERVICE has to send multicast Hello.
- How can a Target Service opt not to be presented by a DP?
- Is there any difference between a DP and a proxy as defined in ws-discovery remote extension?
The document assumes that a Service needs to know in advance what a DP is, preventing a seemless integration.
Some people assume that a DP should be a component that is inserted in an existing network, mainly to suppress multicast. (ie the Service, including those services that are already shipping, don't even need to know they are talking to a DP) Some think it should help cross network communications in secure/internal environment.
We may need a broader discussion about the expected goals of a Discovery Proxy...
A way to deal with it would be to define several "levels" of DP: a first level would be a seemless multicast suppression (useful in trusted environments for example), and a second level would be a more complex DP as defined in this document, and requiring several changes to services.

From: Vipul Modi [mailto:Vipul.Modi@microsoft.com]
Sent: Mon 10/6/2008 5:18 PM
To: ws-dd@lists.oasis-open.org
Subject: [ws-dd] Understanding WS-Discovery operational modes - WS-D Primer

Hello all,


During the first face to face, some of us felt that the current WS-Discovery specification does not provide a clear description of requirements and responsibilities of various actors in an ad hoc mode and a managed mode. We made good progress on this during the technical discussions and white boarded our understanding of the specification in this regard. We filed and accepted a number of issues called “managed cluster” in this regard.


Please find the attached document titled “WS-Discovery Primer” that captures the essence of our discussions and understanding, and explains the behavior of a Target Service, a Client and a Discovery Proxy in a managed mode and an ad hoc mode as defined by the current specification. This document should allows us to be on the same page with respect to understanding ad hoc and managed modes and message exchanges in these modes, and help us make progress on the “managed cluster” issues.



Vipul Modi

Senior Development Lead, Microsoft Corporation.

vipul.modi@microsoft.com | 425-707-2402


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]