[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [internal] RE: Proposal for managed mode cluster of issues
Thanks for reviewing the proposal and providing the feedback. Please see inline for my comments.
Some comments / questions on the Proposal for managed mode cluster of issues...
4.1 Hello “In a managed mode, all transport address(es) SHOULD be
[Vipul Modi] In an ad hoc mode, implementations may want to limit the content of the packet so as not to exceed MTU. However as you noted down below this could save some Probe/Resolve. This is a change in the existing behavior and potentially existing implementations. I would recommend that we track this as a separate issue and tackle it after CD1.
[Vipul Modi] I believe this is already covered as part of the issue Antoine filed last week, Issue 078.
[Vipul Modi] Thanks for catching this. I also missed this in the normative outline of the Hello, Bye, PM and RM.[Vipul Modi] I have updated the proposal.
[Vipul Modi] As mentioned above let’s track this as a separate issue.
[Vipul Modi] In a capacity of a multicast suppression agent yes, otherwise it is acting as a target service advertising its managed endpoint.
[Vipul Modi] Yes the Discovery Proxy should include all the information. Thanks for raising this, it means that this is not very clear from the specification. The PM and RM sections refer to Hello, which clearly says that all information should be included in the managed mode. I have added statement in the Discovery Proxy section of Probe Match and Resolve Match to make this clear.
The figure is showing all possible message exchange patterns. It does not indicate any sequence. Say a client knows about a Target Service (saved Printer), the client now joins a network, find a DP. It does not need to send Probe, it can simply send Resolve.
[Vipul Modi] The multicast Probes? In that case the Target Service is also continuing to operate in an ad hoc mode as well. So no it would not ignore them, it would respond them normally. See the comment below for more clarification.
[Vipul Modi] A Target Service can operate in an ad hoc mode, a managed mode or both depending upon its configuration. The specification describes the protocol in both modes. As I mentioned in the primer comments, a higher level specification may restrict that for example all Devices MUST support at least ad hoc mode.
[Vipul Modi] This depends upon the implementation and configuration of the Target Service. For example, some Target Service may choose to operate in both mode, some may operate only in managed mode if they are configured to do so. The specification currently describes a mechanism for client to know about proxy when they send multicast Probe and Resolve, the clients then can decide if they want to switch or continue to operate in an ad hoc mode or operate both in an ad hoc and managed mode.
From: Vipul Modi [mailto:Vipul.Modi@microsoft.com]
Please find attached documents that incorporate the proposal for the following “managed cluster” issues.
022 request-response MEP for communicating with proxy
034 Discovery proxy and multicast suppression requirement
035 define protocol assignment/binding for managed mode
036 discovery messages and managed mode
049 forced managed mode transition for the client
Following documents are attached with this email:
1. wsdd-discovery-1.1-spec-wd-02-managed-02.docx: Includes the proposed changes with change bars. Note that some of the links may be broken or you might see some weird formatting of the text within the change bars. These gets fixed when the changes are accepted (see document 2).
2. wsdd-discovery-1.1-spec-wd-02-managed-02-nochangebars.docx: Includes the proposed changes without any change bars.
3. wsdd-discovery-1.1-wsdl-wd-02-managed.wsdl: Modified WSDL file