[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: [ws-dd-comment] NEW Issue: Ad Hoc and Managed for Discovery Proxy
|
Hi Everyone, Please defer discussions
on this issue until a time this issue is accepted and is assigned a number. Document: Web Service
Dynamic Discovery (WS-Discovery) V1.1 Public Review Draft (http://docs.oasis-open.org/ws-dd/discovery/1.1/pr-01/wsdd-discovery-1.1-spec-pr-01.pdf) Location (defaults to
line number): Section 2.2.3 (from line 382) Following the original
issue submission I had a discussion with Ram Jeyaraman and Vipul Modi on this
issue (see below). We just had a telephone conference after this Email discussion,
where we discussed this issue in more detail and agreed upon proposing a slightly
different wording on section 2.2.3 (line 382): However, if one or more DP >>that provide multicast suppression<< are
available, those DP send a unicast >>Hello that contains information on an endpoint that
implements << a well-known "discovery
proxy" type d:DiscoveryProxy in response to any multicast Probe or
Resolve. As depicted in Figure 4, Clients listen for this signal that one or
more DP are available, and for subsequent searches switch to a managed mode and
instead of multicast, send Probe and Resolve messages unicast to one or more DP
they trust whilst ignoring multicast Hello and Bye from Target Services” The changes are in red or
between >> and <<. This wording does target the
original issue but at the same time also considers independency between the
endpoint providing multicast suppression and the endpoint actually implementing
a discovery proxy in managed mode. Thanks again for all the
good work in the WS-DD TC! Best regards, Jens -- From:
Jens Schmutzler [mailto:jens.schmutzler@uni-dortmund.de] Hi Ram, Hi Vipul, Thanks a lot for your
EMails! I read all relevant
sections again with this information in mind and your explanations clarified
this issue to me. However, before I
submitted this issue to the mailing list, I forwarded it to some colleagues in
the MORE consortium and some department members to review it. They were all
quite uncertain about how this is meant in the specification. Hence, I was
thinking about a short and precise wording in order to proactively prevent such
a misunderstanding of the specification in the future. I think the crucial point
here is section 2.2.3 where the Dynamic Mode Switching is detailed: It refers
to the CLIENT switching between both operational modes. From line 404 onwards
it also goes into detail with respect to the behaviour of the TARGET SERVICE:
Merely saying that the target service does not explicitly track the presence of
a DP in the ad-hoc mode as opposed to the client (for complexity reasons). But
the section at this point lacks any information on mandatory behaviours of the
DP! It details both the client and the target service but not the DP. I suggest
adding a short paragraph or even only one sentence saying something like: “In order to fully
support/enable the Dynamic Switching Mode on the network the endpoint with Discovery
Proxy role MUST serve both operational modes (ad-hoc and managed)
simultaneously.” (Please take the exact
wording only as a rough proposal.) I think this would make
the specification a little more precise with respect to the DP and would lead
to less confusion in later sections (5.2.3 etc.). I am looking forward to
hear your comments on this and thanks again for your precise explanations, Jens PS: I would also be
available for further discussion on this via telephone on Monday from 9:00PM
Pacific Time, hope this is not too late?! -- Von: Vipul Modi
[mailto:Vipul.Modi@microsoft.com] Hi Jens, Thanks for the comments. The ad-hoc and managed networks was not
defined clearly in the previous version of the specification. This often resulted
in the obvious association of term “managed” with “Discovery
Proxy” and confusion of terminologies. In this version of specification
we have now defined these terms clearly with respect to the mode in which
endpoints communicate and these definitions are not tied to a presence or
absence of an endpoint of a particular role on the physical network. The term ad-hoc mode and managed mode as
Ram pointed out below, refers to the mode of communication. The ad-hoc communication
mode is related to Discovery messages being sent multicast and the managed
communication mode is related to Discovery messages being send unicast to a
Discovery Proxy. The term ad-hoc network and managed network represents
the network in which the communication is carried out in ad-hoc (multicast) and
managed (unicast) mode respectively. The ad-hoc and managed network refer to
the logical network and separate from the physical network. Note that managed network do require an
endpoint in Discovery Proxy role operating in managed mode. However that same
endpoint with Discovery Proxy role can communicate in an ad-hoc mode (multicast
messages). Thus a presence of a Discovery Proxy endpoint on a physical network
does not define a network as managed network. In-fact on a same physical
network there may be endpoints that are communicating discovery messages in
multicast fashion (ad-hoc mode) and in unicast fashion (managed mode). The
endpoints that are operating in ad-hoc mode are said to be communicating over a
logical ad-hoc network and the endpoint that are operating in managed mode are
said to be communicating over a logical managed network. I am looking forward to hear your
comments. Thanks, Vipul From:
Ram Jeyaraman Hi Jens, Thanks for the comments! The WS-DD TC had earlier discussed this question about
what constitutes a managed network and clarified the definitions for ad hoc and
managed network as follows [1]. A managed network is a logical grouping
determined by the type of the communication (unicast or multcast) used by the
participating nodes in the network and not by the mere presence or absence of a
discovery proxy in the physical network. I would like to hear your thoughts on this. Would you be open to further discussing this via
telephone sometime on Monday, if possible? I am available on Monday @ 7:30AM Pacific Time or
after 8PM Pacific Time. Would any of those times work for you? Thanks. [1] Clarified definitions Ad hoc Mode An operational mode of discovery in which the Hello,
Bye, Probe and Resolve messages are sent multicast. Managed Mode An operational mode of discovery in which the Hello,
Bye, Probe and Resolve messages are sent unicast to a Discovery Proxy. Ad hoc Network A network in which discovery is performed in an ad hoc
mode. Managed Network A network in which discovery is performed in a managed
mode. -----Original Message----- Hi Everyone, Please defer discussions on this issue until a time
this issue is accepted and is assigned a number. Document: Web Service Dynamic Discovery (WS-Discovery)
V1.1 Public Review Draft (http://docs.oasis-open.org/ws-dd/discovery/1.1/pr-01/wsdd-discovery-1.1-spe c-pr-01.pdf) Location (defaults to line number): Multiple
occurrences Owner: Jens Schmutzler The definition of the Ad-Hoc and Managed Mode is
slightly misleading in the current draft: A Client being capable of the Dynamic Switching Mode
(section 2.2.3) would never(!) switch from Ad-Hoc to Managed Mode if it
joins a network where a Discovery Proxy (DP) is running in Managed Mode (see
section 5.2.3). The current draft of the spec only specifies a DP-Hello in
response to Client-Side Multicast Probe for the DP in Ad-Hoc mode
(see section 5.2.3). The current wording does not explicitly exclude this behaviour,
but the following wording would improve consistency of the
specification, as it applies this behaviour to both Ad-Hoc and Managed Mode
for the DP and not only to the Ad-Hoc mode. It basically moves the second
bullet point from the Ad Hoc mode to the top in order to be applicable for
both modes. Proposed Resolution: Proposed wording for 5.2.3 (from line 950): " A Discovery Proxy MAY be configured to reduce
multicast traffic on both ad hoc and managed networks, in this capacity, a
Discovery Proxy MUST listen for multicast Probe for other Target Services and
respond to them with a Hello message as described in Section 4.1.3 Discovery
Proxy. In an ad hoc mode, - A Discovery Proxy MUST listen for multicast Probe
messages for itself and respond as described in Section 5.3.2 Discovery Proxy.
In a managed mode, - A Discovery Proxy MUST listen for unicast Probe
request and respond to them as described in Section 5.3.2 Discovery
Proxy. " Same change would also apply to sections: - 5.3.2 (Probe Match - Discovery Proxy) - 6.2.3 (Resolve - Discovery Proxy) - 6.3.2 (Resolve Match - Discovery Proxy) Consequently section 4.1.3 and 4.2.3 also need to be
reordered: Proposed wording for 4.1.3 (from line 633): " - A Discovery Proxy MAY be configured to reduce
multicast traffic on both ad hoc and managed networks, in this capacity: - A Discovery Proxy MUST listen for multicast
Hello messages and store (or update) information for the corresponding Target
Services. - A Discovery Proxy MUST listen for multicast
Probe (and Resolve). In response to any multicast Probe (or multicast Resolve)
from a Client, a Discovery Proxy MUST send a unicast Hello to the
Client and SHOULD send the Hello without waiting for a timer to elapse. In an ad hoc mode, - A Discovery Proxy MUST send a Hello for itself (as a
Target Service of d:DiscoveryProxy type) as described in Section 4.1.1
Target Service. In a managed mode, - A Discovery Proxy MUST listen for unicast Hello
messages and store (or update) information for the corresponding Target
Services. " Proposed Wording for 4.2.3 (from line 775): " - A Discovery Proxy MAY be configured to reduce
multicast traffic on both ad hoc and managed networks, in this capacity: - A Discovery Proxy MUST listen for multicast
Bye messages, marking or removing corresponding information as invalid. In an ad hoc mode, - A Discovery Proxy SHOULD send a Bye for itself (as a
Target Service of d:DiscoveryProxy type) when it is preparing to leave
the network as described in Section 4.2.1 Target Service. In a managed mode, - A Discovery Proxy MUST listen for unicast Bye
messages, marking or removing corresponding information as invalid. " Alternatively, section 2.2 could state that the
Discovery Proxy always MUST implement both Ad Hoc and Managed Modes. Then and only
then the following sections would be consistent with section 2.2 to
2.2.3. We are currently in the development of a Discovery
Proxy for the SOA4D DPWS4J stack following the draft specification, where
we stumbled across this issue. Thanks a lot for all the good work in the WS-DD TC! Best Regards, Jens Schmutzler (member of the IST-MORE consortium) -- Dipl.-Ing. Jens A. Schmutzler Communication Networks Institute (CNI) Otto-Hahn-Str. 6 44227 Room: C1-04-176 Fon: +49 (231) 755-3781, Fax: -6136 EMail: jens.schmutzler@tu-dortmund.de Web: (www.cni.tu-dortmund.de) -- This publicly archived list offers a means to provide input
to the OASIS Web Services Discovery and Web Services Devices
Profile (WS-DD) TC. In order to verify user consent to the Feedback
License terms and to minimize spam in the list archive, subscription is
required before posting. Subscribe: Unsubscribe:
ws-dd-comment-unsubscribe@lists.oasis-open.org List help: ws-dd-comment-help@lists.oasis-open.org List archive:
http://lists.oasis-open.org/archives/ws-dd-comment/ Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf List Guidelines:
http://www.oasis-open.org/maillists/guidelines.php Committee:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-dd |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]