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.
> >> 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf