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
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
.
-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
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
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
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
-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
-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
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
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
-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
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
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
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
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
-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
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
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.
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
-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
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
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
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
...@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
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
-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
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_
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
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
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
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.
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
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
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
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
-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
-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
-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.
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
-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
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
-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
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
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
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
45 matches
Mail list logo
