Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
On Thu, 2010-04-01 at 14:59 -0400, Hadriel Kaplan wrote: > 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? You're not mis-reading the requirement. I'm not sure that I understand why you think that this is so expensive. If the UA is not behind a NAT, the cost of the subscription is a few bytes of state in the configuration server. If the UA is behind a NAT, then keepalives will be needed to permit any request (including an INVITE) to reach it. There is no need for separate keepalives for the SUBSCRIBE dialog and those needed to support the REGISTER pseudo-dialog. Since the service provider is in control of the routing for both INVITEs and those SUBSCRIBEs, surely it's trivial to arrange things so that the same keepalive is sufficient for both, which makes the marginal cost in the NAT case the same as that without a NAT. The avalanche restart problem already exists for the REGISTERs that will usually be coming at the same time, but the SUBSCRIBE already has (and the draft explicitly requires that that UA be prepared to use) mechanisms for telling the SUBSCRIBER to wait a server-specified time before retrying. Such a mechanism could be implemented at the SP edge without evening looking at the configuration data, and the UA is free to use its previous configuration in the mean time. So ... why? Many SIP features are implemented exclusively in or require close coordination with the capabilities of the UA. This means that changing such features often requires that the UA be reconfigured. In order to provide a good user experience, the time between a change request and when the change is in effect should be brief and predictable, which is inconsistent with long polling intervals. Telling users to reboot a device to activate a change or wait some unpredictable time are unsatisfactory. Having the configuration change notification mechanism allows the reconfiguration to be prompt and predictable. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
Hi Scott, Comments inline... > -Original Message- > From: Scott Lawrence [mailto:xmlsc...@gmail.com] > Sent: Thursday, April 01, 2010 10:27 PM > To: Hadriel Kaplan > > If the UA is not behind a NAT, the cost of the subscription is a few > bytes of state in the configuration server. Well, it's not just a "few" bytes - it's a whole dialog's worth of state. (call-id, tags, To-URI, From-URI, list of routes, expires, whatever) But it's also the SIP signaling - every subscription expires interval the UA has to send a Subscribe to refresh, the server has to process it, update the subscription state, return a 200, send a Notify, and get a 200 for that. No? Obviously you could make the expiration interval long, but however long you make it will be as long as the worst-case config-change time, in case the Subscription server failed/restarted in-between. So that same time is also how long the polling interval could/would be if the UA just checked the HTTP server instead. > If the UA is behind a NAT... > [snipped text] Of course - I only mentioned the NAT issue because some folks had talked about the subscription going to a config-server directly without going through edge proxies. > So ... why? Many SIP features are implemented exclusively in or require > close coordination with the capabilities of the UA. This means that > changing such features often requires that the UA be reconfigured. In > order to provide a good user experience, the time between a change > request and when the change is in effect should be brief and > predictable, which is inconsistent with long polling intervals. Telling > users to reboot a device to activate a change or wait some unpredictable > time are unsatisfactory. Having the configuration change notification > mechanism allows the reconfiguration to be prompt and predictable. Of course telling users to reboot is untenable. I'm not suggesting they should. But the actual config data identified in the draft, and any I've seen in actual use, is not the kind that requires frequent updating. More to the point, some SSP's are perfectly fine with rolling out new "features" over the course of a day or X hours instead of this instant. They don't just switch over instantly anyway, and many SSP's require migration time and old-mode support for a period because they can't disrupt established calls. Regardless, my point isn't that it's not a nice feature to be able to do it instantly - my point is it's a nice feature, not a requirement for ua-configuration to work. Let the operator decide whether to do it. Don't mandate it be used. -hadriel p.s. and really instead of requiring permanent Subscriptions for every SIP mechanism which needs instant notification, we should just define a generic mechanism for asynchronous notification to UA's from their SSP for this and other uses. I know it needs some means for the UA to authenticate the request, but that's a good problem to solve. :) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
On Fri, 2010-04-02 at 12:05 -0400, Hadriel Kaplan wrote: > > -Original Message- > > From: Scott Lawrence [mailto:xmlsc...@gmail.com] > > Sent: Thursday, April 01, 2010 10:27 PM > > To: Hadriel Kaplan > > > > If the UA is not behind a NAT, the cost of the subscription is a few > > bytes of state in the configuration server. > > Well, it's not just a "few" bytes - it's a whole dialog's worth of > state. (call-id, tags, To-URI, From-URI, list of routes, expires, > whatever) > But it's also the SIP signaling - every subscription expires interval > the UA has to send a Subscribe to refresh, the server has to process > it, update the subscription state, return a 200, send a Notify, and > get a 200 for that. No? > > Obviously you could make the expiration interval long, but however > long you make it will be as long as the worst-case config-change time, > in case the Subscription server failed/restarted in-between. So that > same time is also how long the polling interval could/would be if the > UA just checked the HTTP server instead. You assume that the configuration server looses subscription state on a restart... that would be a pretty shabby implementation, especially given that one would expect the subscription times to be very long (if I were going to make a suggestion, it would be at least a week). > > If the UA is behind a NAT... > > [snipped text] > > Of course - I only mentioned the NAT issue because some folks had > talked about the subscription going to a config-server directly > without going through edge proxies. Again, that would be very poor design on the part of the provider, and is entirely within the providers control since they are setting the URL value and all the DNS records that control routing for the domain in that URL. > > So ... why? Many SIP features are implemented exclusively in or require > > close coordination with the capabilities of the UA. This means that > > changing such features often requires that the UA be reconfigured. In > > order to provide a good user experience, the time between a change > > request and when the change is in effect should be brief and > > predictable, which is inconsistent with long polling intervals. Telling > > users to reboot a device to activate a change or wait some unpredictable > > time are unsatisfactory. Having the configuration change notification > > mechanism allows the reconfiguration to be prompt and predictable. > > Of course telling users to reboot is untenable. I'm not suggesting > they should. But the actual config data identified in the draft, and > any I've seen in actual use, is not the kind that requires frequent > updating. More to the point, some SSP's are perfectly fine with > rolling out new "features" over the course of a day or X hours instead > of this instant. They don't just switch over instantly anyway, and > many SSP's require migration time and old-mode support for a period > because they can't disrupt established calls. Well, my experience is mostly in enterprise deployments (some quite large), but certainly in those people expect immediate response (certainly less than a minute) when they make a change. I think that as large scale service providers start to roll out better features like custom ring tones and fancy display features (which many of the current generation of SIP phones have, and which require configuration), they'll need similar responsiveness (or, put another way, the ones that provide immediate gratification will be perceived to be much higher quality those that don't). I've never seen a SIP phone reboot during a call when told to reconfigure by any of the existing mechanisms; I would be amazed to see one do it with this - but again, that's an implementation quality issue. > Regardless, my point isn't that it's not a nice feature to be able to > do it instantly - my point is it's a nice feature, not a requirement > for ua-configuration to work. Let the operator decide whether to do > it. Don't mandate it be used. One of the things that I personally fought very hard for in this specification was removing optional behavior and choices of any kind whenever possible. This is purely my own personal opinion, but I think that many IETF specs have fallen into the trap of getting consensus by making too many protocol features optional or having alternative ways of doing things. Simplicity is virtue, and conditional statements in specifications are sources of interoperability problems. If we were to adjust this spec to, for example, allow the configuration server to decide whether or not the UA had to subscribe, then some providers would decide to not bother, and some UAs would decide that since today they only cared about that one provider they wouldn't bother to implement (or test) that part of the spec. Pretty soon the feature is a real crap shoot and again SIP phones look flaky and hard to administer. I freely admit to being something of a zealot in trying to kee
Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
On 4/5/2010 8:00 AM, Scott Lawrence wrote: > On Fri, 2010-04-02 at 12:05 -0400, Hadriel Kaplan wrote: > >>> -Original Message- >>> From: Scott Lawrence [mailto:xmlsc...@gmail.com] >>> Sent: Thursday, April 01, 2010 10:27 PM >>> To: Hadriel Kaplan >>> >>> If the UA is not behind a NAT, the cost of the subscription is a few >>> bytes of state in the configuration server. >> >> Well, it's not just a "few" bytes - it's a whole dialog's worth of >> state. (call-id, tags, To-URI, From-URI, list of routes, expires, >> whatever) >> But it's also the SIP signaling - every subscription expires interval >> the UA has to send a Subscribe to refresh, the server has to process >> it, update the subscription state, return a 200, send a Notify, and >> get a 200 for that. No? >> >> Obviously you could make the expiration interval long, but however >> long you make it will be as long as the worst-case config-change time, >> in case the Subscription server failed/restarted in-between. So that >> same time is also how long the polling interval could/would be if the >> UA just checked the HTTP server instead. > > You assume that the configuration server looses subscription state on a > restart... that would be a pretty shabby implementation, especially > given that one would expect the subscription times to be very long (if I > were going to make a suggestion, it would be at least a week). NOTHING can be "assumed about an IETF Standard which does not have an accompanying use model or BCP" for its use, so this is in fact relevant and appropriate. > >>> If the UA is behind a NAT... >>> [snipped text] >> >> Of course - I only mentioned the NAT issue because some folks had >> talked about the subscription going to a config-server directly >> without going through edge proxies. > > Again, that would be very poor design on the part of the provider, and > is entirely within the providers control since they are setting the URL > value and all the DNS records that control routing for the domain in > that URL. But since you have not restricted them from doing this really stupid thing you cannot assume they wont. > >>> So ... why? Many SIP features are implemented exclusively in or require >>> close coordination with the capabilities of the UA. This means that >>> changing such features often requires that the UA be reconfigured. In >>> order to provide a good user experience, the time between a change >>> request and when the change is in effect should be brief and >>> predictable, which is inconsistent with long polling intervals. Telling >>> users to reboot a device to activate a change or wait some unpredictable >>> time are unsatisfactory. Having the configuration change notification >>> mechanism allows the reconfiguration to be prompt and predictable. >> >> Of course telling users to reboot is untenable. I'm not suggesting >> they should. But the actual config data identified in the draft, and >> any I've seen in actual use, is not the kind that requires frequent >> updating. More to the point, some SSP's are perfectly fine with >> rolling out new "features" over the course of a day or X hours instead >> of this instant. They don't just switch over instantly anyway, and >> many SSP's require migration time and old-mode support for a period >> because they can't disrupt established calls. > > Well, my experience is mostly in enterprise deployments (some quite > large), but certainly in those people expect immediate response > (certainly less than a minute) when they make a change. I think that as > large scale service providers start to roll out better features like > custom ring tones and fancy display features (which many of the current > generation of SIP phones have, and which require configuration), they'll > need similar responsiveness (or, put another way, the ones that provide > immediate gratification will be perceived to be much higher quality > those that don't). > > I've never seen a SIP phone reboot during a call when told to > reconfigure by any of the existing mechanisms; I would be amazed to see > one do it with this - but again, that's an implementation quality issue. > >> Regardless, my point isn't that it's not a nice feature to be able to >> do it instantly - my point is it's a nice feature, not a requirement >> for ua-configuration to work. Let the operator decide whether to do >> it. Don't mandate it be used. > > One of the things that I personally fought very hard for in this > specification was removing optional behavior and choices of any kind > whenever possible. Then why make any Assumptions about anything? This is purely my own personal opinion, but I think > that many IETF specs have fallen into the trap of getting consensus by > making too many protocol features optional or having alternative ways of > doing things. Simplicity is virtue, and conditional statements in > specifications are sources of interoperability problems. If we were to > adjust this spec t
Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
On Mon, 2010-04-05 at 08:43 -0700, todd glassey wrote: > > >> Obviously you could make the expiration interval long, but however > >> long you make it will be as long as the worst-case config-change time, > >> in case the Subscription server failed/restarted in-between. So that > >> same time is also how long the polling interval could/would be if the > >> UA just checked the HTTP server instead. > > > > You assume that the configuration server looses subscription state on a > > restart... that would be a pretty shabby implementation, especially > > given that one would expect the subscription times to be very long (if I > > were going to make a suggestion, it would be at least a week). > > NOTHING can be "assumed about an IETF Standard which does not have an > accompanying use model or BCP" for its use, so this is in fact relevant > and appropriate. I'm not sure what you're suggesting here... > >>> If the UA is behind a NAT... > >>> [snipped text] > >> > >> Of course - I only mentioned the NAT issue because some folks had > >> talked about the subscription going to a config-server directly > >> without going through edge proxies. > > > > Again, that would be very poor design on the part of the provider, and > > is entirely within the providers control since they are setting the URL > > value and all the DNS records that control routing for the domain in > > that URL. > > But since you have not restricted them from doing this really stupid > thing you cannot assume they wont. In either of the above cases, the party who is making poor design or implementation choices is the party that suffers. In neither case does the Internet suffer any appreciable damage, since the mandated retry backoff prevents undo traffic. I suppose that the document could specify that subscription state must be preserved across restarts, or could specify that anyone deploying a configuration service must ensure that the configured routing is such that NAT keepalive traffic is the same as that needed for other purposes. The former seems pretty obvious to me, but I guess I would not object to it; the latter is a constraint on deployments that we can't test in an implementation anyway, so I don't quite see the point. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
On 4/5/2010 9:04 AM, Scott Lawrence wrote: > On Mon, 2010-04-05 at 08:43 -0700, todd glassey wrote: >> Obviously you could make the expiration interval long, but however long you make it will be as long as the worst-case config-change time, in case the Subscription server failed/restarted in-between. So that same time is also how long the polling interval could/would be if the UA just checked the HTTP server instead. >>> >>> You assume that the configuration server looses subscription state on a >>> restart... that would be a pretty shabby implementation, especially >>> given that one would expect the subscription times to be very long (if I >>> were going to make a suggestion, it would be at least a week). >> >> NOTHING can be "assumed about an IETF Standard which does not have an >> accompanying use model or BCP" for its use, so this is in fact relevant >> and appropriate. > > I'm not sure what you're suggesting here... OK, I am saying that because the IETF allows any level of implementation of any of its protocols it has nothing to say about how much of any protocol or practice is implemented... unless there is a BCP saying that this is the minimum acceptable implementation for the use of the IETF's license. > > If the UA is behind a NAT... > [snipped text] Of course - I only mentioned the NAT issue because some folks had talked about the subscription going to a config-server directly without going through edge proxies. >>> >>> Again, that would be very poor design on the part of the provider, and >>> is entirely within the providers control since they are setting the URL >>> value and all the DNS records that control routing for the domain in >>> that URL. >> >> But since you have not restricted them from doing this really stupid >> thing you cannot assume they wont. > > In either of the above cases, the party who is making poor design or > implementation choices is the party that suffers. | No its the victims they take down with them who suffer... Todd In neither case does > the Internet suffer any appreciable damage, since the mandated retry > backoff prevents undo traffic. > > I suppose that the document could specify that subscription state must > be preserved across restarts, or could specify that anyone deploying a > configuration service must ensure that the configured routing is such > that NAT keepalive traffic is the same as that needed for other > purposes. The former seems pretty obvious to me, but I guess I would > not object to it; the latter is a constraint on deployments that we > can't test in an implementation anyway, so I don't quite see the point. > > > <>___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
> -Original Message- > From: Cullen Jennings [mailto:flu...@cisco.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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
> -Original Message- > From: Scott Lawrence [mailto:xmlsc...@gmail.com] > Sent: Monday, April 05, 2010 11:00 AM > To: Hadriel Kaplan > > On Fri, 2010-04-02 at 12:05 -0400, Hadriel Kaplan wrote: > > > > Obviously you could make the expiration interval long, but however > > long you make it will be as long as the worst-case config-change time, > > in case the Subscription server failed/restarted in-between. So that > > same time is also how long the polling interval could/would be if the > > UA just checked the HTTP server instead. > > You assume that the configuration server looses subscription state on a > restart... that would be a pretty shabby implementation, especially > given that one would expect the subscription times to be very long (if I > were going to make a suggestion, it would be at least a week). Nope, I make no assumptions about implementation. When I say "restart", though, I do mean full restart - including a flush of any database, drive, memory, whatever. That would be the worst case. And my guess is that worst-case happens more frequently than people would like to admit. So whatever the Subscribe's expiration time is, is as long as the worst-case new-feature-rollout time. > I think that as > large scale service providers start to roll out better features like > custom ring tones and fancy display features (which many of the current > generation of SIP phones have, and which require configuration), they'll > need similar responsiveness (or, put another way, the ones that provide > immediate gratification will be perceived to be much higher quality > those that don't). And that's all great and good. Again, I'm not arguing it isn't a nice feature. But it *is* a feature. It's not inherently necessary to have Subscriptions to make a config framework work. You're adding complexity and cost - for what you perceive to be a necessary capability. I'm arguing it's not necessary, and we shouldn't force people to pay for something they might not want. The IETF has been really unsuccessful at trying to do that. -hadriel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
> -Original Message- > From: Scott Lawrence [mailto:xmlsc...@gmail.com] > Sent: Monday, April 05, 2010 11:00 AM > To: Hadriel Kaplan > > One of the things that I personally fought very hard for in this > specification was removing optional behavior and choices of any kind > whenever possible. This is purely my own personal opinion, but I think > that many IETF specs have fallen into the trap of getting consensus by > making too many protocol features optional or having alternative ways of > doing things. Simplicity is virtue, and conditional statements in > specifications are sources of interoperability problems. And I'm generally very receptive to that type of argument, as you probably know. But this isn't some minor option or slight difference. This is a *vastly* different deployment model being hard-coded to "on", and forced down people's throat as a one-size-fits-all decision. You can't even turn it off through the config framework itself, because the subscription happens before the config is "valid". > If we were to > adjust this spec to, for example, allow the configuration server to > decide whether or not the UA had to subscribe, then some providers would > decide to not bother, Well if that's the case then that tells you something about how "necessary" it was, no? ;) > and some UAs would decide that since today they > only cared about that one provider they wouldn't bother to implement (or > test) that part of the spec. Pretty soon the feature is a real crap > shoot and again SIP phones look flaky and hard to administer. I freely > admit to being something of a zealot in trying to keep the specification > simple, with as few choices for any party as possible, because that's > the best way to reach universal interoperability. There is no way to police compliance. If people decide to ignore MUST statements in RFCs, then they don't comply with the RFC. If you make it mandatory for a UA, and the UA doesn't do it, then it's not compliant. Forcing the provider to deploy additional servers and a specific architecture just to force a UA to implement a MUST statement? That's bizarre. Regardless, SIP Subscription itself has interop issues, so it's not like this will be guaranteed to interop world-wide just because it works in the first instance. Since this is from the SIP-Forum, you guys actually have an opportunity to force the UA side to implement it, and do it in a common way, by branding a mark and doing a certification program for the mark - like WiFi Alliance does - which would actually improve interoperability. (if it's backed up by real 3rd-party certification, not self-certification) -hadriel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
On Mon, 2010-04-05 at 12:50 -0400, Hadriel Kaplan wrote: > 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 are misreading it. The configuration data is obtained via HTTPS before the subscription is created. Until the subscription is established (whether following the initial load of the data or on any subsequent UA restart), the status of that configuration data is that it is of 'unknown validity' (having an established subscription on which no change notice has been received changes that to 'known to be valid'). The spec says in section 2.6 (Validity of Stored Configuration Data): The UA MAY use configuration data that is of unknown validity, or configuration data that is known to be no longer valid, while attempting to revalidate that data or obtain new data. So the UA may use the configuration data before any subscription is established - the subscription does not block anything (except getting change notices). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
> -Original Message- > From: Scott Lawrence [mailto:xmlsc...@gmail.com] > Sent: Monday, April 05, 2010 2:30 PM > To: Hadriel Kaplan > > The spec says in section 2.6 > (Validity of Stored Configuration Data): > > The UA MAY use configuration data that is of unknown validity, > or configuration data that is known to be no longer valid, while > attempting to revalidate that data or obtain new data. > > So the UA may use the configuration data before any subscription is > established - the subscription does not block anything (except getting > change notices). Heh... weren't you just arguing about how optional requirements in IETF docs are bad? ;) This form of optional is right up that alley. For example, if I am a service provider who wants to not have Subscription mode, and the only way to do it is through UA config framework itself by setting a config field for "Subscribe-UA-Config="false" or whatever, then clearly the UA's MUST use the config. A MAY statement does nothing. If it's not clear and exact as to what config data a UA is supposed to use, and when, then you really do get "flaky service behavior" as you were worried about in a previous email. -hadriel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
On Mon, 2010-04-05 at 15:09 -0400, Hadriel Kaplan wrote: > > > -Original Message- > > From: Scott Lawrence [mailto:xmlsc...@gmail.com] > > Sent: Monday, April 05, 2010 2:30 PM > > To: Hadriel Kaplan > > > > The spec says in section 2.6 > > (Validity of Stored Configuration Data): > > > > The UA MAY use configuration data that is of unknown validity, > > or configuration data that is known to be no longer valid, while > > attempting to revalidate that data or obtain new data. > > > > So the UA may use the configuration data before any subscription is > > established - the subscription does not block anything (except getting > > change notices). > > Heh... weren't you just arguing about how optional requirements in > IETF docs are bad? ;) > > This form of optional is right up that alley. For example, if I am a > service provider who wants to not have Subscription mode, and the only > way to do it is through UA config framework itself by setting a config > field for "Subscribe-UA-Config="false" or whatever, then clearly the > UA's MUST use the config. A MAY statement does nothing. The draft is clear that the configuration data can modify any part of the procedures in the draft. Section 2: The User Agent MAY obtain configuration information by any means in addition to those specified here, and MAY use such information in preference to any of the steps specified below, ... So if you're looking for an escape clause, you've found it, but the rest of the sentence is important ...but MUST be capable of using these procedures alone in order to be compliant with this specification. > If it's not clear and exact as to what config data a UA is supposed to > use, and when, then you really do get "flaky service behavior" as you > were worried about in a previous email. I think that the wording of that particular statement is perhaps unfortunate, but have not found a better one. In effect, what we were trying to do is express that the UA is not required to wait until the subscription exists to use the data, and can continue to use the data should the subscription fail for any reason. This prevents various failure modes and/or delays in the UA when the Configuration Service is overloaded or otherwise unavailable. It's not an 'optional requirement' it's a non-requirement. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
> -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of > Scott Lawrence > Sent: Monday, April 05, 2010 3:55 PM > > On Mon, 2010-04-05 at 15:09 -0400, Hadriel Kaplan wrote: > > This form of optional is right up that alley. For example, if I am a > > service provider who wants to not have Subscription mode, and the only > > way to do it is through UA config framework itself by setting a config > > field for "Subscribe-UA-Config="false" or whatever, then clearly the > > UA's MUST use the config. A MAY statement does nothing. > > The draft is clear that the configuration data can modify any part of > the procedures in the draft. Section 2: > > The User Agent MAY obtain configuration information by any means > in addition to those specified here, and MAY use such > information in preference to any of the steps specified > below, ... But all that statement is "clear" about is that it's NOT clear - not clear what the UA will do, in practice/implementation. Leaving it up to the UA to decide what to do does nothing to assure the service provider of anything. I'm not trying to be difficult (really!) - I'm just asking: imagine I'm a service provider. I want my users to go into a Best-Buy/Wal-Mart/whatever and buy a SIP phone, plug it into the Internet, download some config stuff from my Apache HTTPS servers, and work. Can I do that, without having to also deploy SIP Subscription servers? As I read this doc, I cannot. > So if you're looking for an escape clause, you've found it, but the rest > of the sentence is important > > ...but MUST be capable of using these procedures alone in order > to be compliant with this specification. Yes, I read that and was thoroughly confused. :) > I think that the wording of that particular statement is perhaps > unfortunate, but have not found a better one. In effect, what we were > trying to do is express that the UA is not required to wait until the > subscription exists to use the data, and can continue to use the data > should the subscription fail for any reason. This prevents various > failure modes and/or delays in the UA when the Configuration Service is > overloaded or otherwise unavailable. It's not an 'optional requirement' > it's a non-requirement. But saying "the UA is not required to do Foo" is NOT the same as saying "the UA is required to not do Foo". In effect, any and all UA's in the Universe can meet the former, but only some can meet the latter. What I mean is, with this language, ALL UA's automatically comply with the RFC, but only *some* will actually use their config without waiting for a subscription. -hadriel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
Review of: draft-lawrence-sipforum-user-agent-config This appears to be an Individual Submission. By title and Introductory text, the document specifies its scope as user agent configuration by non-technical users. The actual contents of the specification suggests a broader scope, also covering automated (non-human) configuration, as well as the details of a remote "Configuration Service". If the details of the Configuration Service are defined elsewhere I did not find citation to it in this draft. Rather, Section 2.3 appears to imply that remote service's HTTP-based query characteristics. It even mandates access via HTTPS rather than HTTP, independent of whether other security mechanisms would suffice. That is, the document slips into specifying an integrated service, not just the configuration for a component of that service. Given the significant security-related detail provided in Section 2.4.1, the security model ought to be called out and discussed in detail, separately. I suggest specifying the details of the remote query service into a separate section, if not a separate document. (A separate document would be appropriate if the configuration service has other plausible clients, besides this one type of UA.) Detailed comments: Section 1.1 Presumably "is free to" should be replaced by MAY, since this is intended to be a normative document and statements in a Scope section specify boundaries. Section 2.1 Section 2.1 dictates platform behaviors for network and link-layer configuration. This kind of detail, in this kind of document, encourages divergent support, since it specifies details that are normally provided elsewhere. At most, the section should provide a generic reference to "standard" IP support and leave it at that. My own suggestion is to say that IP and link configuration are outside the scope of the document. Section 2.2 Is "DNS Name" a domain name or is it a host name? Section 2.2.1 Local Network Domain" is an essential parameter, but is undefined. The reference to 2.1.2 does not resolve. It is probably also worth confirming that an automatically-supplied domain name is an organizational string (DNS suffix) rather than the fully qualified name of the UA. About "network", a term like "local network domain" is probably not as meaningful as one might wish, given the decoupling between IP networks and Domains. My guess is that the specification should simply say "local domain". Section 2.2.2 This section launches the document into the realm of human user interface design. That's a discipline typically excluded from IETF work, for very good reasons. If the document is specifying the protocol-related details of user agent, it fits well into IETF work. If the document seeks to specify user interface design, it doesn't. This subsection provides a good example of the problem with this aspect of the document. The section says that a UA MAY provide for manual configuration. Imagine that the specification instead said that the UA MUST NOT provide for manual configuration. Would it be reasonable for this specification to mandate such a restriction? Probably not. But for a specification to be meaningful, such alternative choices must make sense. I don't mean that the alternative would be a good choice but that the "vocabulary" of doing a specification needs to permit alternative choices. This one doesn't. The specification should define the configuration information that is needed, define any automated means that might exist for obtaining data, and defer specification of other means of obtaining the data. Section 2.3.1 The UA MUST make a DNS request for NAPTR records for that domain name. So it would be a violation of the specification to have the necessary Configuration Service response data already configured into the UA? Why? Section 2.3.1.2 If the DNS request to resolve the Configuration Service Name to a request URL does not receive any response, the UA should follow standard DNS retry procedures." The preceding sub-section (2.3.1.1) discusses redundancy. So it's not clear whether "standard" retry procedures should retry the same server or an alternative one. If the DNS request to resolve the Configuration Domain Name to a host name returns a response that indicates that no matching result is available (NXDOMAIN), the UA SHOULD attempt to obtain another Configuration Domain Name using the procedures in Section 2.2, "Obtaining the Configuration Service Domain". Section 2.2 provides no reference to the means of obtaining a first name, nevermind alternatives. Section 2.3.2.1 The section does not specify, for each parameter, whether it is optional or required. If the intent is to default to optional unless otherwise mandated, the spec should say so at the beginning of the sub-section. Since the procedure defined by [RFC5626] allows any UA to construct a value for this parameter, the sfua-id parameter MUST always be included
Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
So I agree with Hadriel that we want the document to be very clear on what code the implementors need to write but I'm not exactly seeing the confusion. Perhaps I need to go reread the doc from that point of view. However,I did want to comment on the use cases for this. There are many service providers that think it is important to be able to push a new configuration to a UA "quickly" and the definition of quickly varies widely. Imagine the case where someone is having problems getting their fax to work and the SP wants to change the preferred codec from 729 to 711. Now I realize you could do that by using an SBC that forced negation to only 711 but that would reduce the flexibility of the system. Some operators want to be able to change the config on the UA. I have talked to some that seem fine with the idea that the UA would poll ever 24 hours or that the end user user would need to power cycle the UA. I have talked to others that think that is totally unacceptable and need to be able to trigger something that causes the UA to get the new config in something more like 30 seconds. Different folks have different ideas of how fast you need to be able to update this however when you star t talking about how fast people would like to roll out fix to a security of DOS attack problem, all the service providers I have talked to start talking about much faster times than 24 hours. I'm sure there are some deployments where polling would be fine but there are lots that don't find this acceptable. On Apr 5, 2010, at 3:55 PM, Hadriel Kaplan wrote: > > >> -Original Message- >> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of >> Scott Lawrence >> Sent: Monday, April 05, 2010 3:55 PM >> >> On Mon, 2010-04-05 at 15:09 -0400, Hadriel Kaplan wrote: >>> This form of optional is right up that alley. For example, if I am a >>> service provider who wants to not have Subscription mode, and the only >>> way to do it is through UA config framework itself by setting a config >>> field for "Subscribe-UA-Config="false" or whatever, then clearly the >>> UA's MUST use the config. A MAY statement does nothing. >> >> The draft is clear that the configuration data can modify any part of >> the procedures in the draft. Section 2: >> >>The User Agent MAY obtain configuration information by any means >>in addition to those specified here, and MAY use such >>information in preference to any of the steps specified >>below, ... > > But all that statement is "clear" about is that it's NOT clear - not clear > what the UA will do, in practice/implementation. Leaving it up to the UA to > decide what to do does nothing to assure the service provider of anything. > > I'm not trying to be difficult (really!) - I'm just asking: imagine I'm a > service provider. I want my users to go into a Best-Buy/Wal-Mart/whatever > and buy a SIP phone, plug it into the Internet, download some config stuff > from my Apache HTTPS servers, and work. Can I do that, without having to > also deploy SIP Subscription servers? As I read this doc, I cannot. > > >> So if you're looking for an escape clause, you've found it, but the rest >> of the sentence is important >> >>...but MUST be capable of using these procedures alone in order >>to be compliant with this specification. > > > Yes, I read that and was thoroughly confused. :) > > >> I think that the wording of that particular statement is perhaps >> unfortunate, but have not found a better one. In effect, what we were >> trying to do is express that the UA is not required to wait until the >> subscription exists to use the data, and can continue to use the data >> should the subscription fail for any reason. This prevents various >> failure modes and/or delays in the UA when the Configuration Service is >> overloaded or otherwise unavailable. It's not an 'optional requirement' >> it's a non-requirement. > > But saying "the UA is not required to do Foo" is NOT the same as saying "the > UA is required to not do Foo". In effect, any and all UA's in the Universe > can meet the former, but only some can meet the latter. > > What I mean is, with this language, ALL UA's automatically comply with the > RFC, but only *some* will actually use their config without waiting for a > subscription. > > -hadriel > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
> -Original Message- > From: Cullen Jennings [mailto:flu...@cisco.com] > Sent: Tuesday, April 06, 2010 11:53 AM > To: Hadriel Kaplan > > However,I did want to comment on the use cases for this. There are many > service providers that think it is important to be able to push a new > configuration to a UA "quickly" and the definition of quickly varies > widely. Imagine the case where someone is having problems getting their > fax to work and the SP wants to change the preferred codec from 729 to 711. > Now I realize you could do that by using an SBC that forced negation to > only 711 but that would reduce the flexibility of the system. Some > operators want to be able to change the config on the UA. I have talked to > some that seem fine with the idea that the UA would poll ever 24 hours or > that the end user user would need to power cycle the UA. I have talked to > others that think that is totally unacceptable and need to be able to > trigger something that causes the UA to get the new config in something > more like 30 seconds. Different folks have different ideas of how fast you > need to be able to update this however when you start talking about how > fast people would like to roll out fix to a security of DOS attack problem, > all the service providers I have talked to start talking about much faster > times than 24 hours. Right, so what happens if the Subscription *is* the DoS attack? I'm not saying this to be cute - we need a way to turn it off, and have it off to start with (i.e., on reboot). No one has any empirical evidence or experience with what this thing will do to large subscriber domains. (and by large I mean multiple millions of UA's, which is the scale several SIP deployments are in now) As you know, there were several painful "growing pains" in the past in large subscriber domains with unforeseen UA behavior. Similar issues cropped up again when reg-event Subscriptions started getting deployed. If what we really want is something to force the UA to download a config *right now*, then do that explicitly. Give each registered UA a "private" gruu, known only to the SSP and UA. When you want to refresh the UA, send a PUBLISH to the gruu, telling it to refresh its config. You can do that gruu statelessly on the SSP side, any number of ways. > I'm sure there are some deployments where polling would be fine but there > are lots that don't find this acceptable. Absolutely - different strokes for different folks. That doesn't mean everyone should be forced to do it. -hadriel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
Cullen, I'm sure there are some deployments where polling would be fine but there are lots that don't find this acceptable. The Internet alaredy has quite a bit of experience with renewal of parameters, via DHCP and the DNS. What is the justification that mandates a more complex model than these use? It's not usually considered sufficient to simply cite the fact that some operators somewhere want something different. There needs to be a compelling case made. It is always possible to invent edge cases that appear to justify a different paradigm. The real question is about real need. Given that operators have survived nicely with the DHCP and DNS models, what is the /compelling/ need for doing something differently for the current proposal? It will greatly help discussion to have operators represent themselves. If they really believe the more complex update model is essential, they should lobby for it themselves. The IETF is nicely open to such participation... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
On Tue, 2010-04-06 at 09:24 -0700, Dave CROCKER wrote: > Cullen, > > > I'm sure there are some deployments where polling would be fine but there > > are lots that don't find this acceptable. > > > The Internet alaredy has quite a bit of experience with renewal of > parameters, > via DHCP and the DNS. > > What is the justification that mandates a more complex model than > these use? It's not usually considered sufficient to simply cite the fact > that > some operators somewhere want something different. There needs to be a > compelling case made. > > It is always possible to invent edge cases that appear to justify a different > paradigm. The real question is about real need. The configuration data we're discussing here is substantially more complex and more important to the operation of the device than the information provided by either DHCP or DNS. A better analogy would be the full configuration information for a router - would anyone argue that only being able to change the configuration of router once every 24 hours would be sufficient? > Given that operators have survived nicely with the DHCP and DNS models, what > is > the /compelling/ need for doing something differently for the current > proposal? > > It will greatly help discussion to have operators represent themselves. If > they > really believe the more complex update model is essential, they should lobby > for > it themselves. The IETF is nicely open to such participation... But we can't require it. The systems I work on are targeted at smaller scales that Hadriel is arguing for, but the need for prompt (seconds, not minutes) configuration updates is real for our market. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
On Apr 6, 2010, at 10:16 AM, Hadriel Kaplan wrote: > > > > -Original Message- > > From: Cullen Jennings [mailto:flu...@cisco.com] > > Sent: Tuesday, April 06, 2010 11:53 AM > > To: Hadriel Kaplan > > > > However,I did want to comment on the use cases for this. There are many > > service providers that think it is important to be able to push a new > > configuration to a UA "quickly" and the definition of quickly varies > > widely. Imagine the case where someone is having problems getting their > > fax to work and the SP wants to change the preferred codec from 729 to 711. > > Now I realize you could do that by using an SBC that forced negation to > > only 711 but that would reduce the flexibility of the system. Some > > operators want to be able to change the config on the UA. I have talked to > > some that seem fine with the idea that the UA would poll ever 24 hours or > > that the end user user would need to power cycle the UA. I have talked to > > others that think that is totally unacceptable and need to be able to > > trigger something that causes the UA to get the new config in something > > more like 30 seconds. Different folks have different ideas of how fast you > > need to be able to update this however when you start talking about how > > fast people would like to roll out fix to a security of DOS attack problem, > > all the service providers I have talked to start talking about much faster > > times than 24 hours. > > Right, so what happens if the Subscription *is* the DoS attack? I'm not > saying this to be cute - we need a way to turn it off, and have it off to > start with (i.e., on reboot). > > No one has any empirical evidence or experience with what this thing will do > to large subscriber domains. (and by large I mean multiple millions of UA's, > which is the scale several SIP deployments are in now) I'm aware of deployments with millions of UAs that use subscribe. Agree there are growing points in scaling anything and everything > As you know, there were several painful "growing pains" in the past in large > subscriber domains with unforeseen UA behavior. Similar issues cropped up > again when reg-event Subscriptions started getting deployed. > > If what we really want is something to force the UA to download a config > *right now*, then do that explicitly. Give each registered UA a "private" > gruu, known only to the SSP and UA. When you want to refresh the UA, send a > PUBLISH to the gruu, telling it to refresh its config. You can do that gruu > statelessly on the SSP side, any number of ways. I care more there is a way to do it than how it is done but can you explain how that is lighter weight than a subscribe? I would think that a subscribe could be done stateless on the SSP too given the usual state in dialog information techniques. I get how using a register to form an implicit subscribe would reduce the traffic of the initial subscribe formation and that might be a interesting optimization for someone to go write a draft on. > > > > I'm sure there are some deployments where polling would be fine but there > > are lots that don't find this acceptable. > > Absolutely - different strokes for different folks. That doesn't mean > everyone should be forced to do it. This conversation constantly confuses the issue of must implement vs must deploy. Which one are you objecting to here. > > -hadriel > Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
> -Original Message- > From: Cullen Jennings [mailto:flu...@cisco.com] > Sent: Tuesday, April 06, 2010 12:56 PM > To: Hadriel Kaplan > > > No one has any empirical evidence or experience with what this thing > > will do to large subscriber domains. (and by large I mean multiple > > millions of UA's, which is the scale several SIP deployments are in now) > > I'm aware of deployments with millions of UAs that use subscribe. Agree > there are growing points in scaling anything and everything Right, but they're doing it for reg-events and presence, after the Registration. During an avalanche, for example, they're implicitly throttled by the effective registration rates. This config framework is reversing it, having subscriptions before the registrations. I'm not saying it's not do-able or won't work, I'm just saying we don't know. (and I'm saying it's not free, and some folks won't think it's worth the cost) > > If what we really want is something to force the UA to download a config > > *right now*, then do that explicitly. Give each registered UA a "private" > >gruu, known only to the SSP and UA. When you want to refresh the UA, send > > a PUBLISH to the gruu, telling it to refresh its config. You can do that > > gruu statelessly on the SSP side, any number of ways. > > I care more there is a way to do it than how it is done but can you > explain how that is lighter weight than a subscribe? One way: when the UA Registers, have the Registrar construct a "private" gruu, for example using a hash of the registered contact with an unchanging key only known to the registrar. (so no extra state in registrar) Send that gruu back in the Register response with a new param name defined in your spec. The UA stores this private gruu, but cannot use it for anything but matching. The SSP can send an out-of-dialog PUBLISH asynchronously, to that contact using the gruu, to tell the UA to go get the HTTP config again. It's lighter weight because there's no subscription messaging, no permanent dialog state, and even the gruu is constructable and does not need to be stored by the SSP, only by the UA. [sarcasm=on] I don't know why the IETF keeps trying to put state into the middle instead of leaving it in the ends! :) [sarcasm=off] > I would think that a > subscribe could be done stateless on the SSP too given the usual state in > dialog information techniques. I don't know what you mean? How can the UAS send a Notify asynchronously without having stored the tags, call-id and path info of the subscription dialog, created by the UAC/Subscriber? You can't cookify them anywhere in the messaging, for example, because the UAS is the one sending the Notify sometime later. (I'm not referring to SBC's storing the dialog state - I'm talking about the config server) > I get how using a register to form an > implicit subscribe would reduce the traffic of the initial subscribe > formation and that might be a interesting optimization for someone to go > write a draft on. But why bother with a dialog at all?? The only answer I heard previously was: so the UA knows it's the config server, which it trusts. Well, if a shared secret is what we need, then the private gruu is that secret. -hadriel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
On 4/6/2010 9:55 AM, Cullen Jennings wrote: This conversation constantly confuses the issue of must implement vs must deploy. Which one are you objecting to here. Perhaps you have some data to cite about the historical, real-world difference between these? In a world of legitimately open systems, multiple implementations and competing products, there is usually little room for requiring implementation but not supporting deployment, I believe. If you have data to the contrary, please do share it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
> > Right, but they're doing it for reg-events and presence, after the > Registration. During an avalanche, for example, they're implicitly throttled > by the effective registration rates. This config framework is reversing it, > having subscriptions before the registrations. I'm not saying it's not > do-able or won't work, I'm just saying we don't know. (and I'm saying it's > not free, and some folks won't think it's worth the cost) Avalanche (restart) has its own set of problems - including overwhelming either the HTTP server, SSP or registrar. (In a draft, we've made proposals how to address this in some cases, as long as the UA can detect that it is likely part of an avalanche.) As we've seen from the SIP overload discussion, you can't rely on the "natural" throttling of the server to nicely space out requests - the whole thing is much more likely to collapse in a heap, so that no useful work gets done. This affects registration, subscription and retrieval more or less equally. Henning___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
On Tue, 2010-04-06 at 13:39 -0400, Hadriel Kaplan wrote: > > > -Original Message- > > From: Cullen Jennings [mailto:flu...@cisco.com] > > Sent: Tuesday, April 06, 2010 12:56 PM > > To: Hadriel Kaplan > > > > > No one has any empirical evidence or experience with what this thing > > > will do to large subscriber domains. (and by large I mean multiple > > > millions of UA's, which is the scale several SIP deployments are in now) > > > > I'm aware of deployments with millions of UAs that use subscribe. Agree > > there are growing points in scaling anything and everything > > > Right, but they're doing it for reg-events and presence, after the > Registration. During an avalanche, for example, they're implicitly > throttled by the effective registration rates. This config framework > is reversing it, having subscriptions before the registrations. I'm > not saying it's not do-able or won't work, I'm just saying we don't > know. (and I'm saying it's not free, and some folks won't think it's > worth the cost) This draft says nothing at all about the ordering of the change notice subscription vs any registration. > > > If what we really want is something to force the UA to download a config > > > *right now*, then do that explicitly. Give each registered UA a "private" > > >gruu, known only to the SSP and UA. When you want to refresh the UA, send > > > a PUBLISH to the gruu, telling it to refresh its config. You can do that > > > gruu statelessly on the SSP side, any number of ways. > > > > I care more there is a way to do it than how it is done but can you > > explain how that is lighter weight than a subscribe? > > One way: when the UA Registers, have the Registrar construct a > "private" gruu, for example using a hash of the registered contact > with an unchanging key only known to the registrar. (so no extra state > in registrar) Send that gruu back in the Register response with a new > param name defined in your spec. The UA stores this private gruu, but > cannot use it for anything but matching. The SSP can send an > out-of-dialog PUBLISH asynchronously, to that contact using the gruu, > to tell the UA to go get the HTTP config again. > > It's lighter weight because there's no subscription messaging, no > permanent dialog state, and even the gruu is constructable and does > not need to be stored by the SSP, only by the UA. > [sarcasm=on] I don't know why the IETF keeps trying to put state into > the middle instead of leaving it in the ends! :) [sarcasm=off] I'd be open to a fully worked out proposal based on PUBLISH, but I actually don't think that there are big savings over a SUBSCRIBE based mechanism. I don't buy the argument that the dialog state is burdensome - it's a few hundred bytes at most (and much of that size is under the control of the server). I do have some problem with making the notification some kind of side effect of the 'normal' registration. REGISTER exists to map an AOR to one or more Contacts. The Configuration Service needs to be able to address the change notice (whatever method carries it) to a specific UA, _not_ to the AOR of some user registered to that UA. If the UA is going to REGISTER an AOR for itself that is distinct from that of any user registered on it, then the whole thing starts to look a lot like a SUBSCRIBE. While we did not include text in the draft to suggest the use of the SIP-Etag mechanism in draft-ietf-sipcore-subnot-etags, it could be added to suppress the initial NOTIFY associated with the subscription (and if it would help, I'd have no problem with putting such text in). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
Sure, but vendors have already spent years working the reg-avalanche problem out for subscribers. One of my fears with this config framework is it's changing it, without a way to undo/not-do the change. -hadriel From: Henning Schulzrinne [mailto:h...@cs.columbia.edu] Sent: Tuesday, April 06, 2010 1:59 PM To: Hadriel Kaplan Cc: Cullen Jennings; IETF Discussion Mailing List Subject: Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC Avalanche (restart) has its own set of problems - including overwhelming either the HTTP server, SSP or registrar. (In a draft, we've made proposals how to address this in some cases, as long as the UA can detect that it is likely part of an avalanche.) As we've seen from the SIP overload discussion, you can't rely on the "natural" throttling of the server to nicely space out requests - the whole thing is much more likely to collapse in a heap, so that no useful work gets done. This affects registration, subscription and retrieval more or less equally. Henning ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
On Mon, 2010-04-05 at 17:10 -0700, Dave CROCKER wrote: > Review of: draft-lawrence-sipforum-user-agent-config Thanks for taking the time to read this, Dave. > This appears to be an Individual Submission. For IETF process purposes that is correct. As the document says, it is the product of a design team working within the SIP Forum Technical Working Group. > By title and Introductory text, the document specifies its scope as user agent > configuration by non-technical users. The actual contents of the > specification > suggests a broader scope, also covering automated (non-human) configuration, > as > well as the details of a remote "Configuration Service". I'm not sure what you're asking or suggesting above... the specification describes automated (or at worst mostly automated) procedures for user agent configuration, because that's what non-technical users need. Do you see a distinction or think that some clarification is needed? > If the details of the Configuration Service are defined elsewhere I did not > find > citation to it in this draft. Rather, Section 2.3 appears to imply that > remote > service's HTTP-based query characteristics. The draft deliberately does not specify anything about the Configuration Service (CS) other than the protocol interface it supports. Any other characteristic of the CS is beyond the scope of the document, and anything that supports that interface can act as a CS. Do you think that's a problem? > It even mandates access via HTTPS rather than HTTP, independent of whether > other > security mechanisms would suffice. That is, the document slips into > specifying > an integrated service, not just the configuration for a component of that > service. Our goal was to specify a simple set of rules that every UA and CS could implement that would ensure interoperability. While we could have put in some words about how there might exist circumstances in which HTTP would be appropriate and sufficiently secure, it was our judgement that such text would not advance the goal. Yes, if your network is all glass fiber and has quantum crypto at the physical layer then maybe you don't need https... > Given the significant security-related detail provided in Section 2.4.1, the > security model ought to be called out and discussed in detail, separately. I'm not clear on what detail you think is missing. > I suggest specifying the details of the remote query service into a separate > section, if not a separate document. (A separate document would be > appropriate > if the configuration service has other plausible clients, besides this one > type > of UA.) The draft as it is is intended to support any SIP UA. I'm not clear on which query you mean by 'remote query service' or why it should be specified anywhere else. > Detailed comments: > > > Section 1.1 > > Presumably "is free to" should be replaced by MAY, since this is intended to > be > a normative document and statements in a Scope section specify boundaries. I have no problem with that. > Section 2.1 > > Section 2.1 dictates platform behaviors for network and link-layer > configuration. This kind of detail, in this kind of document, encourages > divergent support, since it specifies details that are normally provided > elsewhere. > > At most, the section should provide a generic reference to "standard" IP > support > and leave it at that. My own suggestion is to say that IP and link > configuration are outside the scope of the document. Our intent was to specify a profile of "standard" (whatever that means) IP support; the consensus was that being specific would increase the likelihood that different implementations and deployments would have the same expectations. > Section 2.2 > > Is "DNS Name" a domain name or is it a host name? If I understand your question correctly, it is a domain name. Given the usage of the value (section 2.3.1), I think that's clear. > Section 2.2.1 > > > Local Network Domain" is an essential parameter, but is undefined. The > > reference to 2.1.2 does not resolve. Section 2.1.2 (last paragraph) says: In either case, if the DHCP or DHCPv6 service provides a domain name value or values for the option concerned, the UA MUST save those domain names as candidates for use as the Local Network Domain. > It is probably also worth confirming that an automatically-supplied domain > name > is an organizational string (DNS suffix) rather than the fully qualified name > of > the UA. Given that the draft describes the DHCP(v6) option values where this comes from, I don't understand why anything more might be needed. > About "network", a term like "local network domain" is probably not as > meaningful as one might wish, given the decoupling between IP networks and > Domains. My guess is that the specification should simply say "local domain". The draft only uses the term capitalized... and defines that term in that form as the d
RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
> -Original Message- > From: Scott Lawrence [mailto:xmlsc...@gmail.com] > Sent: Tuesday, April 06, 2010 2:10 PM > To: Hadriel Kaplan > > On Tue, 2010-04-06 at 13:39 -0400, Hadriel Kaplan wrote: > > This draft says nothing at all about the ordering of the change notice > subscription vs any registration. Oy vey. The more you keep explaining what the draft does NOT specify, the more worried I get. :( > > It's lighter weight because there's no subscription messaging, no > > permanent dialog state, and even the gruu is constructable and does > > not need to be stored by the SSP, only by the UA. > > [sarcasm=on] I don't know why the IETF keeps trying to put state into > > the middle instead of leaving it in the ends! :) [sarcasm=off] > > I'd be open to a fully worked out proposal based on PUBLISH, but I > actually don't think that there are big savings over a SUBSCRIBE based > mechanism. I don't buy the argument that the dialog state is > burdensome - it's a few hundred bytes at most (and much of that size is > under the control of the server). I think we just have to agree to disagree then. If you really think having all UA's SIP-Subscribe, ad infinitum, is not more expensive and error-prone than just sending a single message to it if and only when you need to, then we just live in different Worlds. It's just an informational draft and you don't need to appease me anyway. > I do have some problem with making the notification some kind of side > effect of the 'normal' registration. REGISTER exists to map an AOR to > one or more Contacts. The Configuration Service needs to be able to > address the change notice (whatever method carries it) to a specific UA, > _not_ to the AOR of some user registered to that UA. It's not an AoR, it's a gruu. (or could be... I don't care what form it takes) But it occurs to me I should just shut up and stop trying to argue - my company will probably profit nicely from this draft. ;) -hadriel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
> > I do have some problem with making the notification some kind of side > > effect of the 'normal' registration. REGISTER exists to map an AOR to > > one or more Contacts. The Configuration Service needs to be able to > > address the change notice (whatever method carries it) to a specific UA, > > _not_ to the AOR of some user registered to that UA. On Tue, 2010-04-06 at 16:41 -0400, Hadriel Kaplan wrote: > It's not an AoR, it's a gruu. (or could be... I don't care what form > it takes) I think that you miss my point. REGISTER does not identify a UA - it identifies some AOR. If we were to define a form of registration that does identify the UA so that that the configuration service could address each UA uniquely, that would be a good thing (for this and other purposes). > But it occurs to me I should just shut up and stop trying to argue - > my company will probably profit nicely from this draft. ;) I have no problem either with you stopping or with your company making a nice profit :-) (indeed, the whole point of this is to make SIP adoption much easier - a rising tide - if your boat floats better than others, that's fine with me). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
Hadriel Kaplan said: "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 " [BA] I agree with your assessment. This is one of those situations where (infrequent) polling scales better. That is how currently most OS update mechanisms work; they poll the update servers at intervals orders of magnitude longer than NAT refresh times (e.g. weekly or daily at most), with randomized polling times. That way there is no need to maintain NAT bindings, and no danger of "flash crowds". Yes, it might take a while to bring all the clients up to the latest version, but if you've got any substantial client population, then you need to spread out the updates anyway to control the load on the update servers. In my experience, even where NOTIFY is used to provide update notifications today, SUBSCRIBE is not. Yes, that is non-standard, but I think it demonstrates concern about the overhead relating to SIP subscription/refresh. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
On 4/6/2010 10:59 AM, Henning Schulzrinne wrote: Avalanche (restart) has its own set of problems - including overwhelming either the HTTP server, SSP or registrar. (In a draft, we've made proposals how to address this in some cases, as long as the UA can detect that it is likely part of an avalanche.) As we've seen from the SIP overload discussion, you can't rely on the "natural" throttling of the server to nicely space out requests - the whole thing is much more likely to collapse in a heap, FWIW, this is a time-honored topic. In the mid/late 80's, I believe this problem was referred to as the West Point problem, since all the cadets would turn on their network-connected PCs at exactly 8am. Ungermann-Bass vs. Bridge Communication had fundamentally different network booting models. One worked well under this sort of load. One didn't. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
On 4/6/2010 1:39 PM, Scott Lawrence wrote: On Mon, 2010-04-05 at 17:10 -0700, Dave CROCKER wrote: By title and Introductory text, the document specifies its scope as user agent configuration by non-technical users. The actual contents of the specification suggests a broader scope, also covering automated (non-human) configuration, as well as the details of a remote "Configuration Service". I'm not sure what you're asking or suggesting above... the specification describes automated (or at worst mostly automated) procedures for user agent configuration, because that's what non-technical users need. Do you see a distinction or think that some clarification is needed? The specification appears to provide for human interaction. That's not automated. It also appears to provide all the details for the remote service. Contrary to your view that the spec does not provide the details for that service, I'd say that it provides quite a bit of such detail. Perhaps not all that is necessary, but quite a bit. Perhaps the disparity in my assessment and yours is the difference between visible versus internal details. From my perspective, this document provides most or all of the external details. Since the IETF specifies protocol behaviors and not internal implementation or internal functional details, that's enough to count as an IETF specification. It even mandates access via HTTPS rather than HTTP, independent of whether other security mechanisms would suffice. That is, the document slips into specifying an integrated service, not just the configuration for a component of that service. Our goal was to specify a simple set of rules that every UA and CS could implement that would ensure interoperability. It usually helps to distinguish between the core, essential features versus optional ones. TLS is obviously a respectable choice. But some environments don't need it. The Subscription feature has utility. But its implementation and operations cost make it appropriate to specify as an option, not a mandated universal feature. (Contrary to Cullen's point, I see this specification as mandating the /use/ of that feature, not just its implementation. The style for specifying the distinction is quite different from what's in this document.) While we could have put in some words about how there might exist circumstances in which HTTP would be appropriate and sufficiently secure, it was our judgement that such text would not advance the goal. Yes, if your network is all glass fiber and has quantum crypto at the physical layer then maybe you don't need https... As I suggested in the review, at the least the document should have some discourse about its security model, to justify security-related mandatory behaviors. (see below) Given the significant security-related detail provided in Section 2.4.1, the security model ought to be called out and discussed in detail, separately. I'm not clear on what detail you think is missing. I'm not a security geek but have had the pleasure of interacting with some. I've been particularly thrilled to experience the demands of such things as documenting a threat model. But still don't understand the security arena (filled with sand, of course) to describe the requirements. Perhaps a security area personage can assist here. And that assistance might well be to dismiss what I'm suggesting -- but I doubt it. I suggest specifying the details of the remote query service into a separate section, if not a separate document. (A separate document would be appropriate if the configuration service has other plausible clients, besides this one type of UA.) The draft as it is is intended to support any SIP UA. I'm not clear on which query you mean by 'remote query service' or why it should be specified anywhere else. The CS is the remote query service. Section 2.1 Section 2.1 dictates platform behaviors for network and link-layer configuration. This kind of detail, in this kind of document, encourages divergent support, since it specifies details that are normally provided elsewhere. At most, the section should provide a generic reference to "standard" IP support and leave it at that. My own suggestion is to say that IP and link configuration are outside the scope of the document. Our intent was to specify a profile of "standard" (whatever that means) IP support; the consensus was that being specific would increase the likelihood that different implementations and deployments would have the same expectations. The desire to do a product specification is understandable. However that's not what the IETF usually standardizes. For all of the many user-level specifications done in the IETF, precious few dictate DHCP details. In particular, as I said, repeating detail present in other standards specifications is a good way to create divergent specifications. Simply declare the use of standards and say no more.
Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
On 4/6/2010 9:34 AM, Scott Lawrence wrote: What is the justification that mandates a more complex model than these use? It's not usually considered sufficient to simply cite the fact that some operators somewhere want something different. There needs to be a compelling case made. It is always possible to invent edge cases that appear to justify a different paradigm. The real question is about real need. The configuration data we're discussing here is substantially more complex and more important to the operation of the device than the information provided by either DHCP or DNS. The data are more "important" than the device's IP Address? As for "complexity", I don't see how the choice of update mechanism is affected by data complexity. > A better analogy would be the full configuration information for a router - would anyone argue that only being able to change the configuration of router once every 24 hours would be sufficient? Each SIP UA is like an Internet Router? Given that operators have survived nicely with the DHCP and DNS models, what is the /compelling/ need for doing something differently for the current proposal? It will greatly help discussion to have operators represent themselves. If they really believe the more complex update model is essential, they should lobby for it themselves. The IETF is nicely open to such participation... But we can't require it. Unfortunately, direct participation is how the IETF measures things. Second- and third-hand reports are subject to too much noise in the communication path. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
On Wed, 2010-04-07 at 08:59 -0700, Dave CROCKER wrote: > > On 4/6/2010 9:34 AM, Scott Lawrence wrote: > >> What is the justification that mandates a more complex model than > >> these use? It's not usually considered sufficient to simply cite the fact > >> that > >> some operators somewhere want something different. There needs to be a > >> compelling case made. > >> > >> It is always possible to invent edge cases that appear to justify a > >> different > >> paradigm. The real question is about real need. > > > > The configuration data we're discussing here is substantially more > > complex and more important to the operation of the device than the > > information provided by either DHCP or DNS. > > The data are more "important" than the device's IP Address? > > As for "complexity", I don't see how the choice of update mechanism is > affected > by data complexity. Spenser was correct in complexity analogy, but there's more to it than that. In SIP (at least in the phone/communication systems I'm most familiar with) the functionality of the system as a whole is distributed - some things are done in a proxy, some are done in various 'feature servers', and many things are done in the UAs themselves. For many changes in 'phone system' behavior to be done correctly, one must change the behavior of the UAs at the edge. Pushing intelligence out to the edge has many nice scaling and evolution qualities, but it has downsides too; specifically the need to be able to modify configuration data in many devices at the edge of the network. Typical SIP phones have hundreds of configuration parameters - the few that are listed here are not the ones that would need changing frequently. Since there is no standard for what those parameters are or how they are expressed, they are not in scope for this spec (personally, I'd have left all of section 3 out). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
A general note on the history of this document and the context in which it was developed, in hopes of illuminating why it has some of the features that you don't like... This was created as a SIP Forum document to guide the interaction between User Agents and the Configuration Service for a SIP domain (that is, a domain name that appears in a SIP URL). Under SIP Forum rules, working groups are not supposed to do protocol design; they are supposed to create profiles of existing standards to promote interoperability. This specifically often means eliminating some of the alternatives allowed for by the underlying standards (the RFC allows some system to do X or Y, but this profile requires X). IETF specifications, and certainly IETF SIP specifications very often (for good and valid reasons) allow many possible choices to fit a wide range of contexts. That's a fine thing, but can lead to everyone being able to claim conformance while no two implementations can communicate. The SIP Forum decided that one of the important barriers to adoption of SIP technology is the complexity of configuration of SIP User Agents, and especially setting up the initial association of a UA with a SIP domain. This specification was created in response to that need. As such, it includes constraints and requirements on how various parameters should be obtained, and they are often spelled out to a level of detail that might not be usual in an IETF specification (such as some of the DHCP issues you raise). The task group created the procedures it describes by combining usages of a number of existing and well specified IETF protocols (DHCP, DNS, HTTP, SIP); the SIP Forum Board, however, decided that the result was itself sufficiently new that it constituted a new protocol and that it should therefor be sent to the IETF to be published as an RFC. If we'd started with that goal, then perhaps this spec would have been written slightly differently, and then we'd have written a SIP Forum profile document narrowing it and adding details that an IETF reader might not need. I admit that as the document editor, I skipped that refactoring process when producing the I-D form of the document that you've seen. Should the collective wisdom of the IETF process require it, something like that could be done Some additional responses embedded below... On Tue, 2010-04-06 at 20:56 -0700, Dave CROCKER wrote: > > On 4/6/2010 1:39 PM, Scott Lawrence wrote: > > On Mon, 2010-04-05 at 17:10 -0700, Dave CROCKER wrote: > >> By title and Introductory text, the document specifies its scope as user > >> agent > >> configuration by non-technical users. The actual contents of the > >> specification > >> suggests a broader scope, also covering automated (non-human) > >> configuration, as > >> well as the details of a remote "Configuration Service". > > > > I'm not sure what you're asking or suggesting above... the specification > > describes automated (or at worst mostly automated) procedures for user > > agent configuration, because that's what non-technical users need. Do > > you see a distinction or think that some clarification is needed? > > The specification appears to provide for human interaction. That's not > automated. > > It also appears to provide all the details for the remote service. Contrary > to > your view that the spec does not provide the details for that service, I'd > say > that it provides quite a bit of such detail. Perhaps not all that is > necessary, > but quite a bit. > > Perhaps the disparity in my assessment and yours is the difference between > visible versus internal details. From my perspective, this document provides > most or all of the external details. Since the IETF specifies protocol > behaviors and not internal implementation or internal functional details, > that's > enough to count as an IETF specification. I guess I still don't understand what you think that the problem is here. > >> It even mandates access via HTTPS rather than HTTP, independent of whether > >> other > >> security mechanisms would suffice. That is, the document slips into > >> specifying > >> an integrated service, not just the configuration for a component of that > >> service. > > > > Our goal was to specify a simple set of rules that every UA and CS could > > implement that would ensure interoperability. > > It usually helps to distinguish between the core, essential features versus > optional ones. TLS is obviously a respectable choice. But some environments > don't need it. The Subscription feature has utility. But its implementation > and operations cost make it appropriate to specify as an option, not a > mandated > universal feature. (Contrary to Cullen's point, I see this specification as > mandating the /use/ of that feature, not just its implementation. The style > for > specifying the distinction is quite different from what's in this document.) It does indirectly mandate the use of T
RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
Just catching up on this discussion, after a period of absence. As chair of the SIP Forum Task Group that carried out this work, I concur with the summary below from Scott and also his various earlier postings answering questions raised on this list - thanks Scott. A further comment below. > -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On > Behalf Of Scott Lawrence > Sent: 07 April 2010 20:10 > To: dcroc...@bbiw.net > Cc: ietf@ietf.org > Subject: Re: Last Call: > draft-lawrence-sipforum-user-agent-config (Session Initiation > Protocol (SIP) User Agent Configuration) to Informational RFC > > A general note on the history of this document and the > context in which > it was developed, in hopes of illuminating why it has some of the > features that you don't like... > > This was created as a SIP Forum document to guide the interaction > between User Agents and the Configuration Service for a SIP > domain (that > is, a domain name that appears in a SIP URL). Under SIP Forum rules, > working groups are not supposed to do protocol design; they > are supposed > to create profiles of existing standards to promote interoperability. > This specifically often means eliminating some of the alternatives > allowed for by the underlying standards (the RFC allows some system to > do X or Y, but this profile requires X). IETF specifications, and > certainly IETF SIP specifications very often (for good and valid > reasons) allow many possible choices to fit a wide range of contexts. > That's a fine thing, but can lead to everyone being able to claim > conformance while no two implementations can communicate. > > The SIP Forum decided that one of the important barriers to > adoption of > SIP technology is the complexity of configuration of SIP User Agents, > and especially setting up the initial association of a UA with a SIP > domain. This specification was created in response to that need. As > such, it includes constraints and requirements on how various > parameters > should be obtained, and they are often spelled out to a level > of detail > that might not be usual in an IETF specification (such as some of the > DHCP issues you raise). The task group created the procedures it > describes by combining usages of a number of existing and > well specified > IETF protocols (DHCP, DNS, HTTP, SIP); the SIP Forum Board, however, > decided that the result was itself sufficiently new that it > constituted > a new protocol and that it should therefor be sent to the IETF to be > published as an RFC. If we'd started with that goal, then > perhaps this > spec would have been written slightly differently, and then we'd have > written a SIP Forum profile document narrowing it and adding details > that an IETF reader might not need. I admit that as the document > editor, I skipped that refactoring process when producing the I-D form > of the document that you've seen. Should the collective wisdom of the > IETF process require it, something like that could be done > > Some additional responses embedded below... > > On Tue, 2010-04-06 at 20:56 -0700, Dave CROCKER wrote: > > > > On 4/6/2010 1:39 PM, Scott Lawrence wrote: > > > On Mon, 2010-04-05 at 17:10 -0700, Dave CROCKER wrote: > > >> By title and Introductory text, the document specifies > its scope as user agent > > >> configuration by non-technical users. The actual > contents of the specification > > >> suggests a broader scope, also covering automated > (non-human) configuration, as > > >> well as the details of a remote "Configuration Service". > > > > > > I'm not sure what you're asking or suggesting above... > the specification > > > describes automated (or at worst mostly automated) > procedures for user > > > agent configuration, because that's what non-technical > users need. Do > > > you see a distinction or think that some clarification is needed? > > > > The specification appears to provide for human interaction. > That's not automated. > > > > It also appears to provide all the details for the remote > service. Contrary to > > your view that the spec does not provide the details for > that service, I'd say > > that it provides quite a bit of such detail. Perhaps not > all that is necessary, > > but quite a bit. > > > > Perhaps the disparity in my assessment and yours is the > difference between > > visible versus internal details. From my perspective, this > document provides > > most or all of the external details. Since the IETF > specifies protocol
RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
Howdy, I said I would shut up, but I missed one question from Cullen, which was: > This conversation constantly confuses the issue of must implement vs must > deploy. Which one are you objecting to here. Answer: I am objecting to there not *being* a distinction between must implement vs. must deploy in this draft. The draft requires the implementation and DEPLOYMENT of a SIP Subscription service. It is not optional to use. It is not optional to deploy. Through some careful analysis of the implementation requirements stipulated in the draft, one may be able to find an exemption path to avoid deployment by means of configuration - but the language of the requirements to do so is so weak that it's meaningless. You cannot stipulate that a "UA MAY do foo" in a SIP-Forum profile or IETF RFC, and then expect administrators to rely on that foo for anything useful whatsoever, because not all UAs are required to do foo. Some will, some won't. All of them will be compliant. This basically defeats the whole point of having an "implementation profile", imho. For example, the following requirements are stipulated: The User Agent MAY obtain configuration information by any means in addition to those specified here, and MAY use such information in preference to any of the steps specified below, but MUST be capable of using these procedures alone in order to be compliant with this specification. ... The UA MAY at any time return to any earlier step in the process of obtaining configuration data. ... The UA MAY use configuration data that is of unknown validity, or configuration data that is known to be no longer valid, while attempting to revalidate that data or obtain new data. There is no assurance that such configuration data is still useful, but the UA is NOT REQUIRED to stop using or delete the data. These requirements are all completely meaningless, in the sense that they do not provide any reliable behavior. -hadriel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
On Thu, 2010-04-08 at 04:12 -0400, Hadriel Kaplan wrote: > Howdy, > I said I would shut up, but I missed one question from Cullen, which was: > > This conversation constantly confuses the issue of must implement vs must > > deploy. Which one are you objecting to here. > > Answer: I am objecting to there not *being* a distinction between must > implement vs. must deploy in this draft. The draft requires the > implementation and DEPLOYMENT of a SIP Subscription service. It is > not optional to use. It is not optional to deploy. Well, one could argue that a provider could cause the returned SIP url for the change notice subscription to be one for which there is no routing (return 'Link: '). By the rules, the UA would periodically make a DNS request to try to find it, but would be allowed to use the configuration data. Silly, but allowed. No one is going to be forced to use any of this specification. If you don't want the features it provides (automatic initial configuration with prompt updates), then don't use it. At the risk of repeating myself, I want to make sure that one reason for using SUBSCRIBE/NOTIFY for the change notices is clear: there is no other existing standard way to address a specific User Agent. User Agents do not register a contact that identifies the device (or program); they register addresses that identify users (SIP AORs), and those same addresses might well also map to other UAs. If I want to change the configuration of exactly one device, I need a way to send a message just to that one device. Putting a subscription URL in the Link header returned by the HTTPS configuration data response allows the Configuration Service to associate every item of configuration data with the devices that have it, so that when that data it is possible to send a message to exactly the set of devices that need to know. > Through some careful analysis of the implementation requirements > stipulated in the draft, one may be able to find an exemption path to > avoid deployment by means of configuration - but the language of the > requirements to do so is so weak that it's meaningless. If you have a suggestion for better wording that preserves the intent, I'm happy to hear it. > You cannot stipulate that a "UA MAY do foo" in a SIP-Forum profile or > IETF RFC, and then expect administrators to rely on that foo for > anything useful whatsoever, because not all UAs are required to do > foo. Some will, some won't. All of them will be compliant. This > basically defeats the whole point of having an "implementation > profile", imho. In general I agree with that paragraph, and have tried hard not to put that particular kind of problem into this spec. I don't think that any of the examples you cite below produce the kind of problem you describe. I'll attempt below to explain why each are needed... > For example, the following requirements are stipulated: >The User Agent MAY obtain configuration information by any means in >addition to those specified here, and MAY use such information in >preference to any of the steps specified below, but MUST be capable >of using these procedures alone in order to be compliant with this >specification. The MAY 'escape' clauses above are there primarily to allow a configuration to 'stick'. The user of a UA may want to configure it such that the UA can be moved to different networks but keep the association with the SIP domain it is configured for. If I configure my phone to register with my company SIP service, and then take that phone to my home office or a hotel, I may not want it to even try to reconfigure itself to the domain provided by the local network DHCP, even though it needs to use DHCP to get local IP configuration data. They also allow for deployment in particular environments that may have special needs, such as a very high security environment that requires preconfigured keying material and static IP addresses. These clauses are there to make it clear that such behavior is allowed by the specification. The MUST is there to ensure that one cannot argue that because other means are available the device conforms to this spec even though it actually requires that the manual or other mechanisms always be used - exactly the problem you describe above. >The UA MAY at any time return to any earlier step in the >process of obtaining configuration data. I'm not sure how this fits the pattern you're concerned about. It does not allow the device to do anything other than start over doing a step that's in the spec. It's there to give an implementer flexibility in error handling. Perhaps it doesn't need to be said, but I (and others) felt that making this explicit would prevent over-zealous testers from being too rigid in requiring particular error behavior. (In practice, this is always true anyway... the "give up an reboot" response) >The UA MAY use configuration data that is of unknown validity, or >confi
RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
Lets not forget what this specification was attempting to solve, which has been the well known boot strap problem with SIP-CUA's we have collectively ignored since the creation of SIP, especially those that might use (dare I say it) phone numbers. The model here is to make such things as SIP CUA's as easy to use as traditional POTS phones. Plug them in, they work.. at least now after punching in a small data string into the keypad of a device, instead of having to manually Config the device using some on board HTTP app. As the success of some Apple devices testify ( and Skype for that matter) ..making complex electronics configuration nearly stupid proof increases the overall market. :-) This could also expand the market for SIP devices and the for competitive SIP services by permitting them to be sold at mass market outlets without being necessarily tied to one SSP, if, yes, they were compliant with the specification and yes Hadriel you had a branded logo program that insured compliance. The SIP Forum is "not there yet" on that kind of testing, compliance and logo program. Any discussion of how to improve the specification is useful but the goal is the expansion of SIP related services in the market. Gee sort of what we are trying to do with the PBX to SSP issues. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Scott Lawrence Sent: Thursday, April 08, 2010 9:37 AM To: Hadriel Kaplan Cc: Cullen Jennings; IETF Discussion Mailing List Subject: RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC On Thu, 2010-04-08 at 04:12 -0400, Hadriel Kaplan wrote: > Howdy, > I said I would shut up, but I missed one question from Cullen, which was: > > This conversation constantly confuses the issue of must implement vs must > > deploy. Which one are you objecting to here. > > Answer: I am objecting to there not *being* a distinction between must > implement vs. must deploy in this draft. The draft requires the > implementation and DEPLOYMENT of a SIP Subscription service. It is > not optional to use. It is not optional to deploy. Well, one could argue that a provider could cause the returned SIP url for the change notice subscription to be one for which there is no routing (return 'Link: '). By the rules, the UA would periodically make a DNS request to try to find it, but would be allowed to use the configuration data. Silly, but allowed. No one is going to be forced to use any of this specification. If you don't want the features it provides (automatic initial configuration with prompt updates), then don't use it. At the risk of repeating myself, I want to make sure that one reason for using SUBSCRIBE/NOTIFY for the change notices is clear: there is no other existing standard way to address a specific User Agent. User Agents do not register a contact that identifies the device (or program); they register addresses that identify users (SIP AORs), and those same addresses might well also map to other UAs. If I want to change the configuration of exactly one device, I need a way to send a message just to that one device. Putting a subscription URL in the Link header returned by the HTTPS configuration data response allows the Configuration Service to associate every item of configuration data with the devices that have it, so that when that data it is possible to send a message to exactly the set of devices that need to know. > Through some careful analysis of the implementation requirements > stipulated in the draft, one may be able to find an exemption path to > avoid deployment by means of configuration - but the language of the > requirements to do so is so weak that it's meaningless. If you have a suggestion for better wording that preserves the intent, I'm happy to hear it. > You cannot stipulate that a "UA MAY do foo" in a SIP-Forum profile or > IETF RFC, and then expect administrators to rely on that foo for > anything useful whatsoever, because not all UAs are required to do > foo. Some will, some won't. All of them will be compliant. This > basically defeats the whole point of having an "implementation > profile", imho. In general I agree with that paragraph, and have tried hard not to put that particular kind of problem into this spec. I don't think that any of the examples you cite below produce the kind of problem you describe. I'll attempt below to explain why each are needed... > For example, the following requirements are stipulated: >The User Agent MAY obtain configuration information by any means in >addition to those specified here, and MAY use such information in >preference to any of the steps specified below, but MUST be capable >of using these procedures
RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
> -Original Message- > From: Richard Shockey [mailto:rich...@shockey.us] > Sent: Thursday, April 08, 2010 10:34 AM > > Lets not forget what this specification was attempting to solve, which has > been the well known boot strap problem with SIP-CUA's we have collectively > ignored since the creation of SIP, especially those that might use (dare I > say it) phone numbers. I am not forgetting that at all. That's one of the reasons I find it so perplexing that a draft which is supposed to make things easy and simple for "boot strapping", has decided to mandate a nice-to-have feature which adds complexity and is not required for boot-strapping. > Any discussion of how to improve the specification is useful but the goal > is > the expansion of SIP related services in the market. Gee sort of what we > are > trying to do with the PBX to SSP issues. Right, and as we learned with PBX to SSP issues in SIP-Connect 1.0, not being extremely specific and getting it right the first time will hurt you later. ;) -hadriel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
> -Original Message- > From: Scott Lawrence [mailto:xmlsc...@gmail.com] > Sent: Thursday, April 08, 2010 9:37 AM > To: Hadriel Kaplan > > Well, one could argue that a provider could cause the returned SIP url > for the change notice subscription to be one for which there is no > routing (return 'Link: '). By the rules, the > UA would periodically make a DNS request to try to find it, but would be > allowed to use the configuration data. Silly, but allowed. Right, but the since that would make it an "unknown validity" config, and the requirements do not mandate any UA to *use* an "unknown validity" config... do you see a problem? Instead of getting into an unknown-behavior state, why don't you simply allow the HTTP response to NOT have a Link header, or define a NULL URI to use - and then state that it means there is no Subscription service and the UA MUST consider the HTTP-based config valid? > No one is going to be forced to use any of this specification. If you > don't want the features it provides (automatic initial configuration > with prompt updates), then don't use it. So we should go define another profile which is a textual copy of this one, but changes two sentences?? Is that really good for SIP or the SIP-Forum? > At the risk of repeating myself, I want to make sure that one reason for > using SUBSCRIBE/NOTIFY for the change notices is clear: there is no > other existing standard way to address a specific User Agent. Right, I understand that you have no other way to do X. Fine, so specify how to do X. Don't mandate that X be used with Y, when Y does not depend on X to function properly, and X is not trivial. -hadriel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
True.. but I don't think anyone realized when we began the SIP Connect 1.1 process and MARTINI that what is a simple business issue "I just want to plug in foo and it works." would turn into a total philosophical debate of the SIP registration process. This is why members of our Board insisted that the proposed informational documents be reviewed by the usual RAI suspects here in the IETF. In retrospect I think that was a reasonable idea. I think the proposed PAN registry, however, is essential to make this all work but that IMHO is utterly outside the scope of the IETF. > -Original Message- > From: Richard Shockey [mailto:rich...@shockey.us] > Sent: Thursday, April 08, 2010 10:34 AM > > Lets not forget what this specification was attempting to solve, which has > been the well known boot strap problem with SIP-CUA's we have collectively > ignored since the creation of SIP, especially those that might use (dare I > say it) phone numbers. I am not forgetting that at all. That's one of the reasons I find it so perplexing that a draft which is supposed to make things easy and simple for "boot strapping", has decided to mandate a nice-to-have feature which adds complexity and is not required for boot-strapping. > Any discussion of how to improve the specification is useful but the goal > is > the expansion of SIP related services in the market. Gee sort of what we > are > trying to do with the PBX to SSP issues. Right, and as we learned with PBX to SSP issues in SIP-Connect 1.0, not being extremely specific and getting it right the first time will hurt you later. ;) -hadriel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
On Thu, 2010-04-08 at 15:15 -0400, Hadriel Kaplan wrote: > > > -Original Message- > > From: Scott Lawrence [mailto:xmlsc...@gmail.com] > > Sent: Thursday, April 08, 2010 9:37 AM > > To: Hadriel Kaplan > > > > Well, one could argue that a provider could cause the returned SIP url > > for the change notice subscription to be one for which there is no > > routing (return 'Link: '). By the rules, the > > UA would periodically make a DNS request to try to find it, but would be > > allowed to use the configuration data. Silly, but allowed. > > Right, but the since that would make it an "unknown validity" config, > and the requirements do not mandate any UA to *use* an "unknown > validity" config... do you see a problem? The requirements explicitly allow the UA to use an "unknown validity" configuration. I don't think it would be appropriate to put in a MUST that says the UA should use any configuration data response - the data may be in the wrong format, corrupt, or have any other problem, so that would just lead to a different argument. > Instead of getting into an unknown-behavior state, why don't you > simply allow the HTTP response to NOT have a Link header, or define a > NULL URI to use - and then state that it means there is no > Subscription service and the UA MUST consider the HTTP-based config > valid? > > No one is going to be forced to use any of this specification. If you > > don't want the features it provides (automatic initial configuration > > with prompt updates), then don't use it. > > So we should go define another profile which is a textual copy of this > one, but changes two sentences?? Is that really good for SIP or the > SIP-Forum? > > At the risk of repeating myself, I want to make sure that one reason for > > using SUBSCRIBE/NOTIFY for the change notices is clear: there is no > > other existing standard way to address a specific User Agent. > > Right, I understand that you have no other way to do X. Fine, so > specify how to do X. Don't mandate that X be used with Y, when Y does > not depend on X to function properly, and X is not trivial. Perhaps our fundamental disagreement is whether or not having a prompt way to reconfigure a UA is a requirement. When the SIP Forum chartered this work, it was agreed that that was requirement (and I certainly think it is). I think that a configuration mechanism that does not allow for updates under the control of the service won't be successful. Could we allow the Configuration Service to omit the Link? Obviously, we could. I think that would materially reduce the utility of the protocol and would be a bad idea. Clearly we differ on that. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
> -Original Message- > From: Scott Lawrence [mailto:xmlsc...@gmail.com] > Sent: Thursday, April 08, 2010 4:51 PM > > On Thu, 2010-04-08 at 15:15 -0400, Hadriel Kaplan wrote: > > Right, but the since that would make it an "unknown validity" config, > > and the requirements do not mandate any UA to *use* an "unknown > > validity" config... do you see a problem? > > The requirements explicitly allow the UA to use an "unknown validity" > configuration. We must be having a communication problem. :) "Allowing" the UA to do something in this context means nothing. It means nothing because it has no teeth - the UA does not need to follow the MAY statement. Because it does not need to, some won't. If some won't, then the administrator cannot rely on UA's to do it, to accomplish a goal (in this case, the goal of not doing a subscription). > I don't think it would be appropriate to put in a MUST > that says the UA should use any configuration data response - the data > may be in the wrong format, corrupt, or have any other problem, so that > would just lead to a different argument. That's a red herring. If the data is corrupt or wrong format, it couldn't be used even if it were of unknown validity. And it's not like the Subscription would fix it. There's a fundamental difference between the failure of a protocol/state-machine/parsing, and a disabled feature. Let me put it in a different way: what the ua-config model is about is basically provisioning, right? Would you expect a provisioning command to take effect (assuming its understood), or would you expect the device being provisioned to decide whether it takes effect or not? > Perhaps our fundamental disagreement is whether or not having a prompt > way to reconfigure a UA is a requirement. When the SIP Forum chartered > this work, it was agreed that that was requirement (and I certainly > think it is). I think that a configuration mechanism that does not > allow for updates under the control of the service won't be successful. Was it a requirement to support, or a requirement to use? > Could we allow the Configuration Service to omit the Link? Obviously, > we could. I think that would materially reduce the utility of the > protocol and would be a bad idea. Clearly we differ on that. Yup, on that we agree. :) And for the record, it's not that I don't see the intrinsic value in immediate updates - it's that the mechanism to do so can't be disabled from the get-go. The ua-config framework is about configuration, but this particular feature is not using the framework to be enabled/disabled, when it clearly could be. -hadriel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
On Apr 8, 2010, at 13:51 , Scott Lawrence wrote: > > Perhaps our fundamental disagreement is whether or not having a prompt > way to reconfigure a UA is a requirement. When the SIP Forum chartered > this work, it was agreed that that was requirement (and I certainly > think it is). I think that a configuration mechanism that does not > allow for updates under the control of the service won't be successful. +1 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
On Apr 6, 2010, at 16:47 , Bernard Aboba wrote: > Hadriel Kaplan said: > > “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 ” > > [BA] I agree with your assessment. This is one of those situations where > (infrequent) polling scales better. That is how currently most OS update > mechanisms work; they poll the update servers at intervals orders of > magnitude longer than NAT refresh times (e.g. weekly or daily at most), with > randomized polling times. That way there is no need to maintain NAT > bindings, and no danger of “flash crowds”. Yes, it might take a while to > bring all the clients up to the latest version, but if you’ve got any > substantial client population, then you need to spread out the updates anyway > to control the load on the update servers. > So there are somethings like upgrading the software firmware on phones where a slow roll over makes sense, however there are other things like moving from a 4 digit to 5 digit internal dialing plan where you want to flash cut over all the phones at a given site. Can you imagine telling a site, uh, your phone will switch from 4 to 5 digit dialing some time in the next few days - if 4 digit stops working, try 5 digits and see if that works. That the sort of think that generates support calls that are far more expensive than servers. I realize that if you put the poll rate low enough, polling can achieve the same as notification but the rates required for many services make notification scale better than polling. > In my experience, even where NOTIFY is used to provide update notifications > today, SUBSCRIBE is not. Yes, that is non-standard, but I think it > demonstrates concern about the overhead relating to SIP subscription/refresh. > __ Having dealt with many or the problems that come from setting MWI lights using NOTIFY without subscribe I am fairly confident that this NOTify without SUBscribe is broken is some many ways it is not even worth discussing. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
