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

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 1 Apr 2010 14:59:50 -0400

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

---

From: Scott Lawrence <[email-masked]>
Date: Thu, 01 Apr 2010 22:26:53 -0400

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.

> 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.

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 2 Apr 2010 12:05:39 -0400

Hi Scott,
Comments inline...

> -----Original Message-----
> From: Scott Lawrence [mailto:[email-masked]]
> Sent: Thursday, April 01, 2010 10:27 PM
> To: Hadriel Kaplan
> 
> 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.

> 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. :)

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 5 Apr 2010 08:07:07 -0600

> 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.

---

From: Scott Lawrence <[email-masked]>
Date: Mon, 05 Apr 2010 11:00:23 -0400

On Fri, 2010-04-02 at 12:05 -0400, Hadriel Kaplan wrote:

> 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).

> 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.

> 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 keep the specification
simple, with as few choices for any party as possible, because that's
the best way to reach universal interoperability.

> 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. :)

I'm quite supportive of that idea, although I'd suggest that the real
need is for a standard mechanism to address a specific UA that is not
related to the AOR of any user addresses it happens to also accept.  The
old Pingtel phones had that (a 'hidden' registration that used the
phones MAC address as the local part of the SIP URI), and I've missed
having it countless times.  We've got hacks for this in our sipXecs
system that Dale has described in an I-D, but a standard mechanism would
be far better.  Solving that general problem is beyond the scope of
this, though.

---

From: todd glassey <[email-masked]>
Date: Mon, 05 Apr 2010 08:43:42 -0700

> 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.
> value and all the DNS records that control routing for the domain in

But since you have not restricted them from doing this really stupid
thing you cannot assume they wont.

> whenever possible. 

Then why make any Assumptions about anything?

 This is purely my own personal opinion, but I think
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Scott Lawrence <[email-masked]>
Date: Mon, 05 Apr 2010 12:04:10 -0400

> accompanying use model or BCP" for its use, so this is in fact relevant

I'm not sure what you're suggesting here...

> 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.

---

From: todd glassey <[email-masked]>
Date: Mon, 05 Apr 2010 09:26:20 -0700

> 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.

> implementation choices is the party that suffers. 
|
No its the victims they take down with them who suffer...

Todd

 In neither case does

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 5 Apr 2010 12:50:34 -0400

> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Monday, April 05, 2010 10:07 AM
> To: Hadriel Kaplan
> 

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 5 Apr 2010 13:01:25 -0400

> Sent: Monday, April 05, 2010 11:00 AM
> To: Hadriel Kaplan
> 

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

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 5 Apr 2010 13:36:12 -0400

> 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
> 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

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

---

From: Scott Lawrence <[email-masked]>
Date: Mon, 05 Apr 2010 14:30:15 -0400

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).

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 5 Apr 2010 15:09:43 -0400

> Sent: Monday, April 05, 2010 2:30 PM
> To: Hadriel Kaplan
> 
> The spec says in section 2.6

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

---

From: Scott Lawrence <[email-masked]>
Date: Mon, 05 Apr 2010 15:55:02 -0400

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, ...
        
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.

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 5 Apr 2010 17:55:55 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Scott Lawrence
> Sent: Monday, April 05, 2010 3:55 PM
> 

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.  

>         to be compliant with this specification.

Yes, I read that and was thoroughly confused. :)

> overloaded or otherwise unavailable.  It's not an 'optional 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

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 05 Apr 2010 17:10:37 -0700

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.

While I can understand requiring this identifier, I don't understand the logic
offered here.  What does "allows any UA to construct a value" have to do with
mandating the use of the value?

Section 2.3.3

This is more in the form of an example than a specification.  Having the
example.net details provided is helpful, but should be prefaced by specification
language that does not depend on the example.

2.5.1.

> Any HTTP response from the CS that provides configuration data to the UA MUST
> include a Link header as specified by [draft-roach-sip-http-subscribe]
...
> A UA that receives a successful configuration data response MUST attempt to
> maintain a subscription to the SIP URI from the Link header

This mandates that all UAs and all configuration servers participate in an
on-going, live update notification relationship.  That has complexity and
scaling effects which are worthy of justification.  Why is it not acceptable to
have some UA/CS interactions be quick and simple?

The configuration data cited in Section 3 does not appear to be of the type that
is typically highly volatile.  So the need for incurring the complexity and
scaling costs of the live-update mechanism is not automatically evident.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 6 Apr 2010 09:52:47 -0600

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 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. 

I'm sure there are some deployments where polling would be fine but there are lots that don't find this acceptable. 

> 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.

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 6 Apr 2010 12:16:10 -0400

> 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

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 06 Apr 2010 09:24:12 -0700

Cullen,

> 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

---

From: Scott Lawrence <[email-masked]>
Date: Tue, 06 Apr 2010 12:34:45 -0400

> 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?

> 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.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 6 Apr 2010 10:55:49 -0600

On Apr 6, 2010, at 10:16 AM, Hadriel Kaplan wrote:

> 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.
> 

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. 

> 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. 

Cullen Jennings

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 6 Apr 2010 13:39:26 -0400

> 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

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 06 Apr 2010 10:47:03 -0700

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 6 Apr 2010 13:59:00 -0400

> 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 fr…

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

---

From: Scott Lawrence <[email-masked]>
Date: Tue, 06 Apr 2010 14:10:06 -0400

On Tue, 2010-04-06 at 13:39 -0400, Hadriel Kaplan wrote:
> 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.

> 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).

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 6 Apr 2010 16:08:33 -0400

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:[email-masked]] 
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

Henning

---

From: Scott Lawrence <[email-masked]>
Date: Tue, 06 Apr 2010 16:39:18 -0400

> 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.  

> 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?

> 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?

> 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...

> security model ought to be called out and discussed in detail, separately.

I'm not clear on what detail you think is missing.

> if the configuration service has other plausible clients, besides this one type

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.

> a normative document and statements in a Scope section specify boundaries.

I have no problem with that.

> 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.

> 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.

> > 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.

> is an organizational string (DNS suffix) rather than the fully qualified name of

Given that the draft describes the DHCP(v6) option values where this
comes from, I don't understand why anything more might be needed.

> 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 domain name(s) provided by DHCP(v6) to be used in a
specific way in the context of these procedures.  We could remove the
word 'Network', but I'm not sure that makes it any more clear for this
purpose.

> design.  That's a discipline typically excluded from IETF work, for very good

The draft says:

        A UA MAY provide an interface by which a DNS name is provided
        directly by the user for the Configuration Service Name. 

I hardly think that constitutes user interface design.

> specification of other means of obtaining the data.

The use case that motivated this particular statement is an important
one for SIP User Agents... the user may require that the UA be
configured for a specific service (the users company, home, or a
commercial service).  Since the name of that service may not be supplied
by the local network (a wifi hotspot perhaps), there must be
alternatives means allowed.  This statement is just an attempt to make
it clear that manual means are allowed.

Do you believe that the allowing this explicitly does any harm to
interoperability?

> Configuration Service response data already configured into the UA?  Why?

No, and that is explicit in 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...
        
> whether "standard" retry procedures should retry the same server or an

so the choice is up to the implementation - that does not seem to be an
interoperability problem to me.

> Section 2.2 provides no reference to the means of obtaining a first name,

You've quoted too much of the draft for me to believe that we're reading
different specs... 2.2 references 2.2.1 and 2.2.2, which provide for
getting the name.

> the spec should say so at the beginning of the sub-section.

Immediately above this in the parent section (2.3.2), the first rule for
adding parameters is: 

        1. The UA MUST add all parameters from those defined in the
        Configuration Request Parameters (Configuration Request
        Parameters) list below for which the UA has a value. Any
        parameter from that set for which the UA does not have a value
        MUST be omitted. 

> mandating the use of the value?

The rule (quoted above) is that if the UA has a value for the parameter,
then the parameter must be sent; since every UA has a value for sfua-id,
every UA MUST send it.

> language that does not depend on the example.

That's what sections 2.3.1 and 2.3.2 do...

> scaling costs of the live-update mechanism is not automatically evident.

This point is the subject of a significant ongoing thread so I won't
repeat it here... suffice to say that the minimal configuration data
listed in section 3 is not what needs to be changed frequently or
promptly.

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 6 Apr 2010 16:41:34 -0400

> Sent: Tuesday, April 06, 2010 2:10 PM
> To: Hadriel Kaplan
> 

Oy vey.  The more you keep explaining what the draft does NOT specify, the more worried I get. :(

> 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.

> _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

---

From: Scott Lawrence <[email-masked]>
Date: Tue, 06 Apr 2010 17:01:33 -0400

> It's not an AoR, it's a gruu. (or could be... I don't care what form

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).

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 06 Apr 2010 20:04:34 -0700

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

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 06 Apr 2010 20:56:42 -0700

> 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.

> 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
> glass fiber and has quantum crypto at the physical layer then maybe you

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)

> 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.

> which query you mean by 'remote query service' or why it should be

The CS is the remote query service.

> likelihood that different implementations and deployments would have the

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.

> usage of the value (section 2.3.1), I think that's clear.

First, I believe it is not a formal term, yet this is a specification.  So the 
term should have a precise definition that refers to the precise characteristics 
of the string.  From the current text, I do not know what that is.  I raised the 
possibilility of its being a host name because that's a subset of valid domain 
names and frankly I suspect it's what you really mean.  But I'm not sure.  The 
specification should leave no doubt.

>          those domain names as candidates for use as the Local Network

Candidate, not specific selection.  And plural, not singular.  These leave open 
a lot of room for guessing.  Guessing what to use is not conducive to 
interoperability.

> word 'Network', but I'm not sure that makes it any more clear for this

I don't understand how capitalization or its lack has semantic impact in an IETF 
specification.  It's also a bit risky to focus on DHCP(v6) since there is so 
little use of it.

Is this effort intended to rely on v6 deployment before it is useful?  (Yes, I 
know the answer is no; I'm trying to highlight why it is better to say something 
more generic about the domain name you want and have DHCP [v4 and/or v6] only as 
exemplars.)

> I hardly think that constitutes user interface design.

Well, that gets to my point about the question of whether having even this is 
useful.

My guess is that the presence of this "MAY" is meaningless, since it's not 
within the scope of this document to give permission or refuse it to have this 
normative directive.

I suspect that what makes sense for the document is to have some non-normative 
text that merely reminds the implementer that one way of obtaining parameters is 
by querying users.

> it clear that manual means are allowed.

My point is that this document has no scope of authority for prohibiting such 
behavior.  So it does not mean much to have a normative statement saying it is 
allowed.

> Do you believe that the allowing this explicitly does any harm to

Yeah.  Its presence will invite some readers to believe that they are /expected/ 
to implement this mechanism.  It's a common bit of confusion abut MAY vs. SHOULD 
vs MUST.

The simple implication is that the normative language in a specification should 
say only what it MUST say and no more.  Anything else that it might want to 
include as pedagogy should be written as non-normative text.

>          information in preference to any of the steps specified below...

"MUST make a DNS request" means that the request must be made, independent of 
whether it already has the information or has another means of obtaining the 
information.

If you think the specification language with a MUST is conditional, please explain.

At the least, it is sounding as if the specification has some conflicting details.

> interoperability problem to me.

If the choice is up to the implementation, then I do not know what normative 
directive you are actually specifying in this section.

> different specs... 2.2 references 2.2.1 and 2.2.2, which provide for

Well, that's clearly the intent of 2.2.  My point was that I believe it does not 
provide the right detail to satisfy that intent.

> Immediately above this in the parent section (2.3.2), the first rule for

Hmmm.  Two comments:

1.  Yeah, I missed that.  Sorry.

2.  I am not sure I know what "for which the UA has a value" means.

My guess is that the specify really ought to say "The UA SHOULD request all 
parameters that it can use."

That said, I'm not sure I understand why even that statement is needed. 
Mandating what is subscribed intrudes on operational choice, and will be the 
wrong policy for some environments.

> then the parameter must be sent; since every UA has a value for sfua-id,

So your clarifying text is actually redundant?  Or it's merely meant to remind 
the reader that this parameter is always present.  While this could be a useful 
bit of pedagogy for the reader, it's not a normative point.

> That's what sections 2.3.1 and 2.3.2 do...

Oh my.  Right.  The word "Example" in the subsection title should have been a 
clue for me...

d/

-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 07 Apr 2010 08:59:36 -0700

On 4/6/2010 9:34 AM, Scott Lawrence wrote:
> 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

Each SIP UA is like an Internet Router?

>> it themselves.  The IETF is nicely open to such participation...

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

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 7 Apr 2010 11:52:10 -0500

> Each SIP UA is like an Internet Router?

Dave, I understood Scott's point to be that the amount of configuration were 
roughly comparable (within an order of magnitude) - Scott, did I get that 
right?

Thanks,

Spencer

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 07 Apr 2010 10:21:13 -0700

On 4/7/2010 9:52 AM, Spencer Dawkins wrote:
> Dave, I understood Scott's point to be that the amount of configuration
> were roughly comparable (within an order of magnitude) - Scott, did I
> get that right?

The specification lists a rather small number of parameters, by my count.

In addition, I am still not understanding how the scale of the data is relevant 
to the update model.

Note that original reference cited update latency, not scale.

d/
-- 

   Dave Crocker

---

From: Scott Lawrence <[email-masked]>
Date: Wed, 07 Apr 2010 14:04:26 -0400

> As for "complexity", I don't see how the choice of update mechanism is affected 

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).

---

From: Scott Lawrence <[email-masked]>
Date: Wed, 07 Apr 2010 15:10:22 -0400

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...

> enough to count as an IETF specification.

I guess I still don't understand what you think that the problem is
here.  

> specifying the distinction is quite different from what's in this document.)

It does indirectly mandate the use of TLS, since it requires that the
configuration URL be https, which must be over TLS.

In theory, I understand that there are circumstances under which the use
of TLS would not be needed to provide the authentication and
confidentiality protection that it is included here to provide.  The
document could add a bunch of additional material that explain those
needs and criteria under which it would be ok to not use TLS.  Granted.
I could probably even write it with some helpful review from the IETF
security community.   I think that the result would be less clear than
it is now, and that while TLS might not be needed in some (very very
rare) environments, it's not going to do any harm.

> specification should leave no doubt.

I think that the spec spells out quite carefully how the value is used
to construct DNS queries.  The DNS specs that it references already
clearly spell out the syntax of values used in such queries.  If 'domain
name' or 'DNS domain name' are not the right terms to use to express
that (they are _not_ fully qualified host names), then I would welcome a
suggestion of an alternative term that would be more correct (though I
suspect I'd end up wanting to add a note explaining that whatever that
term is, it's what most of us think of as a domain name).

> a lot of room for guessing.  Guessing what to use is not conducive to 

One need not guess... the spec says (section 2.2.1):

        If multiple DNS names are provided by DHCPv6 option 21, the UA
        MUST attempt to use each of the names provided, in the order
        they were given by the DHCPv6 service, until a configuration is
        successfully obtained.

in the IPv4 case the option value can provide only one name, so the
situation does not arise.

> text that merely reminds the implementer that one way of obtaining parameters is 

Some of the contributors to the document felt strongly that making a
clear statement that manual input of this value is allowed was
important.  Again, some of this reflects the difference between a more
usual (and more abstract) IETF specification and a document that the SIP
Forum could use as the basis of a conformance test (no such test has yet
been defined).  

> include as pedagogy should be written as non-normative text.

I fail to see how saying 'X MAY do Y' could be misunderstood to be a
requirement that X do Y.

I'm much more concerned that a reader whose product was meant to be used
in a way that would normally need that feature might read the document
without that statement and conclude that the specification was not
suited to their needs because it didn't clearly allow for manual input
of that key information.

> At the least, it is sounding as if the specification has some conflicting details.

As I pointed out, there is a blanket statement at the beginning that
allows implementations to modify the procedures to suit circumstances
(something you have argued for elsewhere).   I suppose it's true that I
could have instead (or in addition) made every MUST in the document
conditional.  My editorial judgment is that this way is clearer;
reasonable people may differ.

> directive you are actually specifying in this section.

The spec is just providing guidance for how to deal with an error
condition, and in effect doing so by telling the implementer to look at
the relevant DNS specs.  There is no new normative requirement.

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 8 Apr 2010 08:45:42 +0200

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.

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Scott Lawrence
> Sent: 07 April 2010 20:10
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Last Call:
> draft-lawrence-sipforum-user-agent-config (Session Initiation
> Protocol (SIP) User Agent Configuration) to Informational RFC
>
[JRE] There is an additional consideration: how would the UA know, when setting out to discover its configuration, whether it is safe to skip TLS? This is particular so in the case where the CS domain is not the local network domain, but it is also a consideration when the two domains are the same. It seems a lot safer always to use TLS.

John

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 Apr 2010 04:12:41 -0400

Howdy,
> 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

---

From: Scott Lawrence <[email-masked]>
Date: Thu, 08 Apr 2010 09:37:24 -0400

On Thu, 2010-04-08 at 04:12 -0400, Hadriel Kaplan wrote:
> 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: <sip:devnull.example.org>').  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...

>    of using these procedures alone in order to be compliant with this

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.

>    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)

>    NOT REQUIRED to stop using or delete the data.

This is there to prevent a failure in the configuration system from
causing failures in other functions of the UA.  Suppose that a device is
properly configured for a particular service.  The call routing
functions of that service are implemented separately from the
configuration management parts of that service.  The configured device
approaches the expiration of its configuration change subscription, and
correctly sends a reSUBSCRIBE request to refresh it.  Due to some
transient failure somewhere (routing problems, the CS system itself is
down), that request fails and the configuration change subscription
expires.  The section above is there to make clear that the device does
not have to stop using (or worse, delete) the configuration, thus
propagating an error that affects the configuration refresh system into
the call processing.  Again, I don't see how allowing this causes
interoperability problems.

> These requirements are all completely meaningless, in the sense that
> they do not provide any reliable behavior.

It's true that they allow some degree of variability, but I think that
some flexibility increases the overall robustness of the system, and
that over-specification can be as harmful as under-specification.  If
you think that any of these do cause interop problems, then I'd be happy
to hear about them.

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 8 Apr 2010 10:34:02 -0400

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: [email-masked] [mailto:[email-masked]] 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

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 Apr 2010 14:57:29 -0400

> From: Richard Shockey [mailto:[email-masked]]
> Sent: Thursday, April 08, 2010 10:34 AM
> 
> 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.  

> 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

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 Apr 2010 15:15:37 -0400

> 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?

> 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?

> 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

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 8 Apr 2010 16:12:00 -0400

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.

> ignored since the creation of SIP, especially those that might use (dare I

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.  

> 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

---

From: Scott Lawrence <[email-masked]>
Date: Thu, 08 Apr 2010 16:51:05 -0400

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.  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?

> 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?

> 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.

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 Apr 2010 22:17:50 -0400

> Sent: Thursday, April 08, 2010 4:51 PM
> 
> 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'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?

> allow for updates under the control of the service won't be successful.

Was it a requirement to support, or a requirement to use?

> 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

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 18 Apr 2010 19:23:53 -0700

> allow for updates under the control of the service won't be successful.

+1