ietf
[Top] [All Lists]

RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC

2010-04-05 11:50:58


-----Original Message-----
From: Cullen Jennings [mailto:fluffy(_at_)cisco(_dot_)com]
Sent: Monday, April 05, 2010 10:07 AM
To: Hadriel Kaplan

On Apr 1, 2010, at 12:59 PM, Hardier Kaplan wrote:
1) The mechanism does not scale, for large SSP's. (is this only meant
for small deployments?)

Why is this any worse that say a registration? I don't buy this assertion
that it does not scale.

Well of course anything "scales" if you throw enough money at it.
I guess it would have been clearer to say "it does not scale in a 
cost-effective manner relative to the benefit it provides".

As you know it *is* actually more signaling messages and heavier than 
Registration during restart, but let's just assumes it scales no worse than 
Registration.  Is that a good thing?  Registration provides something tangibly 
valuable (and unavoidably necessary).  How does this config framework model 
*require* the subscriptions in order to properly function, other than just 
through text saying it does?  For some folks it will be very useful/good, for 
others a waste of money and complexity.

And the way this is written makes the Subscription portion now a 
critical/blocking component in getting SIP service up and working (unless I'm 
misreading it).  You and I both know vendors have spent *years* perfecting SIP 
Registration for avalanche-type events, to get service back up as quickly as 
possible.  Changing that model in a way that cannot be turned off/disabled is 
just asking for trouble.

BTW, I wouldn't care so much if this were just some random individual draft or 
only meant for private Enterprise deployments.  But this is really a Sip-Forum 
draft, meant for SSP's of any size.

-hadriel
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>