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.
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.)
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...
As I suggested in the review, at the least the document should have some
discourse about its security model, to justify security-related mandatory
behaviors. (see below)
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'm not a security geek but have had the pleasure of interacting with some.
I've been particularly thrilled to experience the demands of such things as
documenting a threat model. But still don't understand the security arena
(filled with sand, of course) to describe the requirements. Perhaps a security
area personage can assist here. And that assistance might well be to dismiss
what I'm suggesting -- but I doubt it.
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.
The CS is the remote query service.
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.
The desire to do a product specification is understandable. However that's not
what the IETF usually standardizes. For all of the many user-level
specifications done in the IETF, precious few dictate DHCP details.
In particular, as I said, repeating detail present in other standards
specifications is a good way to create divergent specifications. Simply declare
the use of standards and say no more.
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.
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.
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.
I don't understand how capitalization or its lack has semantic impact in an IETF
specification. It's also a bit risky to focus on DHCP(v6) since there is so
little use of it.
Is this effort intended to rely on v6 deployment before it is useful? (Yes, I
know the answer is no; I'm trying to highlight why it is better to say something
more generic about the domain name you want and have DHCP [v4 and/or v6] only as
exemplars.)
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.
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.
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.
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.
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.
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.
Well, that's clearly the intent of 2.2. My point was that I believe it does not
provide the right detail to satisfy that intent.
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:
Hmmm. Two comments:
1. Yeah, I missed that. Sorry.
2. I am not sure I know what "for which the UA has a value" means.
My guess is that the specify really ought to say "The UA SHOULD request all
parameters that it can use."
That said, I'm not sure I understand why even that statement is needed.
Mandating what is subscribed intrudes on operational choice, and will be the
wrong policy for some environments.
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.
So your clarifying text is actually redundant? Or it's merely meant to remind
the reader that this parameter is always present. While this could be a useful
bit of pedagogy for the reader, it's not a normative point.
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...
Oh my. Right. The word "Example" in the subsection title should have been a
clue for me...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf