Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC

[Scott Lawrence <[e-mail]>]

On Mon, 2010-04-05 at 17:10 -0700, Dave CROCKER wrote: 
> Review of:  draft-lawrence-sipforum-user-agent-config

Thanks for taking the time to read this, Dave.

> This appears to be an Individual Submission.

For IETF process purposes that is correct.  As the document says, it is
the product of a design team working within the SIP Forum Technical
Working Group.  

> 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?

> 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.

The draft deliberately does not specify anything about the Configuration
Service (CS) other than the protocol interface it supports.   Any other
characteristic of the CS is beyond the scope of the document, and
anything that supports that interface can act as a CS.  Do you think
that's a problem?

> 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.  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...

> 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 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.

> 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.

I have no problem with that.

> 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.

> 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.

> 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.

> 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.

> 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.

> 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.

Do you believe that the allowing this explicitly does any harm to
interoperability?

> 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...
        
> 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 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.

> 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: 

        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.

> 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...

> 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.

This point is the subject of a significant ongoing thread so I won't
repeat it here... suffice to say that the minimal configuration data
listed in section 3 is not what needs to be changed frequently or
promptly.