I also think the current text is too limiting. The best approach is to make it clear in the draft that other routing techniques are allowed and supported, leave in the flags but remove the very skeletal direct response routing from this draft and we instead do that in the relay/direct response draft.
David (as individual) On Sun, Nov 21, 2010 at 3:04 AM, Roni Even <[email protected]> wrote: > >> >> Direct Response Routing and ICE >> • Specified in §5.3.2.4 >> This option can only be used if the direct-return-response-permitted >> flag in the configuration for the overlay is set to TRUE. The >> RESPONSE_COPY flag SHOULD be set to false while the FORWARD_CRITICAL >> and DESTINATION_CRITICAL MUST be set to true. When a node that >> supports this forwarding options receives a request with it, it acts >> as if it had send an Attach request to the the requesting_node and it >> had received the connection_information in the answer. This causes it >> to form a new connection directly to that node. >> • This doesn’t work with ICE because the sender of the request doesn’t >> have your information >> Proposed Resolution: DRR can only be used with No-ICE >> ***NOTE: This slide generated significant discussion in the meeting. >> There were some comments that this was incomplete, and discussion of >> moving this out of the base draft and into the relay/direct response >> draft. ADDITIONAL DISCUSSION REQUIRED. > > I see the problem and think that we should take this section out from RELOAD > and continue with the individual relay draft (draft-jiang-p2psip-relay-04) > for the use case where the node is not behind NAT or a relay can be used. > In this case we will need to verify that RELOAD allows such extensions and > that there are no issues with supporting it due to some routing assumptions. > > Roni Even > > > > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
