An Extension to the REsource LOcation And Discovery (RELOAD) Protocol to Support Direct Response Routing
Note: This ballot was opened for revision 11 and is now closed.
(Gonzalo Camarillo) Yes
(Spencer Dawkins) (was Discuss) Yes
Thank you for addressing my Discuss questions, which were (just tor the record): I'm looking at http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-p2psip-rpr-11.txt&url2=http://tools.ietf.org/id/draft-ietf-p2psip-drr-11.txt and seeing a lot of duplication between these drafts. That could be OK, although some protocol machinery looks like it's defined in both drafts (for instance, 0x08 IGNORE-STATE-KEEPING), but what I hoped to see is some discussion of RPR versus DRR - when you implement RELOAD, does it make sense to pick either RPR or DDR, and then fall back to SSR, or would you expect anyone to implement both SRR and RPR, or even attempt both in succession before falling back to SSR? I would guess that attempting DDR (directly route the reply), then attempting RPR (route using a relay), and only then falling back to SSR would make sense. Is there any guidance you can give? You'll notice I'm a coauthor on http://tools.ietf.org/html/draft-ietf-p2psip-concepts-05, so if you tell me "there's no energy for new text", I'll believe you, but I wanted to ask ... Original Comment: In Section 2, it would be helpful to me, to include a description of RPR. I know that's described in another specification, but RPR is referenced throughout this one.
(Jari Arkko) No Objection
(Richard Barnes) No Objection
(Stewart Bryant) No Objection
(Adrian Farrel) No Objection
(Stephen Farrell) No Objection
- DRR involves sending the client IP address out to the network. Is that different from base RELOAD? If so, then that privacy-relevant difference should be noted, but I've not had time to check the base RELOAD (this would be a DISCUSS if I had time to check and figured that it is different). Is this a new consideration? - Could checking for DRR, but then falling back to SRR, involve sending out the client IP address in a way different from base RELOAD? (Same as above, no time to check, sorry;-) - The diff  between this and RPR is interesting. There are common bits of specification but its not clear to me which RFC will be normative, e.g. for the IGNORE-STATE-KEEPING flag. That doesn't seem like a good plan, but I'm not sure what'd be best to do about it.  http://tools.ietf.org/rfcdiff?url1=draft-ietf-p2psip-rpr-11&url2=draft-ietf-p2psip-drr-11.txt
(Brian Haberman) No Objection
(Joel Jaeggli) No Objection
Barry Leiba No Objection
(Ted Lemon) No Objection
In section 1, last paragraph: networks. An extension to RELOAD to support DRR is proposed in Section 6. Some optional methods to check peer connectivity are I think you should say "defined" rather than "proposed", to avoid misunderstandings. This is consistent with the text in section 6. Why don't tables 1 and 2 also list performance for SRR+DTLS? Also, probably a naive question, with DTLS+DRR, is every message after the first sent directly from the sending peer to the destination peer? This seems obvious—if DRR succeeded, why not? But it's never mentioned in the document, so perhaps I am missing something?
(Pete Resnick) No Objection
(Martin Stiemerling) (was Discuss) No Objection
Thank you for addressing my concerns!