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. (i
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 tha
> -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 a
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 t
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 th
> -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
> -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 t
ullen 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 misse
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
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 dep
.
> -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 In
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 do
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
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 alway
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 coveri
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 aval
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 U
> > 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,
> -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
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 d
lto: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
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
>
> 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 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
> -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
> > milli
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
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
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 tha
> -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
> confi
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
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 coverin
> -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
>
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):
> >
> >
> -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,
>
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 befo
> -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 poss
> -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 i
> -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?)
>
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/rest
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
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
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
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.
__
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.
Wel
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 s
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 Su
46 matches
Mail list logo
