Resource Reservation Protocol (RSVP) Proxy Approaches
draft-ietf-tsvwg-rsvp-proxy-approaches-09

Nits to fix if you have to do a respin or in AUTH-48 if the RFC Editor
misses them.

draft-ietf-tsvwg-rsvp-proxy-approaches-06.txt
---
I am surprised that all of your references are Informative. Surely some of these are prerequisites for understanding your work?
---

4.3.  Inspection-Triggered Proxy

 [...]

   Note however, that in case of reservation failure, the inspection-
   triggered RSVP Proxy does not have a direct mechanism for notifying
   the application (since it is not participating itself actively in
   application signaling) so that the application is not in a position
   to take appropriate action (for example terminate the corresponding
   session).  To mitigate this problem, the inspection-triggered RSVP
   Proxy may mark differently the DSCP of flows for which an RSVP

The first use of the DSCP acronym should be expanded.


I am also agreeing with Adrian's comment, I was wondering about this myself.

In Section 4.5: 

   Candidate protocols for realizing such interface
   include SNMP ([RFC3416]), COPS-PR ([RFC3084]), QPIM ([RFC3644]), the
   Extensible Markup Language (XML) and DIAMETER ([RFC3588]).  

SNMP is seldom used for configuration purposes over the Internet in real life. COPS-PR has very little reported deployment if at all. XML is manguage to present information and not a protocol. 

I suggest to take out XML, and to consider whether SNMP and COPS-PR should be left in the text. On the other hand I believe that it would be appropriate to mention here NETCONF (RFC 4741) which is a protocol that uses XML-encoding for performing configuration management operations on network devices.

In section 4.1, the paragraph immediately following figure 3 explains that receipt of a ResvErr by the RSVP Receiver Proxy "ensures that the RSVP Receiver Proxy is aware of the reservation failure, conventional RSVP procedures do not cater for notification of the sender of the reservation failure."  It's not clear to me why the sender needs to be notified of reservation failure.  Is this addressing a problem with RSVP generally or just RSVP Receiver Proxy?  I speculate that the problem here may be that the Proxy receives the ResvErr, so neither the application receiver nor the sender is explicitly notified of the reservation failure; do I have that right?  Would someone more familiar with RSVP than I am be able to deduce the reason for sender notification?  I'm happy to be educated as I'm not well-versed in RSVP.

Nit: "cater for" might read better as "cater to" or "provide for"

Agree with Tim's concern #2 (what happens when you unintentionally (or intentionally) end up with more than one proxy in a path?

I am concerned that RSVP in general allows hosts to send something that the router has to receive in its control plane, which opens up the possibility of DOS attacks by the hosts against the routers. Given the current state of host security, it is pretty much a non-starter to let millions of hosts send anything to the router's control plane. The result is that service providers won't allow RSVP packets across the CE/PE boundary (or just tunnel them over the network). 

I am not aware of this being discussed anywhere. I think that this general issue is worth writing up in more detail. 

I am putting this in as a comment, rather than a DISCUSS, since this is not specific to RSVP proxy. It is a basic issue with RSVP (which of course is water than went over the dam a very long time ago). Thus it is not at all clear that this document is the right place to discuss this issue.

section 1:

"presents several fundamental RSVP proxy approaches insisting on how ..."

I don't think "insisting" is the right word here!

section 4.4:
s/cortresponding/corresponding/
s/implicitely/implicitly/