An Extension to the REsource LOcation And Discovery (RELOAD) Protocol to Support Relay Peer Routing
RFC 7264

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

(Gonzalo Camarillo) Yes

(Spencer Dawkins) Yes

Comment (2014-02-03)
No email
send info
In Section 2, it would be helpful to me, to include a description of DRR. I know that's described in another specification, but DDR is referenced throughout this one.

In 3.2.2.  Using bootstrap nodes as relay peers

   Bootstrap nodes are typically publicly reachable in a RELOAD
   architecture.  As a result, one possible architecture would be to use
   the bootstrap nodes as relay peers for use with RPR.  A relay peer
   SHOULD be publicly accessible and maintain a direct connection with
   its client.  

would a relay peer work if it's not publicly accessible?

In 4.1.  How RPR works

   A requirement for RPR is for the source peer to convey their relay
   peer (or peers) transport address in the request, so the destination
   peer knows where the relay peer are and send the response to a relay
   peer first.  The request SHOULD include also the requesting peer
   information enabling the relay peer to route the response back to the
   right peer.

would RPR work if you don't include the requesting peer information?

(Jari Arkko) No Objection

(Richard Barnes) No Objection

(Stewart Bryant) No Objection

(Benoît Claise) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2014-02-06)
No email
send info
- General: RELOAD is now an RFC and should be referred
to as such.

- 5.1: what is N?

- 5.1 last para seems to contain a logical flaw, you say
that RPR can be better or worse than SRR, depending on N,
but you cannot conclude from that that which is better then
does not depend on N, but only on other factors. I think
the text makes that mistake.

- 9: On what basis and for what are we saying that an RPR
relay node "SHOULD be a trusted one"? (That's an odd phrase
in itself.) I can see problems with getting a RELOAD client
to really trust some IP address somewhere in the n/w for
some unstated purpose.

- 9: Presumably an RPR relay is a fine point of attack, esp
if used by many devices. What problems can arise?  I don't
think you say but shouldn't you? (For example, if I wanted
to know who's calling whom and can convince lots of folks
that I'm a good RPR then happy days for me.)

(Note the two last points above are near-discusses, but
I'll leave them as comments for now since I don't recall
if RELOAD covers those issues and haven't time right
now to check. If I get a chance to check before the 
telechat I might make 'em DISCUSS points.)

(Brian Haberman) No Objection

Comment (2014-02-05)
No email
send info
I support Martin's DISCUSS points.

(Joel Jaeggli) No Objection

Comment (2014-02-02)
No email
send info
On Sep 25, 2013, at 8:30 PM, Carlos Pignataro <cpignata@cisco.com> wrote:

> Hi!
>
> As a member of the Operations Directorate I have reviewed the following draft which is in IETF last call for it's operational impact.
>
> This document specifies protocol extensions to RELOAD to allow for a shortcut in the return path. This in turn is advantageous to network administrators from a manageability perspective.
>
> Minor:
>
> The document references the "configuration file", which is defined in [I-D.ietf-p2psip-base]. [I-D.ietf-p2psip-base] is a Normative reference. As a suggestions, perhaps, it could help to clarify where the configuration file is defined (i.e., add a citation to the relevant section of p2psip-base).
>
> Also the document makes a distinction between a managed network versus an open network, but this is not precisely defined in this document. A small definition of what is a "closed" versus "open" network could help, from a manageability standpoint.
>
> Nits:
>
> It is not clear why there is a subsection 3.1.1, when it has the same heading as 3.1, and 3.1 is a single paragraph:
> 3.1.  RPR
> 3.1.1.  Relay Peer Routing (RPR)
>
>    In some mobile deployments, using RPR may help reducing radio battery
>    usage and bandwidth by the intermediate peers.  The service provider
>    may recommend using RPR based on his knowledge of the topology.
>
> "his or her knowledge", as the service provider can be a "he" or a "she".
>
> Hope these are clear and useful!
>
> Carlos.

Barry Leiba No Objection

(Ted Lemon) No Objection

(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