Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)
RFC 5626
Yes
(Robert Sparks)
No Objection
Lars Eggert
(Dan Romascanu)
(Lisa Dusseault)
(Magnus Westerlund)
(Pasi Eronen)
(Ron Bonica)
(Ross Callon)
(Russ Housley)
(Tim Polk)
Recuse
(Cullen Jennings)
Note: This ballot was opened for revision 20 and is now closed.
Lars Eggert
No Objection
Robert Sparks Former IESG member
Yes
Yes
()
Adrian Farrel Former IESG member
No Objection
No Objection
(2009-05-31)
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.
Alexey Melnikov Former IESG member
No Objection
No Objection
(2009-05-30)
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)".
Dan Romascanu Former IESG member
No Objection
No Objection
()
Lisa Dusseault Former IESG member
No Objection
No Objection
()
Magnus Westerlund Former IESG member
(was Discuss)
No Objection
No Objection
()
Pasi Eronen Former IESG member
No Objection
No Objection
()
Ralph Droms Former IESG member
No Objection
No Objection
(2009-06-02)
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.
Ron Bonica Former IESG member
No Objection
No Objection
()
Ross Callon Former IESG member
No Objection
No Objection
()
Russ Housley Former IESG member
No Objection
No Objection
()
Tim Polk Former IESG member
No Objection
No Objection
()
Cullen Jennings Former IESG member
Recuse
Recuse
()