Re: [Sipping] I-D on service identification now available

[Dean Willis <dean.willis at softarmor.com>]

Dean Willis wrote:

> Further, it's why I think the SIP-level signaling should be opaque to  
> the access network provider. It's none of their business, and the  
> current protocol is flawed for having let them into the control channel.

I've caught some considerable flack from people for the above statement, 
 but I'm afraid I must stand by it. I absolutely and totally believe it 
to be true. However, it may perhaps not be clear what I meant.

A model that splits service delivery into "access" and "service" layers 
only works as long as the access network is comepletely transparent to 
the service being delivered.

Once the access network provider starts to restrict service delivery 
functionality to services they can "make a premium" on (or otherwise 
have reason to "understand"), you just don't have the Internet any more.

In short, what happens is that new services can only be delivered with 
the explicit consent of and by arrangement with the access network 
providers. This turns the introduction of a new service into an 
exponential problem, paralyzing the whole system.

Take, for example, HTTP (as Juha mentioned). If every new web 
application had to get explicit buy-in from AOL, UUNET, Sunrise, 
Verizon, Vodafone, DT, BT, FT, and every other access-providing 
organization, there'd never be another web-based application launched. I 
believe it's totally unreasonable to propose this sort of model, and 
will do everything in my power to keep us from heading that way.

Jonathan raised the same question in his response of earlier today:

> Firstly, as you indicate, for these types of services, only the 
called > domain can ascertain what the service is. Interestingly, it is in
> exactly these cases that the calling domain is not actually providing 
> the service. This raises interesting questions, like, does it even
> make sense for an originating domain to *authorize* the access of a
> service that it is not even providing?

and he proposes an alternative model:

> Clearly, though, some of the things we'd want to do based on knowledge
> of the service, do make sense in the calling domain. One clear one is
> QoS authorization. I think the right answer there is that the SIP
> signaling would be sent all the way to the terminating domain, which
> would then be able to make the service determination, and through
> something like policy server peering, communicate information back to
> the originating domain on the required QoS and whether it should be
> authorized or not. Such an approach has the benefit that it allows a
> terminating domain to offer whatever services it wants, without
> coordinating with the originating side, yet still allow service-based 
> QOS authorization in the originating domain.

Note that this approach works just fine in a topology where access and 
service are separated. It does require (as proposed above) a new 
interface (like "policy server peering") for the QoS agreement, but it 
does NOT require that the access network understand the specific service 
being delivered. I believe this property is an absolute necessity for an 
Internet standard.

--
Dean


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP