Issue pr008 - WS-Discovery - Clarifications to ad hoc and managedmode definitions

[Ram Jeyaraman <Ram.Jeyaraman@microsoft.com>]

This issue is assigned the number pr008. For further discussions on this issue, please refer to this issue number or use this thread.

-----Original Message-----
From: Jens Schmutzler [mailto:jens.schmutzler@uni-dortmund.de] 
Sent: Friday, April 03, 2009 6:58 AM
To: ws-dd-comment@lists.oasis-open.org
Cc: Damien.LAVAUX@fr.thalesgroup.com
Subject: [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-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)
Dortmund University of Technology
Otto-Hahn-Str. 6
44227 Dortmund
Germany

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: ws-dd-comment-subscribe@lists.oasis-open.org
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