An Extension to the REsource LOcation And Discovery (RELOAD) Protocol to Support Relay Peer Routing
draft-ietf-p2psip-rpr-11

I support Martin's DISCUSS points.

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.

Thank you for addressing my concerns!

- 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.)