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

[Dan Romascanu <dromasca@avaya.com>]

	[Dan] I try to be cautious and hope to avoid entering some
'religious' discussion :-)
	  
> These are not *absolutely necessary features*.
> Issues concerning integration of QoS (RSVP) and
> VoIP (as well as AAA) have been the focus of
> work by a number of people for quite some time
> now. See the following drafts, submitted to the
> SIP (Session Initiation Protocol) working group.
> 
> draft-gross-sipaq-00.txt
> draft-gross-cops-sip-00.txt
> draft-sinnreich-aaa-interdomain-sip-qos-osp-00.txt
> draft-sinnreich-interdomain-sip-qos-osp-01.txt
> draft-sinnreich-johnston-sip-osp-token-00.txt
> 
> No extensions or modifications to RSVP need to be made.
> 
> A snippet from the santitoro draft:
> 
> > The first ErrorValue informs the sending application that it MUST NOT
> > send the traffic described in its PATH message. The second ErrorValue
> > informs the sending application that prioritized resources are not
> > available but that it may proceed to send with no resource guarantees.
> > (The ErrorValues are intended to be included in PATH_ERR messages, in
> > response to corresponding PATH messages).
> 
> Both of these cases have already been addressed.
> draft-sinnreich-interdomain-sip-qos-osp-01.txt discusses
> in detail two QoS models: QoS Assured and QoS Enabled.
> The QoS assured model only completes call setup if/when
> QoS has been established. In this case, the sender does
> not send until/unless QoS has been established. The QoS
> enabled model completes call setup regardless. In this
> case, the user wants the call to proceed before QoS has
> been granted and even if QoS is never granted for the
> session.
> 
> draft-gross-sipaq-00.txt defines a COPS extension for
> SIP to integrate policy (and AAA) messaging into the VoIP
> picture. See draft-gross-sipaq-00.txt for a general
> overview.
> 
	[Dan]  The reason why I personally did not look previously at the
drafts that you point to is related to the fact that SIP is not right now in
my focus. The five drafts that you refer seem all to assume the use of SIP
and propose SIP-related extensions. The approach taken by
draft-santitoro-rap-policyerrorcodes-01.txt seems to avoid such an
assumption and this is the reason for proposing a solution at the level of
RSVP error values. I did not think by myself long enough to decide that this
is the 'only' or the 'preferred' solution, but it works in these
environments that do not implement SIP.

	Regards,

	Dan