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

From: Simon Perreault <[email-masked]>
Date: Sat, 29 Nov 2014 11:47:56 -0500

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/

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sat, 29 Nov 2014 22:11:09 +0100

On 29 Nov 2014, at 17:47, Simon Perreault <[email-masked]> wrote:

> - 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:
> 
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
> =====
> 
At one point it did, but the wg - especially Cullen Jennings - did not accept it. I personally still think it's needed.
>    [[TODO: Sync with Vijay Gurbani on impacts of this draft to RFC 6157,
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] has proven that looking up the "A or AAAA
> 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:
> 
> 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.
>    discovering an ip address

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

/O
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Simon Perreault <[email-masked]>
Date: Sun, 30 Nov 2014 10:51:00 -0500

On Sat, Nov 29, 2014 at 4:11 PM, Olle E. Johansson <[email-masked]> wrote:

> We tried to avoid that to prepare for another draft that talks about the
> connections. This draft focuses on making

Ok, then say so explicitly. The numerous references to HE throughout the
text can easily trick the reader into thinking that HE is implicitly
required.

Simon