Issue 010 - Clarify handling of multihomed devices

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

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

-----Original Message-----
From: Antoine Mensch [mailto:antoine.mensch@odonata.fr]
Sent: Tuesday, September 16, 2008 3:30 PM
To: Ram Jeyaraman
Subject: NEW Issue - Clarify handling of multihomed devices

Please defer discussions on this issue until a time this issue is
accepted and is assigned a number.

Document: WS-Discovery
Location : Global
Owner: Antoine Mensch

Description:
When a target service may be reached through several transport
addresses, for instance when using multiple network interfaces for a
device, it is not clear whether it is the responsibility of the service
or the client to select the appropriate transport address for
communication. For instance, the service could publish all its transport
addresses to the client and let the client decide which ones are
reachable, or it could use network adapter information to send Hello,
ProbeMatches and ResolveMatches messages containing only the transport
addresses corresponding to the network interface being used for sending
the messages. Similarly, IPV4 Probes/Resolves could be answered with
ProbeMatches/ResolveMatches containing only IPV4 transport addresses.
This lack of precision creates interoperability issues: for instance,
our experience with the Windows Vista Network Explorer is that it will
not select the best transport address when presented with multiple
transport addresses, some of which being not reachable. On the other
hand, maintaining separate versions of a service metadata information
for different network interfaces could quickly become a nightmare, as we
would need some complex rules for incrementing the metadata version and
resending Hello messages when metadata changes (e.g. change of network
address) only affect one network interface.

Proposed resolution:
To be discussed