Connection Reuse in the Session Initiation Protocol (SIP)
RFC 5923

Note: This ballot was opened for revision 14 and is now closed.

(Cullen Jennings) Yes

Alexey Melnikov (was Discuss) Yes

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Ralph Droms) No Objection

Comment (2009-07-13 for -)
No email
send info
I found the last paragraph of section 3 confusing:

   While this is adequate for TCP, TLS connections can be reused to send
   requests in the backwards direction since each end can be
   authenticated when the connection is initially set up.  Once the
   authentication step has been performed, the situation can thought to
   resemble the picture in Figure 1 except that the connection opened
   from A to B is shared; when A wants to send a request to B, it will
   reuse this connection, and when B wants to send a request to A, it
   will reuse the same connection.

I suggest simply striking the first phrase as I'm not sure what "adequte for TCP" means.  In the second paragraph, I suggest replacing "except that the connection opened from A to B is shared" with "except that A and B both use a single shared connection, for example, between port 8293 on A and port 5061 on B".  Clearer yet, but not necessarily worth the effort, would be a new figure 3 illustrating the single shared connection.

The normative behavior in the first and third paragraphs of section 8.1 seem to use "SHOULD" and "MUST" to describe the same behavior.

(Lisa Dusseault) No Objection

(Adrian Farrel) No Objection

Comment (2009-07-15 for -)
No email
send info
The terms "Alias" and "Persistent connection" look like nouns but are
defined as verbs.

===

Section 8.1 and 8.2 are unclear on exactly how long a connection should
be retained after its last use terminates. The text appears to state
that an implementation must not close a connection unless it 
experiences some form of resource shortage. Isn't this a bit extreme?

Surely this should be reflected in Section 8.3

===

Section 8.1
   The proposed mechanism uses a new Via header field parameter.  The
The mechanisms is no longer "proposed" it is real.

===

Seciton 8.3
   Either the client of the server may terminate a TLS session by
s/of/or/

(Russ Housley) No Objection

Comment (2009-07-13 for -)
No email
send info
  In the Gen-ART Review by Suresh Krishnan, he suggest an update to
  Section 3.  The example ephemeral ports used (8293 & 9741) do not
  correspond to ephemeral ports in most well known OS implementations.
  Please use ones from the suggested IANA range:  IANA suggests 49152
  to 65535.

(Tim Polk) No Objection

(Dan Romascanu) No Objection

(Robert Sparks) (was Discuss) No Objection

Magnus Westerlund No Objection