Subject: [sipcore] draft-ietf-sipcore-dns-dual-stack: Simon Perreault's review

From: [email-masked] (Dale R. Worley)
Date: Sun, 24 Jan 2016 19:43:46 -0500

I've edited in a number of Simon's changes.  However:

Simon Perreault <[email-masked]> writes:
> - It's not clear to me whether Section 4.1 advocates parallel connections
> or not. Is Happy Eyeballs to be applied or not? Or are we not recommending
> one way or another? This needs to be made more explicit.

At this point, the relationship between this draft and Happy Eyeballs is
not clear to me.  My expectations of a combination of 3263 and "Happy
Eyeballs" are:

1. A client must look up both A and AAAA records for a destination in all
   situations where it looks up a destination.

2. A client whose initial attempt to reach a destination via IPv6 fails
   should quickly attempt to reach it via IPv4, regardless of whether the
   destination has declared that it prefers a second IPv6 address to its
   IPv4 address (RFC 6555 section 4 item 1).

3. A client must remember whether attempts to reach a destination via
   IPv6 have failed in the past, and if so, prefer IPv4 to reach it (RFC
   6555 section 4).

Item 1 does not seem to me to be normative.  RFC 3263 is a mess to read,
but any sensible integration of it with the RFCs it references seems to
me to imply that a SIP client (as RFC 3263 calls the sender) must look
up address records for all address families that it supports (in any of
the 3 situations in which it looks up address records).

Items 2 and 3 seem to me to be the essence of "Happy Eyeballs", and they
are normative changes to RFC 3263/2782, since when SRV records are
involved, the SRV records currently declare the order which the client
MUST use the specified addresses.

> - The guidance in Section 4.2 could benefit from stronger normative
> language:
> 
>    When indicating address family preference through SRV, IPv4-only and/
>    or IPv6-only clients should be prepared to handle SRV record sets
>    that don't resolve into an ip address in the address family used by
>    that client.  In such a case, the client should simply proceed to the
>    next priority and try the hostnames in the alternate address family.
> 
> Suggestion: s/should/MUST/g
> 
> And please remove the "and try the hostnames in the alternate address
> family." part, which makes no sense (a hostname cannot be "in an address
> family").

Actually, this paragraph should be moved out of section 4.2, because 4.2
is about how a client should indicate how it prefers to be contacted,
whereas this text is about *all* clients, that resolution may produce
addresses the client doesn't support, and it must be prepared to ignore
those addresses.

> minor
> =====
> 
> - Should this draft formally update RFC 3263?

Assuming that we're actually incorporating the Happy Eyeballs
processing, it updates RFC 3263:

- In regard to URIs that do not invoke SRV records, Happy Eyeballs
  processing provides more constraints on the sequence in which resolved
  addresses are used.  As a tightening of the requirements of RFC 3263,
  it is an update thereof.

- in regard to URIs that invoke SRV records, the sequence specified by
  the SRV records can be overridden.  This contravenes RFC 2782 as
  incorporated by RFC 3263, and so is an update.

However, Olle says:
> At one point it did, but the wg - especially Cullen Jennings - did not
> accept it. I personally still think it's needed.

How do we resolve this?

Dale

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 25 Jan 2016 08:12:02 +0100

> On 25 Jan 2016, at 01:43, Dale R. Worley <[email-masked]> wrote:
> 
> not clear to me.
This draft was meant to only clear up DNS lookups to prepare for another
draft that discusses Happy Eyeballs in SIP. But that one could not be done
if we did not have both A and AAAA records at the same time.

>  My expectations of a combination of 3263 and "Happy
> Eyeballs" are:
> 
The problem here is UDP. We’ve spent many hours discussing this.
For connection oriented protocols we can follow Happy Eyeballs,
but it doesn’t work for UDP. For UDP, we need a solution based 
on DNS. I think I have a presentation that outlines this somewhere.

>> accept it. I personally still think it's needed.
If we write documents in order to guide developers, an update
would be easy to follow while browsing the RFCs.  And it is indeed
an update. The formal problem that I think worries people is that
if we update RFC 3263 the definition of “SIP compliant” will change
and that will affect many vendors. Personally I think that’s a good thing.

/O

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 25 Jan 2016 14:54:01 -0500

> if we did not have both A and AAAA records at the same time.

If I understand you correctly:

The scope of this draft is quite narrow.  It is to update these two
passages of RFC 3263:

   4.2 Determining Port and IP Address

   [a host name with a port number:]
   If the TARGET was not a numeric IP address, but a port is present in
   the URI, the client performs an A or AAAA record lookup of the domain
   name.

   [...]

   [a host name without a port number, but no SRV records for the host name:]
   If no SRV records were found, the client performs an A or AAAA record
   lookup of the domain name.  The result will be a list of IP
   addresses, each of which can be contacted using the transport
   protocol determined previously, at the default port for that
   transport.  Processing then proceeds as described above for an
   explicit port once the A or AAAA records have been looked up.

to align with this passage of RFC 2782 (SRV records):

   Note that where this document refers to "address records", it means A
   RR's, AAAA RR's, or their most modern equivalent.

Is that correct?

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 25 Jan 2016 14:58:27 -0500

"Olle E. Johansson" <[email-masked]> writes:
> The formal problem that I think worries people is that if we update
> RFC 3263 the definition of "SIP compliant" will change and that will
> affect many vendors. Personally I think that's a good thing.

My understanding is that "SIP compliant", to be well-defined, must
always followed by a list of the RFCs that compliance is claimed for, so
the customers and vendors can always ask whether a device is compliant
with RFC 8123, or whatever it will be, as well as RFC 3263.  Certainly
this happened when "SIP" changed from RFC 2543 to RFC 3261.  But maybe
customers are acting differently these days.

Dale

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 26 Jan 2016 09:50:46 +0100

> On 25 Jan 2016, at 20:54, Dale R. Worley <[email-masked]> wrote:
> 

Yes, the one important point was to make sure that “A or AAAA” was redefined to clearly
mean “A and AAAA” records so that we would always have the possibility to
perform Happy Eyeballs. It’s mentioned in several places in RFC 3263 if I remember 
correctly and unfortunately copied to other RFCs.

The second part was using the DNS SRV to indicate the server manager’s
order of preference.

We’ve been discussing back and forth wheather the Happy Eyeballs part
should be part of this draft or not, but have decided multiple times to split it up.
It may or may not be the right way :-)

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 26 Jan 2016 09:52:07 +0100

> On 25 Jan 2016, at 20:58, Dale R. Worley <[email-masked]> wrote:
> 

I am not sure, but RFC 3261 clearly depends on 3263. If we update 3263,
doesn’t that mean that 3261 depends on the new RFC too?

So in order to be 3261 SIP-compliant, which is quite often a requirement,
it would also mean being compliant with proper dual stack handling,
as defined by this new draft…

/O

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 26 Jan 2016 11:04:28 -0500

> as defined by this new draft…

IIUC, you cannot revise history. Something that was once 3261 compliant 
remains so, regardless of what revisions are made later. That is why we 
don't reissue revised RFCs using the original numbers.

Revising 3263 doesn't automatically force implementations of 3261 to 
implement that revision.

What it does do is make compliance to 3261 something that should, in 
itself, be considered insufficient. If we wanted to provide a single RFC 
number that people could claim compliance to that would reflect the 
current understanding of sufficiency then we would need to issue a 
revision to 3261.

	Thanks,
	Paul