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: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] 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
On Thu, 2010-04-08 at 04:12 -0400, Hadriel Kaplan wrote:
Howdy,
I said I would shut up, but I missed one question from Cullen, which was:
This conversation constantly confuses the issue of must implement vs
must
deploy. Which one are you objecting to here.
Answer: I am objecting to there 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...
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 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.
The UA MAY at any time return to any earlier step in the
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)
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.
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.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf