Hi Bruce, Inline Roni > -----Original Message----- > From: Bruce Lowekamp [mailto:[email protected]] > Sent: Wednesday, July 15, 2009 6:06 AM > To: Roni Even > Cc: [email protected] > Subject: Re: [P2PSIP] Relay support in draft-jiang-p2psip-relay-02 > > I would like to see a couple changes in how the ideas in this draft > are implemented, but the concepts are basically sound. I would > support adopting this draft as an extension. > > Section 3 should probably reflect in its discussion that the DRR and > RPR responses require the establishment of a (D)TLS session before the > message is exchanged. I think a precise analysis of the cost isn't > necessary, but the diagrams are a bit misleading in how many messages > are involved.
You are right that the responder needs to establish (D)TLS session. We can add text explaining the link layer behavior for the response. It can also be used to find out if DRR connectivity exists. > > In Section 5.2, why not implement IGNORE-STATE-KEEPING as a > ForwardingOption with FORWARD_CRITICAL? The WG can then discuss > whether to incorporate that into the base draft or leave it as an > extension. Parenthetically, the state to be concerned about is not so > much the hop-by-hop retransmission, but state that may be kept if the > peer is keeping per-transaction forwarding state rather than encoding > it in the via-list. I think that is what 5.2.1 says we will put the right language. The current text meant to have it in the forwarding option flags but the note asks if it should be specified in the forwarding option in the base draft. Maybe this should be discussed in a separate thread with reload base as the topic. I think that there are two questions here 1. Should this flag be part of forwarding option flags in base draft. There is no registry for the flags 2. Should this flag be part of forwarding header since it may have other uses. > > Also in 5.2, with the changes in the via list structure, I think we > need to revisit adding an IP address as a DestinationType in an > extension. I think the ForwardingOption works, but it smells a bit > too much like a hack to me. This may be a good solution for DRR but I am not sure if it will work for the relay peer case since the relay may be used only in the response. Also the peer that sends the response will not know who is the relay from the via/destination list and the relay need to know who is the final receiver. So there is a need to give the response path which is not defined in base draft. The use of the ForwardingOption is the way to extend the forwarding header. > > Bruce _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
