From the Introduction:

   Most IP phones and personal computers get their network
   configurations dynamically via a protocol such as DHCP (Dynamic Host
   Configuration Protocol).  These systems typically do not have a
   useful name in the Domain Name System (DNS), and they almost never
   have a long-term, stable DNS name that is appropriate for use in the
   subjectAltName of a certificate, as required by [RFC3261].  However,
   these systems can still act as a Transport Layer Security (TLS)
   [RFC5246] client and form outbound connections to a proxy or
   registrar which authenticates with a server certificate. 

For the sake of (perhaps foolish) consistency, use the same format "Full Name of Protocol (ACRONYM)" for DHCP, DNS and TLS?  And, for completeness and consistency, add an informative reference for DNS (I see Alexey  has already suggested a similar ref for DHCP).

Another very minor editorial comment, also in the spirit of consistency: there are several indented sub-paragraphs (e.g., in sections 3.5.1, 3.5.2, 4.1).  Some are not idnetified while others begin with "Note:".  And, "Implementation Notes:" are not indented.

Comprehensive and well written.

Need to decide on "keep alive" or "keep-alive"

In 4.4.1 
   This approach MUST only be used with connection oriented transports
   such as TCP or SCTP.
This use of "MUST only" creates some ambiguity and may be confusing.
Perhaps better...
   This approach MUST NOT be used with connection-less transports
   such as UDP.
(Similar in 4.4.2.)

In 4.5
   The number of seconds to wait is computed in the following way.  If
   all of the flows to every URI in the outbound proxy set have failed,
   the base-time is set to 30 seconds; otherwise, in the case where at
   least one of the flows has not failed, the base-time is set to 90
   seconds.  The upper-bound wait time (W) is computed by taking two
   raised to the power of the number of consecutive registration
   failures for that URI, and multiplying this by the base time, up to a
   maximum of 1800 seconds.
But all of these timers may be configurable (see the paragraph below the formula) with defaults explained. Better, therefore...
   The number of seconds to wait is computed in the following way.  If
   all of the flows to every URI in the outbound proxy set have failed,
   the base-time is set to a lower value (with a default of 30 seconds);
   otherwise, in the case where at least one of the flows has not 
   failed, the base-time is set to a higher value (with a default of 90
   seconds).  The upper-bound wait time (W) is computed by taking two
   raised to the power of the number of consecutive registration
   failures for that URI, and multiplying this by the base time, up to a
   configurable maximum time (with a default of 1800 seconds).

There are rather a lot of "SHOULD" uses in the document. Some of these have clauses like "Alternatively, the UA..." which is great. I would prefer for some thought to be given to the other cases where deviation from the SHOULD is allowed.

The IANA considerations sections seem a tad verbose. These sections are supposed only to instruct the IANA about what goes in which registries. Discussion of usage of (for example, response codes) should be limited to the main body of the I-D.

This is a solid document.

I have some comments, which are mostly nits:

COMMENT:

1.  Introduction

   There are many environments for SIP [RFC3261] deployments in which
   the User Agent (UA) can form a connection to a Registrar or Proxy but
   in which connections in the reverse direction to the UA are not
   possible.  This can happen for several reasons, but the most likely
   is a NAT or a firewall in between the SIP UA and the proxy.  Many
   such devices will only allow outgoing connections.  This
   specification allows a SIP User Agent behind such a firewall or NAT
   to receive inbound traffic associated with registrations or dialogs
   that it initiates.

   Most IP phones and personal computers get their network
   configurations dynamically via a protocol such as DHCP (Dynamic Host
   Configuration Protocol).  These systems typically do not have a

I think this needs an Informative reference to DHCP.



4.1.  Instance ID Creation

 [...]

      [RFC3840] defines equality rules for callee capabilities
      parameters, and according to that specification, the
      "sip.instance" media feature tag will be compared by case-
      sensitive string comparison.  This means that the URN will be
      encapsulated by angle brackets ("<" and ">") when it is placed
      within the quoted string value of the +sip.instance Contact header
      field parameter.  The case-sensitive matching rules apply only to
      the generic usages defined in the callee capabilities [RFC3841]

Should this be [RFC3840]?

      and the caller preferences [RFC3841] specifications.  When the


4.3.  Sending Non-REGISTER Requests

 [...]

   The UAC performs normal DNS resolution on the next hop URI (as
   described in [RFC3263]) to find a protocol, IP address, and port.
   For protocols that don't use TLS, if the UAC has an existing flow to
   this IP address, and port with the correct protocol, then the UAC
   MUST use the existing connection.  For TLS protocols, there MUST also
   be a match between the host production in the next hop and one of the
   URIs contained in the subjectAltName in the peer certificate.

You should probably mention that you mean uniformResourceIdentifier
subjectAltName value.

   Typically, a UAC using the procedures of this document and sending a
   dialog-forming request will want all subsequent requests in the
   dialog to arrive over the same flow.  If the UAC is using a GRUU
   [I-D.ietf-sip-gruu] that was instantiated using a Contact header
   field value that included an "ob" parameter, the UAC sends the
   request over the flow used for registration and susequent requests

Typo: subsequent

   will arrive over that same flow.  If the UAC is not using such a


9.1.  Subscription to configuration package

   If the outbound proxy set is already configured on Bob's UA, then
   this subsection can be skipped.  Otherwise, if the outbound proxy set
   is learned through the configuration package, Bob's UA sends a
   SUBSCRIBE request for the UA profile configuration package
   [I-D.ietf-sipping-config-framework].  This request is a poll (Expires
   is zero).  After receiving the NOTIFY request, Bob's UA fetches the
   external configuration using HTTPS (not shown) and obtains a
   configuration file which contains the outbound-proxy-set "sip:
   ep1.example.com;lr" and "sip:ep2.example.com;lr.

Missing <"> before the final dot.


10.  Grammar

   This specification defines a new header field "Flow-Timer", new
   Contact header field parameters, reg-id and +sip.instance.  The
   grammar includes the definitions from [RFC3261] and includes the
   definition of uric from [RFC3986].  Flow-Timer is an extension-header

To be pedantic: the rule for "uric" was obsoleted by RFC 3986
(it is mentioned in passing in its Appendix D.2.)
There is also "uric" in RFC 3261.

   from the message-header in the [RFC3261] ABNF.

   The ABNF[RFC5234] is:

    Flow-Timer     = "Flow-Timer" HCOLON 1*DIGIT

    contact-params =/ c-p-reg / c-p-instance

    c-p-reg        = "reg-id" EQUAL 1*DIGIT ; 1 to (2**31 - 1)

Are leading 0 allowed here?

    c-p-instance   =  "+sip.instance" EQUAL
                      DQUOTE "<" instance-val ">" DQUOTE

    instance-val   = *uric ; defined in RFC 3986

I just want to double check this is intentional: you allow for empty value?

   The value of the reg-id MUST NOT be 0 and MUST be less than 2**31.

11.7.  Media Feature Tag

 [...]

    Values appropriate for use with this feature tag:  String.

According to RFC 2506, this should be "String (equality relationship)".