An Extension to the REsource LOcation And Discovery (RELOAD) Protocol to Support Direct Response Routing
RFC 7263

Note: This ballot was opened for revision 11 and is now closed.

(Gonzalo Camarillo) Yes

(Spencer Dawkins) (was Discuss) Yes

Comment (2014-02-27)
No email
send info
Thank you for addressing my Discuss questions, which were (just tor the record):

I'm looking at 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, 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

Comment (2014-02-06)
No email
send info
- 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.


(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Barry Leiba No Objection

(Ted Lemon) No Objection

Comment (2014-02-05)
No email
send info
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

Comment (2014-03-02)
No email
send info
Thank you for addressing my concerns!

(Sean Turner) No Objection