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