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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf