ietf
[Top] [All Lists]

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

2010-04-05 19:11:04
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>