[sipcore] Review of draft-ietf-sipcore-dns-dual-stack-01

[Simon Perreault <[e-mail]>]

All,

In Honolulu I agreed to review this draft. Here's my review!

Simon



Major
=====

- 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.

- 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").


Minor
=====

- Should this draft formally update RFC 3263?

- In section 1, has this been resolved?

   [[TODO: Sync with Vijay Gurbani on impacts of this draft to RFC
6157 <https://tools.ietf.org/html/rfc6157>,
   especially relative to the additional requirement that DNS be
   populated such that a certain address family is preferred.]]


- Please remove normative language from section 1 (i.e., the SHOULD in the
last paragraph).

- Section 4.1:

   Happy Eyeballs [RFC6555 <https://tools.ietf.org/html/rfc6555>] has
proven that looking up the "A or AAAA
   record" is not an effective practice for dual-stack clients and that
   it can add significant connection delay and greatly degrade user
   experience.


It is not Happy Eyeballs which has proven that, it is experience with
dual-stack. Suggestion: "Experience with dual-stack has proven that...".

- Section 4.1:

      The dual-stack client SHOULD perform an A and AAAA record lookup
      of the domain name and add the respective IPv4/IPv6 addresses to
      the list of IP addresses to be contacted.


Suggested rewording: "A dual-stack client SHOULD perform A and AAAA record
lookups of the domain name and add all resulting IPv4 and/or IPv6 addresses
to the list of IP addresses to be contacted."


Nits
===

- In the abstract, add a reference to the Happy Eyeballs RFC.

- Section 4.1:

   Once the transport protocol has been determined, the procedure for
   discovering an ip address


s/ip/IP/