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

[[e-mail] (Dale R. Worley)]

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

Simon Perreault <[e-mail]> 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