RE: draft-santitoro-rap-policy-errorcodes-01.txt

[Ron Cohen <ronc@cisco.com>]

I think that this draft deserves working group attention and discussion. 
I'm not sure whether it should be a working group item yet.

Here are some basic questions about this draft:

1. I don't agree with the following text in the draft:

"From the perspective of a sender and a receiver of application traffic, 
the conventional usage of RSVP is as follows:
...
  5. Sender sends traffic regardless of the admission control decision. "

I think this indicates a 'bad' RSVP application. If the application 
requires QoS, than it should not 'send it anyway', but rather either 
renegotiate TSPECs or turn to an alternative. For example, if you want to 
run a VoIP flow, and get a QoS refusal, you would than turn to send it via 
PSTN.


2. In the description of the alternatives available today to the network 
administrator to make sure that an application would not send anything 
across the WAN the following option is not mentioned:

Create a 'Discard-on-WAN' PHB, and associate it with a DSCP. Set rules on 
all WAN routers that discard all packets arriving with this DSCP set. 
Return to such applications that send there traffic anyhow this DSCP value 
in the DCLASS object. In this way you are sure that even if the application 
does send the traffic even when QoS is rejected, traffic would be discarded 
on the WAN edge (assuming that at least it conforms with the DCLASS object 
sent to it).

3. It is not explained in the draft why the added values should go into the 
policy error object and not to the error object policy errors as defined in 
appendix A of RFC2750. It does not say what should be carried in the RSVP 
error object

Ron