Re: [ws-dd] Issue 010 - Clarify handling of multihomed devices

[Antoine Mensch <antoine.mensch@odonata.fr>]

Please find attached a document further discussing this issue. This 
document also covers Issues 008 and 017.

Antoine Mensch

Antoine Mensch a écrit :
> Additional info:
> Impact: Implementation change
> Urgency: High
> Priority: High
>
>
> Ram Jeyaraman a écrit :
>> 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
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>   
>> ------------------------------------------------------------------------
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - http://www.avg.com Version: 8.0.169 / Virus 
>> Database: 270.6.21/1674 - Release Date: 16/09/2008 08:15
>>
>>   
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com 
> Version: 8.0.169 / Virus Database: 270.7.4/1695 - Release Date: 27/09/2008 13:11
>
>

Transport addresses issues.docx