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.
Ietf mailing list