I support this. Bruce
On Wed, Dec 15, 2010 at 4:01 PM, David A. Bryan <[email protected]> wrote: > I think I would be most happy with your suggestion: > >> There's another option where we add a ForwardingOptions flag to the >> base draft that specifies not to keep state about the message, but >> isn't explicitly a DRR flag. There might even be a benefit to doing >> that, in that it wouldn't be explicitly tied to the DRR mechanism in >> there now. > > I think this is exactly what I would like to see. > > My concern with the present routing mechanism is it is a bit > underspecified, and also that if we later flesh out a more detailed > one, there will be confusion. I definitely don't want to remove the > routing stuff completely -- we clearly need the flags -- but think the > current attempt at using it for direct routing is a bit > underspecified. I'd rather remove it (leaving the mechanism) so we can > get the next version out with as few changes as possible, and get > RELOAD published so we can move on to other work. > > David (as individual) > > > On Thu, Dec 2, 2010 at 1:53 PM, Bruce Lowekamp <[email protected]> wrote: >> The motivation for putting it into the base draft was that if it is >> part of the base spec, then in the future nodes that implement >> whatever is specified in the relay/DRR draft can make use of those >> techniques while on an overlay with nodes that only implement the base >> draft. For example: >> >> - any sort of relay/DRR requires intermediate nodes to not keep any >> state about routed messages. If support for the routing flag that >> allows this is not in the base draft, they will have to simply reject >> the message. >> - knowledge of how to set up a relay node isn't required to make use >> of the relay node. >> >> The intention of the current text was that it could currently only be >> used with no-ice. But it would provide support so that nodes that >> only implement the base draft would be able to forward messages using >> relay/DRR and would also be able to send messages to a relay node in >> the future without knowing the details of how that is set up. As >> currently specified, it definitely needs some text stating explicitly >> that it can currently only be used with no-ice. >> >> There's another option where we add a ForwardingOptions flag to the >> base draft that specifies not to keep state about the message, but >> isn't explicitly a DRR flag. There might even be a benefit to doing >> that, in that it wouldn't be explicitly tied to the DRR mechanism in >> there now. >> >> Or , of course, we can remove it completely, at the cost that base >> nodes won't be compatible with whatever is done in the relay/DRR >> draft. >> >> Bruce >> >> >> On Tue, Nov 30, 2010 at 8:03 AM, David A. Bryan <[email protected]> wrote: >>> 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 >>> >> > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
