#25 Configuration Option "reduce multicast Traffic" for DiscoveryProxies should be removed!

[Björn Engelmann]

Background:
MDPWS includes WS-Discovery 1.1.
Unfortunately, WS-Discovery contains problems, but cannot be revised as its authors have lost interest in working on it. In order to get an interoperable Discovery Protocol, I would hence suggest to keep including WS-Discovery 1.1, but to fix its issues by overriding some of its Requirements in MDPWS.

Now to the problem:
WSDD_539 in Section 4.1.3 of the WS-Discovery Standard (version 1.1) states
"… A Discovery Proxy MAY be configured to reduce multicast traffic on an ad hoc network, 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."

From this it follows that there is a boolean-valued Configuration Option named "reduce multicast traffic" for DiscoveryProxies.
The Proxy (amongst others) answers multicast Probe messages with a unicast Hello iff this Option is set to "true". We can deduce that there are also Proxies that are configured NOT to reduce multicast traffic and thus NOT answering multicast Probe messages (at least such an implementation would be standard-compliant). In a managed-mode network with such a Proxy,
the multicast Probe messages sent by Clients in ad-hoc mode hence do not lead to this Client being switched to managed mode by receiving an unicast Hello message from the DiscoveryProxy. Consequently, Clients that entered the network after the DiscoveryProxy and hence missed its initial Hello message remain in ad-hoc mode and continue sending multicast Probes although Target Services in a managed-mode network are not answering these according to WSDD_368 in Section 2.2.3.

We can hence see that Discovery in a managed-mode network is dysfunctional when the Proxy does not answer multicast Probe messages. This behaviour is hence essential rather than optional. Providing a Configuration Option for essential behaviour does not make sense and I hence recommed removing the Option and making it mandatory for a DiscoveryProxy to answer multicast Probe messages by simplifying the above Requirement to

"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."