[Ballot discuss]
2.4.1.  Configuration Data Request Authentication

  If the CS requires HTTP authentication of the configuration data
  request, the HTTP 'username' parameter used MUST be the same value as
  the sfua-user value provided in the configuration data request
  parameters. The UA MUST support using either Basic or Digest
  authentication as specified by RFC 2617 [RFC2617].

The last sentence: this doesn't guaranty interoperability. I think UAs
MUST support both, not either.

[Ballot comment]
#1) Sec 1: You might want to answer the question with .  This document provides the answer.

#2) Sec 1.1: Seems like you're dancing around not using 2119 language:

  OLD:

  A User Agent implementation compliant to this specification
  MAY also implement additional mechanisms that may be required in
  particular environments, or for use when the services specified
  here are not available.

  NEW:

  A User Agent implementation compliant to this specification
  MAY also implement additional mechanisms necessary for particular
  environments, or for use when the services specified here are not
  available.

#3) Sec 2.4.2: Is the list of failures inclusive or are there other ways it can fail?

#4) Sec 3.1: r/should/SHOULD

#5) Sec 5: r/Url/URL

#6) Sec 5: r/to provide for including that/to provide that

[Ballot discuss]
[Updated to based on -02 version.]

#1) Addressed in -02.

#2) Addressed in -02.

#3) Addressed in -02.

#4) Addressed in -02.

#5) Addressed (no change required).

#6) Addressed (no change required).

#7) Addressed in -02.

#8) Addressed in -02.

#10) Addressed (no change required).

#11) Addressed (no change required).

#12) Addressed in -02.

#13) Addressed in -02.

#14) Addressed.

[Ballot comment]
#1) Sec 1: You might want to answer the question with .  This document provides the answer.

#2) Sec 1.1: Seems like you're dancing around not using 2119 language:

  OLD:

  A User Agent implementation compliant to this specification
  MAY also implement additional mechanisms that may be required in
  particular environments, or for use when the services specified
  here are not available.

  NEW:

  A User Agent implementation compliant to this specification
  MAY also implement additional mechanisms necessary for particular
  environments, or for use when the services specified here are not
  available.

#3) Sec 2.4.2: Is the list of failures inclusive or are there other ways it can fail?

#4) Sec 3.1: r/should/SHOULD

#5) Sec 5: r/Url/URL

#6) Sec 5: r/to provide for including that/to provide that

[Ballot discuss]
[Updated to based on -02 version.]

#1) Addressed in -02.

#2) Addressed in -02.

#3) Addressed in -02.

#4) Addressed in -02.

#5) Addressed (no change required).

#6) Addressed (no change required).

#7) Addressed in -02.

#8) Addressed in -02.

#10) Addressed (no change required).

#11) Addressed (no change required).

#12) Addressed in -02.

#13) Addressed in -02.

#14) This is a place-holder DISCUSS.  Awaiting response to the SECDIR review provided by Jeffrey Hutzelman on 2010-05-03.

[Ballot discuss]
This Discuss position was updated on 5-17 after an e-mail discussion
among the authors, Ted Lemon (dhc WG co-chair) and myself.  Thread
begins here:
https://www.ietf.org/mailman/private/iesg/2010-May/071964.html and
and continues here:
https://www.ietf.org/mailman/private/iesg/2010-May/071932.html  This
Discuss is based on the -01 rev of the doc.

Ideally, discovery of a SIP UA configuration service would use newly
defined DHCPv4 and DHCPv6 options to pass the Local Network Domain to
the SIP UA.  Reuse/overloading of existing options incurs other costs
and unexpected results.

draft-lawrence-sipforum-user-agent-config specifies the use of
contents of the DHCPv4 "Domain Name" option (code 15) and the contents
of the DHCPv6 "SIP Servers Domain Name List" option (code 21) as
candidates for the UA's "Local Network Domain".  Overloading these
options may conflict with other uses of the options or with the use of
other options (e.g., DHCPv4 "Domain Search" option [code 119]).  Also,
the options carry data in different formats: the "Domain Name" option
a name like "example.com", while the "SIP Servers Domain Name List"
option carries names like "sip1.example.com".

If existing DHCP options are overloaded to carry candidates for the
"Local Netwrok Domain", the options should be consistent between
DCHPv4 and DHCPv6 so a single DNS NAPTR record can serve both options;
e.g., "Domain Search" option and "Domain Search List" option, or the
DHCPv4 and DHCPv6 versions of the "SIP Servers Domain Name List"

[Ballot discuss]
I'm not sure the use of DHCPv4 and DHCPv6 options is consistent and/or correct.  DHCPv4 option 120, "SIP Servers DHCP Option" and DHCPv6 option 21, "SIP Servers Domain Name List" both return a list of FQDNs for SIP servers to be used by the client host.  This doc specifies the use of the DHCPv4 option 15, "Domain Name" to obtain the domain name over IPv4 and DHCPv6 option 21 over IPv6.

I don't think the use of DHCPv6 option 21 is correct, as I think it will deliver the FQDN for SIP servers, rather than the SIP domain in which the host is attached.

[Ballot discuss]
Thank you for bring this work from the SIP Forum and undergoing the pain necessary to get a tag allocated.

I noticed two small issues related to RFC2119 langauge:

Section 2.3.2

  3.  Any parameter not defined by the specification is allowed, but
      MAY be ignored by any Configuration Service that does not
      recognize it.

I suspect that if the CS doesn't understand the parameter is doesn't
have the luxury of "MAY". In fact, since you don't describe any other
procedures for handling unknown parameters, I think this is a "MUST".

---

Section 2.6

As Sean points out, "NOT REQUIRED" is not defined. I suggest you turn
this into a positive statement...
OLD
  There is no
  assurance that such configuration data is still useful, but the UA is
  NOT REQUIRED to stop using or delete the data.
NEW
  There is no
  assurance that such configuration data is still useful, and the UA
  MAY choose to retain the data without deletion and to continue to use
  it.

[Ballot comment]
#1) Sec 1: You might want to answer the question with .  This document provides the answer.

#2) Sec 1.1: Seems like you're dancing around not using 2119 language:

  OLD:

  A User Agent implementation compliant to this specification
  MAY also implement additional mechanisms that may be required in
  particular environments, or for use when the services specified
  here are not available.

  NEW:

  A User Agent implementation compliant to this specification
  MAY also implement additional mechanisms necessary for particular
  environments, or for use when the services specified here are not
  available.

#3) Sec 2.4.2: Is the list of failures inclusive or are there other ways it can fail?

#4) Sec 3.1: r/should/SHOULD

#5) Sec 5: r/Url/URL

#6) Sec 5: r/to provide for including that/to provide that

[Ballot discuss]
[Updated to fix numbering and some bad spelling.  Removed #9, but retained the original numbering scheme.]

#1) Normative references for HTTPS (i.e., RFCs 2817 & 2818) are needed. 

Gonzalo: Note RFC 2818 is Informational but is included in the DOWNREF registry.

#2) Sec 2.4.1: Need normative reference to TLS: RFC 5246

#3) Sec 2.4.1: Is it intentional that you're point to RFC 3546 and not RFC 5246?  3546 was obsoleted by 4366 which in turn was obsoleted by 5246.

#4) Sec 2.4.1: Why is the requirement for the CS to validate client certificates a SHOULD as opposed to MUST?  If the client provides one the server better check it.  More bluntly:

r/The CS SHOULD validate the UA client's certificate, if one is provided./The CS MUST validate the UA client's certificate, if one is provided.

#5) Sec 2.4.2: Text is need to address what happens when a TLS handshake fails and there is only one server in the list and it is removed as a result an error?

#6) Sec 2.5.2: Is HTTPS required when using change polling?  I think the text should be explicit about it being required or not.

#7) Sec 2.6: NOT REQUIRED is not defined by RFC 2119.

#8) Sec 2.6.1: r/HTTP GET/HTTPS GET  It was HTTPS GET in Sec 2.4.

#10) Sec 3.1.3: Is there some kind of recommendation that should included in username about character set support?

#11) Sec 3.1.4: RFC2317 defines two schemes: Basic and Digest Access.  Please specify which is required (I assume it's digest because SIP doesn't allow basic according to RFC 3261?).

#12) Sec 5: The XMPP WG come up with the following (thank you Peter and Simon) that I think should be added here:

Implementations of TLS typically support multiple versions of the
Transport Layer Security protocol as well as the older Secure Sockets
Layer (SSL) protocol.  Because of known security vulnerabilities,
SIP UAs, SIP Service Provider, and the Configuration Service Host MUST
NOT request, offer, or use SSL 2.0. See Appendix E.2 of [TLS] for
further details.

#13) I also support Peter's DISCUSS wrt the client checking the server's certificate.

#14) This is a place-holder DISCUSS.  Awaiting response to the SECDIR review provided by Jeffrey Hutzelman on 2010-05-03.

[Ballot comment]
> 2.2.1.  The Local Network Domain
  >
  >    The UA MUST attempt to use the Local Network Domain name (see
  >    Section 2.1.2, "Network Layer Provisioning") as the Configuration
  >    Service Domain.  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.
  >
  >    If the DHCP service does not provide any local domain name value,
  >    the UA SHOULD use the manual mechanism defined in Section 2.2.2,
  >    "Manual Domain Name Entry".
  >
  Please add something here about what to do if the SIP UA is connected
  to more than one network and gets responses from more than one DHCP
  server, presumeably one associated with each interface.

[Ballot discuss]
2.3.  Constructing the Configuration Request URL

  Using the Configuration Service Domain name obtained in Section 2.2,
  "Obtaining the Configuration Service Domain", the UA MUST construct
  an HTTPS URL with which to request configuration.

This needs a Normative reference to RFC 2818 (HTTP over TLS).

2.3.3.  Configuration Request URI Example

  https://p1.example.net/cfg
      ?sfua-anchor=urn:uuid:00000000-0000-1000-8000-001122334455
      &sfua-vendor=examplecorp.com
      &sfua-model=HypoComm
      &sfua-revision=2.1
  https://p2.example.net/cfg
      ?sfua-anchor=urn:uuid:00000000-0000-1000-8000-001122334455
      &sfua-vendor=examplecorp.com
      &sfua-model=HypoComm
      &sfua-revision=2.1

sfua-anchor is not defined in this document. Did you mean sfua-id?

2.4.1.  Configuration Data Request Authentication

  If the UA is capable of doing so, it SHOULD validate the server
  certificate provided by the CS.

I think this needs a pointer to the document that talks about server
identity validation. You probably want to point to RFC 2818 here.

  If the CS requires HTTP authentication of the configuration data
  request, the HTTP 'username' parameter used MUST be the same value as
  the sfua-user value provided in the configuration data request
  parameters.

This should be clear about which HTTP authentication method should be used. (RFC 2617 specifies 2: Basic and Digest.)

2.4.2.  Configuration Data Request Failure

  o  If the request returns a permanent HTTP failure response, the UA
      MUST remove the failed URL from the list of alternatives for this
      Configuration Service Domain.

Please define (or list) which failure responses are considered "permanent".

2.5.  Configuration Changes

  o  Indicate that the UA is to subscribe for change notifications.
      This is indicated by the CS including a Link header in the
      response with the link relation 'monitor' and SIP URI.  This
      choice is specified in Section 2.5.1 Configuration Change
      Subscriptions.

This needs a Normative reference to draft-nottingham-http-link-header
(just about to be approved for publication).

5.  Security Considerations

  The connection to the Configuration Service is made over TLS.  As the
  TLS server, the CS always provides a server certificate during the
  TLS handshake; if possible, the UA should validate that certificate
  and confirm that it contains as a subject the Configuration Service
  Domain Name or at least the host name from the Configuration Service
  Base Url.

I don't think this is detailed enough to be implementable. Please either specify the exact procedure, or reference RFC 2818 here.

[Ballot comment]
#1) Sec 1: You might want to answer the question with .  This document provides the answer.

#2) Sec 1.1: Seems like you're dancing around not using 2119 language:

  OLD:

  A User Agent implementation compliant to this specification
  MAY also implement additional mechanisms that may be required in
  particular environments, or for use when the services specified
  here are not available.

  NEW:

  A User Agent implementation compliant to this specification
  MAY also implement additional mechanisms necessary for particular
  environments, or for use when the services specified here are not
  available.

#3) Sec 2.4.2: Is the list of failures inclusive or are there other ways it can fail?

#4) Sec 3.1: r/should/SHOULD

#5) Sec 5: r/Url/URL

#6) Sec 5: r/to provide for including that/to provide that

[Ballot discuss]
[Updated to fix numbering.  Removed #9, but retained the original numbering scheme.]

#1) Normative references for HTTPS (i.e., RFCs 2817 & 2818) are needed. 

Gonzolo: Note RFC 2818 is Informational but is included in the DOWNREF registry.

#2) Sec 2.4.1: Need normative reference to TLS: RFC 5246

#3) Sec 2.4.1: Is it intentional that you're point to RFC 3546 and not RFC 5246?  3546 was obsoleted by 4366 which in turn was obsoleted by 5246.

#4) Sec 2.4.1: Why is the requirement for the CS to validate client certificates a SHOULD as opposed to MUST?  If the client provides one the server better check it.  More bluntly:

r/The CS SHOULD validate the UA client's certificate, if one is provided./The CS MUST validate the UA client's certificate, if one is provided.

#5) Sec 2.4.2: Text is need to address what happens when a TLS handshake fails and there is only one server in the list and it is removed as a result an error?

#6) Sec 2.5.2: Is HTTPS required when using change polling?  I think the text should be explicit about it being required or not.

#7) Sec 2.6: NOT REQUIRED is not defined by RFC 2119.

#8) Sec 2.6.1: r/HTTP GET/HTTPS GET  It was HTTPS GET in Sec 2.4.

#10) Sec 3.1.3: Is there some kind of recommendation that should included in username about character set support?

#11) Sec 3.1.4: RFC2317 defines two schemes: Basic and Digest Access.  Please specify which is required (I assume it's digest because SIP doesn't allow basic according to RFC 3261?).

#12) Sec 5: The XMPP WG come up with the following (thank you Peter and Simon) that I think should be added here:

Implementations of TLS typically support multiple versions of the
Transport Layer Security protocol as well as the older Secure Sockets
Layer (SSL) protocol.  Because of known security vulnerabilities,
SIP UAs, SIP Service Provider, and the Configuration Service Host MUST
NOT request, offer, or use SSL 2.0. See Appendix E.2 of [TLS] for
further details.

#13) I also support Peter's DISCUSS wrt the client checking the server's certificate.

#14) This is a place-holder DISCUSS.  Awaiting response to the SECDIR review provided by Jeffrey Hutzelman on 2010-05-03.

[Ballot comment]
#1) Sec 1: You might want to answer the question with .  This document provides the answer.

#2) Sec 1.1: Seems like you're dancing around not using 2119 language:

  OLD:

  A User Agent implementation compliant to this specification
  MAY also implement additional mechanisms that may be required in
  particular environments, or for use when the services specified
  here are not available.

  NEW:

  A User Agent implementation compliant to this specification
  MAY also implement additional mechanisms necessary for particular
  environments, or for use when the services specified here are not
  available.

#3) Sec 2.4.2: Is the list of failures inclusive or are there other ways it can fail?

#4) Sec 3.1: r/should/SHOULD

#5) Sec 5: r/Url/URL

#6) Sec 5: r/to provide for including that/to provide that

[Ballot discuss]
[Updated to fix numbering]

#1) Normative references for HTTPS (i.e., RFCs 2817 & 2818) are needed. 

Gonzolo: Note RFC 2818 is Informational but is included in the DOWNREF registry.

#2) Sec 2.4.1: Need normative reference to TLS: RFC 5246

#3) Sec 2.4.1: Is it intentional that you're point to RFC 3546 and not RFC 5246?  3546 was obsoleted by 4366 which in turn was obsoleted by 5246.

#4) Sec 2.4.1: Why is the requirement for the CS to validate client certificates a SHOULD as opposed to MUST?  If the client provides one the server better check it.  More bluntly:

r/The CS SHOULD validate the UA client's certificate, if one is provided./The CS MUST validate the UA client's certificate, if one is provided.

#5) Sec 2.4.2: Text is need to address what happens when a TLS handshake fails and there is only one server in the list and it is removed as a result an error?

#6) Sec 2.5.2: Is HTTPS required when using change polling?  I think the text should be explicit about it being required or not.

#7) Sec 2.6: NOT REQUIRED is not defined by RFC 2119.

#8) Sec 2.6.1: r/HTTP GET/HTTPS GET  It was HTTPS GET in Sec 2.4.

#9) Sec 3: This headed for INFORMATIONAL so it's unnecessary to include the 2nd sentence in the 1st paragraph:

As such, the contents of this section are non-normative.

#10) Sec 3.1.3: Is there some kind of recommendation that should included in username about character set support?

#11) Sec 3.1.4: RFC2317 defines two schemes: Basic and Digest Access.  Please specify which is required (I assume it's digest because SIP doesn't allow basic according to RFC 3261?).

#12) Sec 5: The XMPP WG come up with the following (thank you Peter and Simon) that I think should be added here:

Implementations of TLS typically support multiple versions of the
Transport Layer Security protocol as well as the older Secure Sockets
Layer (SSL) protocol.  Because of known security vulnerabilities,
SIP UAs, SIP Service Provider, and the Configuration Service Host MUST
NOT request, offer, or use SSL 2.0. See Appendix E.2 of [TLS] for
further details.

#13) I also support Peter's DISCUSS wrt the client checking the server's certificate.

#14) This is a place-holder DISCUSS.  Awaiting response to the SECDIR review provided by Jeffrey Hutzelman on 2010-05-03.

[Ballot comment]
#1) Sec 1: You might want to answer the question with .  This document provides the answer.

#2) Sec 1.1: Seems like you're dancing around not using 2119 language:

  OLD:

  A User Agent implementation compliant to this specification
  MAY also implement additional mechanisms that may be required in
  particular environments, or for use when the services specified
  here are not available.

  NEW:

  A User Agent implementation compliant to this specification
  MAY also implement additional mechanisms necessary for particular
  environments, or for use when the services specified here are not
  available.

#3) Sec 2.4.2: Is the list of failures inclusive or are there other ways it can fail?

#4) Sec 3.1: r/should/SHOULD

#5) Sec 5: r/Url/URL

#6) Sec 5: r/to provide for including that/to provide that

[Ballot discuss]
#1) Normative references for HTTPS (i.e., RFCs 2817 & 2818) are needed. 

Gonzolo: Note RFC 2818 is Informational but is included in the DOWNREF registry.

#2) Sec 2.4.1: Need normative reference to TLS: RFC 5246

#3) Sec 2.4.1: Is it intentional that you're point to RFC 3546 and not RFC 5246?  3546 was obsoleted by 4366 which in turn was obsoleted by 5246.

#4) Sec 2.4.1: Why is the requirement for the CS to validate client certificates a SHOULD as opposed to MUST?  If the client provides one the server better check it.  More bluntly:

r/The CS SHOULD validate the UA client's certificate, if one is provided./The CS MUST validate the UA client's certificate, if one is provided.

#5) Sec 2.4.2: Text is need to address what happens when a TLS handshake fails and there is only one server in the list and it is removed as a result an error?

#6) Sec 2.5.2: Is HTTPS required when using change polling?  I think the text should be explicit about it being required or not.

#7) Sec 2.6: NOT REQUIRED is not defined by RFC 2119.

#8) Sec 2.6.1: r/HTTP GET/HTTPS GET  It was HTTPS GET in Sec 2.4.

#9) Sec 3: This headed for INFORMATIONAL so it's unnecessary to include the 2nd sentence in the 1st paragraph:

As such, the contents of this section are non-normative.

#10) Sec 3.1.3: Is there some kind of recommendation that should included in username about character set support?

#11) Sec 3.1.4: RFC2317 defines two schemes: Basic and Digest Access.  Please specify which is required (I assume it's digest because SIP doesn't allow basic according to RFC 3261?).

#12) Sec 5: The XMPP WG come up with the following (thank you Peter and Simon) that I think should be added here:

Implementations of TLS typically support multiple versions of the
Transport Layer Security protocol as well as the older Secure Sockets
Layer (SSL) protocol.  Because of known security vulnerabilities,
SIP UAs, SIP Service Provider, and the Configuration Service Host MUST
NOT request, offer, or use SSL 2.0. See Appendix E.2 of [TLS] for
further details.

#12) I also support Peter's DISCUSS wrt the client checking the server's certificate.

#13) This is a place-holder DISCUSS.  Awaiting response to the SECDIR review provided by Jeffrey Hutzelman on 2010-05-03.

[Ballot discuss]
This document is a pleasure to read. However, this statement seems a bit weak:

  If the UA is capable of doing so, it SHOULD validate the server
  certificate provided by the CS.

If a UA is capable of validating server certificates, why would the spec not state that the UA MUST do so? Under what conditions would a UA legitimately not be capable of validating server certificates? And what are the rules for certificate validation? (Given that the Configuration Request URL scheme is HTTPS, a reference to Section 3.1 of RFC 2818 seems to be in order.)

[Ballot discuss]
2.3.  Constructing the Configuration Request URL

  Using the Configuration Service Domain name obtained in Section 2.2,
  "Obtaining the Configuration Service Domain", the UA MUST construct
  an HTTPS URL with which to request configuration.

This needs a Normative reference to RFC 2818 (HTTP over TLS).

2.3.2.1.  Configuration Request Parameters

  sfua-id

      The URN identifying the User Agent, constructed as specified in

This needs a normative reference to the URN spec.

      section 4.1 of [RFC5626] "Managing Client-Initiated Connections in
      the Session Initiation Protocol (SIP)".

2.3.3.  Configuration Request URI Example

  https://p1.example.net/cfg
      ?sfua-anchor=urn:uuid:00000000-0000-1000-8000-001122334455
      &sfua-vendor=examplecorp.com
      &sfua-model=HypoComm
      &sfua-revision=2.1
  https://p2.example.net/cfg
      ?sfua-anchor=urn:uuid:00000000-0000-1000-8000-001122334455
      &sfua-vendor=examplecorp.com
      &sfua-model=HypoComm
      &sfua-revision=2.1

sfua-anchor is not defined in this document. Did you mean sfua-id?

2.4.1.  Configuration Data Request Authentication

  If the UA is capable of doing so, it SHOULD validate the server
  certificate provided by the CS.

I think this needs a pointer to the document that talks about server
identity validation. You probably want to point to RFC 2818 here.

  If the CS requires HTTP authentication of the configuration data
  request, the HTTP 'username' parameter used MUST be the same value as
  the sfua-user value provided in the configuration data request
  parameters.

This should be clear about which HTTP authentication method should be used. (RFC 2617 specifies 2: Basic and Digest.)

2.4.2.  Configuration Data Request Failure

  o  If the request returns a permanent HTTP failure response, the UA
      MUST remove the failed URL from the list of alternatives for this
      Configuration Service Domain.

Please define (or list) which failure responses are considered "permanent".

2.5.  Configuration Changes

  o  Indicate that the UA is to subscribe for change notifications.
      This is indicated by the CS including a Link header in the
      response with the link relation 'monitor' and SIP URI.  This
      choice is specified in Section 2.5.1 Configuration Change
      Subscriptions.

This needs a Normative reference to draft-nottingham-http-link-header
(currently in IESG review).

5.  Security Considerations

  The connection to the Configuration Service is made over TLS.  As the
  TLS server, the CS always provides a server certificate during the
  TLS handshake; if possible, the UA should validate that certificate
  and confirm that it contains as a subject the Configuration Service
  Domain Name or at least the host name from the Configuration Service
  Base Url.

I don't think this is detailed enough to be implementable. Please either specify the exact procedure, or reference RFC 2818 here.

[Ballot discuss]
2.3.  Constructing the Configuration Request URL

  Using the Configuration Service Domain name obtained in Section 2.2,
  "Obtaining the Configuration Service Domain", the UA MUST construct
  an HTTPS URL with which to request configuration.

This needs a Normative reference to RFC 2818 (HTTP over TLS).

2.3.2.1.  Configuration Request Parameters

  sfua-id

      The URN identifying the User Agent, constructed as specified in

This needs a normative reference to the URN spec.

      section 4.1 of [RFC5626] "Managing Client-Initiated Connections in
      the Session Initiation Protocol (SIP)".

2.3.3.  Configuration Request URI Example

  https://p1.example.net/cfg
      ?sfua-anchor=urn:uuid:00000000-0000-1000-8000-001122334455
      &sfua-vendor=examplecorp.com
      &sfua-model=HypoComm
      &sfua-revision=2.1
  https://p2.example.net/cfg
      ?sfua-anchor=urn:uuid:00000000-0000-1000-8000-001122334455
      &sfua-vendor=examplecorp.com
      &sfua-model=HypoComm
      &sfua-revision=2.1

sfua-anchor is not defined in this document. Did you mean sfua-id?

2.4.1.  Configuration Data Request Authentication

  If the UA is capable of doing so, it SHOULD validate the server
  certificate provided by the CS.

I think this needs a pointer to the document that talks about server
identity validation. You probably want to point to RFC 2818 here.

  If the CS requires HTTP authentication of the configuration data
  request, the HTTP 'username' parameter used MUST be the same value as
  the sfua-user value provided in the configuration data request
  parameters.

This should be clear about which HTTP authentication method should be used. (RFC 2617 specifies 2: Basic and Digest.)

2.4.2.  Configuration Data Request Failure

  o  If the request returns a permanent HTTP failure response, the UA
      MUST remove the failed URL from the list of alternatives for this
      Configuration Service Domain.

Please define (or list) which failure responses are considered "permanent".

2.5.  Configuration Changes

  o  Indicate that the UA is to subscribe for change notifications.
      This is indicated by the CS including a Link header in the
      response with the link relation 'monitor' and SIP URI.  This
      choice is specified in Section 2.5.1 Configuration Change
      Subscriptions.

This needs a Normative reference to draft-nottingham-http-link-header
(currently in IESG review).

IANA comments:

Upon approval of this document, IANA will make the following assignments
in the "S-NAPTR Application Service Tags" registry at
http://www.iana.org/assignments/s-naptr-parameters/s-naptr-parameters.xhtml

Tag Reference
-------- -------------------------------------------
SFUA.CFG [RFC-lawrence-sipforum-user-agent-config-01]