Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
Dave CROCKER <dhc2@dcrocker.net> Tue, 06 April 2010 00:10 UTC
Return-Path: <dhc2@dcrocker.net>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35BE03A6A1A for <ietf@core3.amsl.com>; Mon, 5 Apr 2010 17:10:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.649
X-Spam-Level:
X-Spam-Status: No, score=-4.649 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U32qxRLobsvy for <ietf@core3.amsl.com>; Mon, 5 Apr 2010 17:10:44 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 37BC93A6A11 for <ietf@ietf.org>; Mon, 5 Apr 2010 17:10:44 -0700 (PDT)
Received: from [192.168.1.14] (adsl-67-127-191-90.dsl.pltn13.pacbell.net [67.127.191.90]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o360AaJK009192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf@ietf.org>; Mon, 5 Apr 2010 17:10:41 -0700
Message-ID: <4BBA7BFD.4070108@dcrocker.net>
Date: Mon, 05 Apr 2010 17:10:37 -0700
From: Dave CROCKER <dhc2@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: IETF Discussion Mailing List <ietf@ietf.org>
Subject: Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
References: <430FC6BDED356B4C8498F634416644A91A79E92FC7@mail>
In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79E92FC7@mail>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV 0.92/10704/Mon Apr 5 16:06:48 2010 on sbh17.songbird.com
X-Virus-Status: Clean
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 05 Apr 2010 17:10:42 -0700 (PDT)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Apr 2010 00:10:46 -0000
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
- Re: Last Call: draft-lawrence-sipforum-user-agent… Hadriel Kaplan
- Re: Last Call: draft-lawrence-sipforum-user-agent… Scott Lawrence
- RE: Last Call: draft-lawrence-sipforum-user-agent… Hadriel Kaplan
- Re: Last Call: draft-lawrence-sipforum-user-agent… Cullen Jennings
- RE: Last Call: draft-lawrence-sipforum-user-agent… Scott Lawrence
- Re: Last Call: draft-lawrence-sipforum-user-agent… todd glassey
- Re: Last Call: draft-lawrence-sipforum-user-agent… Scott Lawrence
- Re: Last Call: draft-lawrence-sipforum-user-agent… todd glassey
- RE: Last Call: draft-lawrence-sipforum-user-agent… Hadriel Kaplan
- RE: Last Call: draft-lawrence-sipforum-user-agent… Hadriel Kaplan
- RE: Last Call: draft-lawrence-sipforum-user-agent… Hadriel Kaplan
- RE: Last Call: draft-lawrence-sipforum-user-agent… Scott Lawrence
- RE: Last Call: draft-lawrence-sipforum-user-agent… Hadriel Kaplan
- RE: Last Call: draft-lawrence-sipforum-user-agent… Scott Lawrence
- RE: Last Call: draft-lawrence-sipforum-user-agent… Hadriel Kaplan
- Re: Last Call: draft-lawrence-sipforum-user-agent… Dave CROCKER
- Re: Last Call: draft-lawrence-sipforum-user-agent… Cullen Jennings
- RE: Last Call: draft-lawrence-sipforum-user-agent… Hadriel Kaplan
- Re: Last Call: draft-lawrence-sipforum-user-agent… Dave CROCKER
- Re: Last Call: draft-lawrence-sipforum-user-agent… Scott Lawrence
- Re: Last Call: draft-lawrence-sipforum-user-agent… Dave CROCKER
- Re: Last Call: draft-lawrence-sipforum-user-agent… Cullen Jennings
- RE: Last Call: draft-lawrence-sipforum-user-agent… Hadriel Kaplan
- Re: Last Call: draft-lawrence-sipforum-user-agent… Dave CROCKER
- Re: Last Call: draft-lawrence-sipforum-user-agent… Henning Schulzrinne
- RE: Last Call: draft-lawrence-sipforum-user-agent… Scott Lawrence
- RE: Last Call: draft-lawrence-sipforum-user-agent… Hadriel Kaplan
- Re: Last Call: draft-lawrence-sipforum-user-agent… Scott Lawrence
- RE: Last Call: draft-lawrence-sipforum-user-agent… Hadriel Kaplan
- RE: Last Call: draft-lawrence-sipforum-user-agent… Scott Lawrence
- Re: Last Call: draft-lawrence-sipforum-user-agent… Bernard Aboba
- Re: Last Call: draft-lawrence-sipforum-user-agent… Dave CROCKER
- Re: Last Call: draft-lawrence-sipforum-user-agent… Dave CROCKER
- Re: Last Call: draft-lawrence-sipforum-user-agent… Spencer Dawkins
- Re: Last Call: draft-lawrence-sipforum-user-agent… Dave CROCKER
- Re: Last Call: draft-lawrence-sipforum-user-agent… Scott Lawrence
- Re: Last Call: draft-lawrence-sipforum-user-agent… Scott Lawrence
- RE: Last Call: draft-lawrence-sipforum-user-agent… Elwell, John
- RE: Last Call: draft-lawrence-sipforum-user-agent… Hadriel Kaplan
- RE: Last Call: draft-lawrence-sipforum-user-agent… Scott Lawrence
- RE: Last Call: draft-lawrence-sipforum-user-agent… Richard Shockey
- RE: Last Call: draft-lawrence-sipforum-user-agent… Hadriel Kaplan
- RE: Last Call: draft-lawrence-sipforum-user-agent… Hadriel Kaplan
- RE: Last Call: draft-lawrence-sipforum-user-agent… Richard Shockey
- RE: Last Call: draft-lawrence-sipforum-user-agent… Scott Lawrence
- RE: Last Call: draft-lawrence-sipforum-user-agent… Hadriel Kaplan
- Re: Last Call: draft-lawrence-sipforum-user-agent… Cullen Jennings
- Re: Last Call: draft-lawrence-sipforum-user-agent… Cullen Jennings