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. 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. 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. Bruce _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
