Subject: [sipcore] Spencer Dawkins' Yes on draft-ietf-sipcore-dns-dual-stack-07: (with COMMENT)

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 16 Aug 2016 20:31:27 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-sipcore-dns-dual-stack-07: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-dns-dual-stack/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I appreciate this work. I do have one comment.

Could you provide some explanation for the reader as to why SIP is
"different", following this statement? Even an example would be useful.

   Unfortunately, in common SIP situations, it is not possible to "race"
   simultaneous request attempts using two address families.

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 19 Aug 2016 15:13:31 -0400

>    simultaneous request attempts using two address families.

That's a good point, because the reason is non-obvious to a reader who
hasn't hassled with SIP in unreliable network environments.

Racing in HTTP is the sending of simultaneous TCP SYNs to two different
addresses.  The client then continues the handshake and sends the
request to the address that responds first.  The crucial fact is that
opening a TCP connection to an HTTP server alone does not change the
server's state.

SIP requests are usually transmitted as single UDP packets, so sending
two copies of the request to two different addresses risks having two
copies of the request propagating through the SIP network at the same
time -- the difference from HTTP is that the SIP element cannot test the
route in a non-state-changing way.

If two copies of the same request arrive at one client, the client must
reject the second of them with a 482 response.  But this rule is not
sufficient to prevent user-visible differences in behavior because a
proxy that is upstream of the second request to arrive at the client may
(almost immediately!) serially fork the second request to further
destinations.  A version of this scenario that I saw in the wild is
diagrammed in
https://www.ietf.org/mail-archive/web/sipcore/current/msg06853.html.

I've added this explanation to section 3.2.  You can see the change in

https://www.ietf.org/rfcdiff?url1=draft-ietf-sipcore-dns-dual-stack-07&url2=http://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore-dns-dual-stack-08.txt

Dale

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 19 Aug 2016 15:10:46 -0500

Hi, Dale,

On Fri, Aug 19, 2016 at 2:13 PM, Dale R. Worley <[email-masked]> wrote:

> https://www.ietf.org/rfcdiff?url1=draft-ietf-sipcore-dns-
> dual-stack-07&url2=http://svn.resiprocate.org/rep/ietf-
> drafts/worley/draft-ietf-sipcore-dns-dual-stack-08.txt
>
> Dale
>

That's a terrific response to my comment. Thank you for including your
response in the document!

Spencer