Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)
draft-ietf-sip-outbound-20

[Ballot comment]
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.

[Ballot discuss]
Section 4.4.1:

  If a pong is not received within 10 seconds after sending a ping (or
  immediately after processing any incoming message being received when
  the pong was expected), then the client MUST treat the flow as
  failed.  Clients MUST support this CRLF keep alive.

I have some issues with the parenthesis "(or immediately after processing any incoming message being received when the pong was expected)".

Although in some cases this should work fine, it seems that there are cases when the timing is such that the proxy's pong answer can arrive some time after an incoming message. If the proxy sends an UA bound message at the same time as the UA send its PING. Then the proxy's message arrive after RTT/2 to the UA. At the same time the PING arrives at the proxy. If the proxy answers in no time, the PONG still arrives RTT/2 after the incoming message. Worst case seems to be RTT + proxy processing delay before the PONG arrives after an incoming message.

To me this seems this is a failure mode, that causes an unnecessary flow recovery. It seems simpler to just skip the exception around incoming messages, are there a reason why it exist?

[Ballot comment]
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.

[Ballot comment]
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)".

[Ballot comment]
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.

IANA comments:

Action #1:

Upon approval of this document, IANA will make the following
assignment in the "Header Fields" registry at
http://www.iana.org/assignments/sip-parameters

Header Name compact Reference
----------------- ------- ---------
Flow-Timer [RFC-sip-outbound-17]


Action #2:

Upon approval of this document, IANA will make the following
assignment in the "Header Field Parameters and Parameter Values"
registry at
http://www.iana.org/assignments/sip-parameters

Header Field Parameter Name Values Reference
---------------------- --------------------- ---------- ---------
Contact reg-id No [RFC-sip-outbound-17]


Action #3:

Upon approval of this document, IANA will make the following
assignment in the "SIP/SIPS URI Parameters" registry at
http://www.iana.org/assignments/sip-parameters

Parameter Name Predefined Values Reference
-------------- ----------------- ---------
ob No [RFCXXXX]


Action #4:

Upon approval of this document, IANA will make the following
assignment in the "Option Tags" registry at
http://www.iana.org/assignments/sip-parameters

Name Description Reference
----------- | ------------------------------------------ | ---------
outbound | This option-tag is used to identify UAs and Registrars |
[RFC-sip-outbound-17]
| which support extensions for Client Initiated Connections. A UA
| places this option in a Supported header to communicate its
| support for this extension. A Registrar places this option-tag in
| a Require header to indicate to the registering User Agent that
| the Registrar used registrations using the binding rules defined
| in this extension.


Action #5:

Upon approval of this document, IANA will make the following
assignments in the "Response Codes" registry at
http://www.iana.org/assignments/sip-parameters

Response Code Reference
------------------------------------------ ---------
430 Flow Failed [RFC-sip-outbound-17]
439 First Hop Lacks Outbound Support [RFC-sip-outbound-17]


Action #6

Upon approval of this document, IANA will make the following
assignment in the "iso.org.dod.internet.features.sip-tree (1.3.6.1.8.4)" registry at
http://www.iana.org/assignments/media-feature-tags


Decimal Name Description Reference
------- | --------------- | ---------------------------------------------- | ------
---
TBD sip.instance | This feature tag contains a string containing a |
[RFC-sip-outbound-17]
| | URN that indicates a unique identifier
| | associated with the UA instance registering the Contact.
| | Values appropriate for use with this feature tag: String.
| | The feature tag is intended primarily for use in the following
| | applications, protocols, services, or negotiation mechanisms: This
| | feature tag is most useful in a communications application, for
| | describing the capabilities of a device, such as a phone or PDA.

  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

SIP chair Dean Willis is serving as the Document Shepherd for this
document.  He has personally reviewed this document and believes it is
as ready for forwarding to the IESG for publication as it is ever
going to get.


  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

The document has been intensively reviewed within the working
group. It was formally reviewed by John Elwell:

http://www.ietf.org/mail-archive/web/sip/current/msg22870.html.

which resulted in several small changes.


  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

The shepherd has no such concerns.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

The shepherd has no specific concerns with this document.

  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

Working group consensus is quite strong for this document. It was
considered "high profile" during the entire cycle, and has been very
thoroughly discussed. Numerous design changes were made in the process
in order to accomodate various points of view.


  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarise the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

The shepherd is unaware of any extreme discontent with this version of
the draft. A previous version that did not require two "outbound
proxy" entries was disparaged on-list, but the document was revised to
accomodate this issue.



  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type and URI type reviews?

The document appears to satisfy the various checklist nits.

  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

References are appropriately divided. There is one reference to a
draft that has been revised, but this does not impact the document.

  (1.i)  Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process has Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?

This document specifies seven IANA actions that appear to be valid and
complete. It defines no new registry or expert review process.

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

The document shepherd verified the ABNF using Bill Fenner's checker.



  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up?  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:




Technical Summary

This document defines a n extension to the Session Initiation Protocol
(SIP) that provides for persistent and reusable connections between
SIP User Agents and SIP Proxy Servers. In particular, this allows
proxy servers to initiate TCP connections or to send asynchronous UDP
datagrams to User Agents in order to deliver requests.  However, in a
large number of real deployments, many practical considerations, such
as the existence of firewalls and Network Address Translators (NATs)
or the use of TLS with server-provided certificates, prevent servers
from connecting to User Agents in this way.  This specification
defines behaviors for User Agents, registrars and proxy servers that
allow requests to be delivered on existing connections established by
the User Agent.  It also defines keep alive behaviors needed to keep
NAT bindings open and specifies the usage of multiple connections from
the User Agent to its Registrar.




Working Group Summary

The working group process on this document was exceptionally long. The
first WG version of the draft appeared in the summer of 2005. Working
group last call initiated in the summer of 2006 and extended until the
summer of 2008, requring several iterations of the draft and the
assignment of Francois Audet as a "process champion" for the draft
within the working group. Most delays seem to have been related to
slow cycle time on the part of the authors, but the process was also
delayed by a number of changes occurring during the review cycle.

Particular sticking points included the keepalive mechanism and a
requirement for binding to multiple outbound proxies if so
configured. The latter was eventually resolved by a widely-accepted
compromise, but the keepalive topic is still being debated.  Although
there is a strong consensus for the keepalive technique specified in
this document, there is some reason to believe that there may be a
need for the keeplaive mechanism independently of the outbound
relationship. There is currently a draft proposing such a mechanism.

This suggests that it might have been more effective to document the
outbound binding and keepalive mechanisms independently.


Document Quality

There are numerous implementations of the protocol, and it has been
tested at SIPit events since 2005.