Subject: RE: [Sip] The Problem with PRACK

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Thu, 16 Mar 2006 18:08:51 -0000

Part of Juha's simplifications also assume that the charging models used by various 3gpp operator's are invalid.

As IETF has not specified a charging model for SIP, or the resources under the control of SIP, and does not intend to, I would suggest that we have to assume there is no such restriction, and therefore have to make sure our protocol supports a multitude of charging cases.

If we wish to start providing such restrictions, then I would suggest IETF needs to specify the charging model as a means of identifying those restrictions. However I do not think this is likely to occur.

regards

Keith

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: 16 March 2006 13:49
> To: Juha Heinanen
> Cc: [email-masked]; Brett Tate; Christer Holmberg (JO/LMF); Dean Willis
> Subject: Re: [Sip] The Problem with PRACK
> 
> 
> 
> 
> Juha Heinanen wrote:
> > Paul Kyzivat writes:
> > 
> >  > Well, I'm pretty sure PRACK was created before 
> SUBSCRIBE. Does that mean 
> >  > that we should trash SUBSCRIBE too?
> > 
> > if you could have implemented same functionality with existing SIP
> > requests, which is not likely with subscribe, but is likely 
> with PRACK.
> 
> I guess then that the entire WG was really very stupid to 
> have approved 
> RFC3262.
> 
> >  > Nobody has come up with a case where PRACK can't be 
> replaced by some 
> >  > other vaguely specified hypothetical new extension to 
> sip. That isn't a 
> >  > fair comparison.
> > 
> > you can dump PRACK for resource reservation without ANY 
> extension to SIP
> > as i have shown in earlier messages.  it was 3gpp folks 
> that defended
> > PRACK on the basis of resource reservation, and they claims 
> turned out
> > to be false.
> 
> I am not trying to defend the 3gpp people. But you haven't 
> proven that 
> their claims are false. You have shown that with a particular set of 
> simplifying assumptions about the problem space you can do 
> without PRACK.
> 
> I think there must be a higher bar for deprecating an RFC.
> 
> I now understand that Rohan is advocating something much less 
> than that. 
> Even that needs good justification, but might be easier to achieve.
> 
> 	Paul
> 
> >  > So we are stuck for now with evolutionary changes. 
> Incompatible changes 
> >  > are hard to do.
> > 
> > evolution in should also mean deprecating bad ideas, not 
> all the time
> > adding new RFCs to the pile.
> > 
> > -- juha
> > 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Dean Willis <[email-masked]>
Date: Thu, 16 Mar 2006 15:18:42 -0600

On Mar 16, 2006, at 12:08 PM, Drage, Keith (Keith) wrote:

> Part of Juha's simplifications also assume that the charging models  
> used by various 3gpp operator's are invalid.
>
> As IETF has not specified a charging model for SIP, or the  
> resources under the control of SIP, and does not intend to, I would  
> suggest that we have to assume there is no such restriction, and  
> therefore have to make sure our protocol supports a multitude of  
> charging cases.
>
> If we wish to start providing such restrictions, then I would  
> suggest IETF needs to specify the charging model as a means of  
> identifying those restrictions. However I do not think this is  
> likely to occur.
>
> regards
>

I'll take it the other way. We have no fundamental requirement, in  
IETF, of even assuring that ANY charging model might possibly be made  
to work. It is simply not a constraint on our work. Now, where we  
have agreed to accept specific external requirements or have provided  
our own requirements, then we would, but only to the extent raised by  
those agreed requirements. Have we done that for SIP?

Personally, I have always argued that anybody attempting to do  
charging off of SIP-level transactions (for anything more than the  
delivery of those transactions) is making a fundamental mistake and  
that the evolution of the protocol is likely to break their  
assumptions, SO DON'T DO IT!

--
Dean