Howdy,
This may not be within the normal rules of etiquette, but I will re-iterate my
issues with this draft which I raised when it was discussed in RAI.
1) The mechanism does not scale, for large SSP's. (is this only meant for small
deployments?)
Expecting every UA to keep a permanent SIP Subscription to "config change"
servers is unreasonable. Either the UA makes this Subscription directly to the
Server(s), in which case there will be a large volume of keep-alives just to
keep NAT pinholes alive; or it makes it through edge proxies, in which case
it's a lot of SIP messaging both in the sense of keeping the Subscribe dialog
alive but more importantly at the worst possible time: during avalanche
restarts. Either way, it's not good.
All this state and signaling is to achieve what? So that once a year or so we
can tell UA's to do another HTTP Get so they change one of their config
settings, or upgrade their firmware?? How is that cost-burden justified? Do
most other applications keep permanent connections for such changes? Not as
far as I can tell. They poll on a (very) infrequent interval.
2) I would be ok with (1) if it was optional, so only providers that wanted it
had to pay for it, but as far as I can tell the mechanism *requires*
implementation of this SIP Subscription service. Maybe I'm reading it wrong?
Section 2.5.1 says the HTTP response MUST have the Link header, with a SIP URI,
and if the Subscription attempt fails then it has to start again, etc. Seems
to me you're requiring/mandating a "nice-to-have-feature", and an expensive and
complicated one at that. Why?
-hadriel
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf