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

["Elwell, John" <[e-mail]>]

Just catching up on this discussion, after a period of absence. As chair of the SIP Forum Task Group that carried out this work, I concur with the summary below from Scott and also his various earlier postings answering questions raised on this list - thanks Scott.

A further comment below.


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Scott Lawrence
> Sent: 07 April 2010 20:10
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: Last Call:
> draft-lawrence-sipforum-user-agent-config (Session Initiation
> Protocol (SIP) User Agent Configuration) to Informational RFC
>
> 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.
[JRE] There is an additional consideration: how would the UA know, when setting out to discover its configuration, whether it is safe to skip TLS? This is particular so in the case where the CS domain is not the local network domain, but it is also a consideration when the two domains are the same. It seems a lot safer always to use TLS.

John


>
> > >> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf
>