ietf
[Top] [All Lists]

Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC

2010-04-06 10:53:19

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(_at_)ietf(_dot_)org 
[mailto:ietf-bounces(_at_)ietf(_dot_)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(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>