OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-dd message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]