Subject: RE: [Sipping] I-D ACTION:draft-rosenberg-sipping-session-policy-r eq-00.txt

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 7 Jan 2003 11:58:23 -0500

Agree.  I specifically want to have the mechanism allowed to
specify the bandwidth parameters (I ask for a 6MB video stream,
the proxy tells me I can only send 4, everything else is the same).
So, is this in scope or out?

I'll point out that this is an interesting one because there is no
middle box; there is simply a bandwidth manager that is doing
something much better than simplistic call admission control. However,
I don't see any reason to judge why one SDP parameter is subject
to policy, and another one is not.  

Brian

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Tuesday, January 07, 2003 11:38 AM
> To: Jonathan Rosenberg
> Cc: [email-masked]
> Subject: Re: [Sipping] I-D
> ACTION:draft-rosenberg-sipping-session-policy-req-00.txt
> 
> 
> This document provides many detailed requirements. But I am 
> still left 
> with a feeling of uncertainty about the overall scope. For instance:
> 
> - I'm not sure what is in scope and out of scope for a media 
> policy. Is 
> there anything that can be negotiated via an offer/answer 
> exchange that 
> is out of scope? Certain specific features that are encoded 
> in SDP are 
> called out specifically. This might imply that it is intended that 
> features not mentioned are out of scope.
> 
> An example of a specific feature not mentioned, is the a=direction 
> attribute used by comedia. It is possible to imagine an intermediate 
> node might want to alter an a=direction:both to be only 
> a=direction:active. Does this need to be listed as a 
> requirement before 
> it can be addressed by policy?
> 
> I am somewhat concerned that this is a slippery slope. Unless we can 
> clearly define what is in scope and what is out, I think we will find 
> that we are simply defining a new representation of SDP, one 
> syntactic 
> element at a time. At the least, this seems to require a sort of 
> meta-model for offers and answers that transcends SDP and SDPng.
> 
> - Continuing the scope question a bit, is there any intent to support 
> policies that can't already be expressed via an offer/answer 
> exchange? 
> (I don't think so, but just checking.)
> 
> - There is much mention of proxies as the nodes that want to specify 
> policy. But I think there are other kinds of servers that may 
> also take 
> on this role. Specifically, a B2BUA may also want to work 
> cooperatively 
> with the endpoints in same way. Of course a B2BUA already has more 
> capabilities to modify the SDP directly, but it may want to be more 
> subtle and friendly in its manipulations. For instance, this 
> mechanism 
> may permit a more extended pre-alert negotiation than is currently 
> possible. So I would like to see these requirements phrased 
> to permit a 
> B2BUA as a policy setter if that makes sense.
> 
> 	Paul
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 24 Jan 2003 22:21:19 -0500

> So, is this in scope or out?

I'd be happy to add it in.

> to policy, and another one is not.  

Well, I am willing to consider that this itself may be a requirement, 
i.e., that its a requirement for a proxy to be able to ask the client to 
do any specific modification to its SDP. However, generally a 
requirements process is about determining exactly what the real problem 
is, and not putting in everything under the sun. Practically speaking, I 
suspect proxies really are interested in a limited number of things. SO 
long as the mechanism is extensible to other aspects of the session, is 
there really a compelling need to support everything at the outset?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com