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.
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On
Behalf Of Scott Lawrence
Sent: 07 April 2010 20:10
To: dcrocker(_at_)bbiw(_dot_)net
Cc: ietf(_at_)ietf(_dot_)org
Subject: Re: Last Call:
draft-lawrence-sipforum-user-agent-config (Session Initiation
Protocol (SIP) User Agent Configuration) to Informational RFC
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...
On Tue, 2010-04-06 at 20:56 -0700, Dave CROCKER wrote:
On 4/6/2010 1:39 PM, Scott Lawrence wrote:
On Mon, 2010-04-05 at 17:10 -0700, Dave CROCKER wrote:
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?
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.
I guess I still don't understand what you think that the problem is
here.
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.
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.)
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.
[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
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.
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.
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).
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.
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.
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.
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.
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.
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).
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
interoperability?
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.
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.
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...
"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.
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.
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 choice is up to the implementation, then I do not
know what normative
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.
_______________________________________________
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