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

[Yoram Bernet <yoramb@microsoft.com>]

Ron et al:

Comments on your comments below...

> point 1: alternate proposal:
> 
> Instead of extending the error object, allow the application to add a 
> policy object reformatting the Path message as a 
> send/do-not-send question.

I don't see the advantage of this alternative. I do see two disadvantages:

1. It requires more work on behalf of the applications - instead of just
learning the network's policy in response to the same standard path message
that applications currently generate, they would have to generate a new and
special path message. 

2. It would complicate the protocol exchange - instead of relying solely on
a response from the network indicating that the network does not want the
app to send, this would require both a query from the application and a
response from the network. 

> Applications that are going to send the traffic anyhow, will 
> always ask the 
> 'do you allow me to send' question, because that is all they 
> need to know.
> 
> Applications that are going to use alternatives (renegotiate 
> TSPEC, use a 
> different route) are going to ask only admission control 
> questions, and are 
> not going to start sending prior to receiving a successful 
> Resv message. 
> Therefore, these applications will use the standard RSVP Path / Resv 
> procedure, and nothing need to be extended for them.
> 

I'm not sure why it is necessary to pigeonhole applications as one or the
other. The same application may use different strategies at different times.
For example, an application might try lesser codecs until it finds that none
are acceptable by the network, at which time it would just not send (or
alternatively, send with best-effort). Such an application is both of the
type that is going to send anyhow (unless prohibited) and simultaneously of
the type that is going to renegotiate. Again - the distinction you draw
seems to just complicate the set of application behaviours. 

> Another good aspect of this proposal that the PEP/PDP knows from the 
> request the capabilities of the application, as they see the 
> new policy 
> object carried in the Path message. This is lacking in the 
> current proposal.

It is true that this alternative would give the PEP/PDP some explicit
information about the application. However - i'm not sure what the PEP/PDP
would do differently based on this information. Unless the PEP/PDP does
something useful and different, i'm not sure that this justifies the
additional protocol exchange.


Yoram