On Mon, 2010-04-05 at 17:10 -0700, Dave CROCKER wrote:
Review of: draft-lawrence-sipforum-user-agent-config
Thanks for taking the time to read this, Dave.
This appears to be an Individual Submission.
For IETF process purposes that is correct. As the document says, it is
the product of a design team working within the SIP Forum Technical
Working Group.
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".
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?
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.
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?
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.
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...
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'm not clear on what detail you think is missing.
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.)
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.
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.
I have no problem with that.
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.
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.
Section 2.2
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.
Section 2.2.1
Local Network Domain" is an essential parameter, but is undefined. The
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.
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.
Given that the draft describes the DHCP(v6) option values where this
comes from, I don't understand why anything more might be needed.
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".
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.
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.
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.
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.
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?
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?
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...
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.
so the choice is up to the implementation - that does not seem to be an
interoperability problem to me.
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.
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.
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.
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.
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?
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.
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.
That's what sections 2.3.1 and 2.3.2 do...
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.
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.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf