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

Regarding the SHOULD in 4.1 I think what needs to happen here is to make it clearer that it is a quote from RFC 2872, as normatively referenced by RFC 3263, and presumably therefore not a new requirement.

Or have I missed something.

Keith

________________________________
From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Olle E. Johansson
Sent: 29 November 2014 21:11
To: Simon Perreault
Cc: sipcore@ietf.org; Olle E Johansson; draft-ietf-sipcore-dns-dual-stack@tools.ietf.org
Subject: Re: [sipcore] Review of draft-ietf-sipcore-dns-dual-stack-01

On 29 Nov 2014, at 17:47, Simon Perreault <sperreault@jive.com<mailto:sperreault@jive.com>> wrote:

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.
We tried to avoid that to prepare for another draft that talks about the connections. This draft focuses on making
both the IPv4 and IPv6 candidates available.

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

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?
At one point it did, but the wg - especially Cullen Jennings - did not accept it. I personally still think it's needed.

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

It's been in planning for a long time - we have a set date in december now.

- 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."
THe normative language here is actually RFC 2782 - DNS SRV. Maybe we should avoid "should" here.

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/

Thank you very much for your review! We'll update the draft.

/O
_______________________________________________
sipcore mailing list
sipcore@ietf.org<mailto:sipcore@ietf.org>
https://www.ietf.org/mailman/listinfo/sipcore