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