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

[Scott Lawrence <[e-mail]>]

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.