An Extension to the REsource LOcation And Discovery (RELOAD) Protocol to Support Direct Response Routing
draft-ietf-p2psip-drr-11
Yes
(Gonzalo Camarillo)
No Objection
(Adrian Farrel)
(Barry Leiba)
(Brian Haberman)
(Jari Arkko)
(Joel Jaeggli)
(Pete Resnick)
(Richard Barnes)
(Sean Turner)
(Stewart Bryant)
Note: This ballot was opened for revision 11 and is now closed.
Gonzalo Camarillo Former IESG member
Yes
Yes
()
Unknown
Spencer Dawkins Former IESG member
(was Discuss)
Yes
Yes
(2014-02-27)
Unknown
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.
Adrian Farrel Former IESG member
No Objection
No Objection
()
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
()
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
()
Unknown
Martin Stiemerling Former IESG member
(was Discuss)
No Objection
No Objection
(2014-03-02)
Unknown
Thank you for addressing my concerns!
Pete Resnick Former IESG member
No Objection
No Objection
()
Unknown
Richard Barnes Former IESG member
No Objection
No Objection
()
Unknown
Sean Turner Former IESG member
No Objection
No Objection
()
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2014-02-06)
Unknown
- 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 [1] 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. [1] http://tools.ietf.org/rfcdiff?url1=draft-ietf-p2psip-rpr-11&url2=draft-ietf-p2psip-drr-11.txt
Stewart Bryant Former IESG member
No Objection
No Objection
()
Unknown
Ted Lemon Former IESG member
No Objection
No Objection
(2014-02-05)
Unknown
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?