Subject: [sipcore] Suresh Krishnan's Discuss on draft-ietf-sipcore-dns-dual-stack-07: (with DISCUSS)

From: "Suresh Krishnan" <[email-masked]>
Date: Wed, 17 Aug 2016 14:58:26 -0700

Suresh Krishnan has entered the following ballot position for
draft-ietf-sipcore-dns-dual-stack-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-dns-dual-stack/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

* Section 3.1

It is not clear to me what exactly the normative addendum is requiring
the client to do as regards to the DNS query while implementing "The
dual-stack client SHOULD look up all address records". Does this mean
that the client should do a AAAA (28) query followed by (or in parallel
or preceded ) for a A (1) query? I think it would be good to clarify the
types and ordering/concurrency of the queries.

* Section 4

I am a bit puzzled by the merging of the address lists from two separate
DNS queries in relation to RFC6724. This is how I see the destination
address selection in RFC6724. The application ends up calling some kind
of name resolution API (something like getaddrinfo()) with a
hostname/FQDN (say sip-1.example.com) and this results in a set of
addresses being returned. The destination address selection algorithm
specified in Section 6 of RFC6724 then orders these addresses and picks
one. I am not seeing how the second FQDN and its associated set of
addresses become involved in the RFC6724 process. Is this something that
you are adding on top of RFC6724? Please clarify.

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 19 Aug 2016 16:30:24 -0400

> types and ordering/concurrency of the queries.

Given that the responses to DNS queries do not depend on the order in
which they are done, it seems to me that the only necessity is to
specify that the client must do both A and AAAA queries.

In regard to the specific record types, one of our goals was that the
wording should be robust to the possibility of additional address
families being created.  Thus we used the wording

      The dual-stack client SHOULD look up all address records [...] for
      all address family(ies) that it supports [...] for the domain name
      and add the resulting addresses to the list of IP addresses to be
      contacted.

Assuming that the client supports exactly IPv4 and IPv6, the queries to
obtain address records for those families are A and AAAA.  I don't see
that the text can be interpreted in a different way.

> you are adding on top of RFC6724? Please clarify.

One way of looking at it is that the full process of resolving the
server's address is the process for SRV records (RFC 2782) on top of the
destination address selection process (RFC 6724).  You've identified
that correctly.

The full process is fairly complicated, and the full documentation
involves the interaction of RFC 3263, RFC 2782, and RFC 6724.  But
restricting our attention to the case in question:

- The SRV records for domain name in the destination SIP URL are looked
  up.  (RFC 3263)

- Depending on the priority and weight fields (and the randomization
  implied by them!), the "target" domain names of the SRV records are
  listed in a particular order.  (RFC 2782)

The case in question is when there are more than one SRV records for the
destination domain name, and hence more than one target domain name.

- Each of those target domain names is expanded into a group of IPv4 and
  IPv6 addresses by looking up the A and AAAA records for the name.  Each
  group is sorted by the destination selection algorithm.  (This can be
  accomplished by calling getaddrinfo() on the target domain name.)
  (RFC 6724)

- The sorted groups of addresses for the target domain names are
  concatenated in the order of the target domain names.

The crucial point here is that the destination selection reordering is
only within the groups that result from the target domain names of the
SRVs -- The whole algorithm is a two-field sort with the "major" sort
being done by the SRV algorithm and the "minor" sort being done by
destination selection.

The original RFC 3263 specification describes the first two steps, but
presumes that the third step does not explicitly sort the addresses that
are obtained for the target domain name.  As a general rule, people who
have digested the rules of RFC 3263 agree that the "naturally correct"
way to incorporate destination selection (now that it exists for IPv6)
is to expand the third step to include that sortation -- and,
critically, that destination selection cannot reorder two addresses
between groups that derive from different target domain names.

The purpose of section 4 is to make that understanding normative.

Now, comparing what I have written here with the text in section 4, I
see that section 4 does not make explicit the ordered list of target
domain names from the SRV records.  And I can see that if the reader is
not thoroughly familiar with RFC 3263, that makes the overall process
significantly less clear, because it doesn't make step 2 above explicit.

I've updated the draft -08 to show the list of target domain names.
You can see the difference in
https://www.ietf.org/rfcdiff?url1=draft-ietf-sipcore-dns-dual-stack-07&url2=http://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore-dns-dual-stack-08.txt
and the entire current draft in
http://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore-dns-dual-stack-08.{txt,html}

Dale

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sat, 20 Aug 2016 08:26:10 +0200

> On 19 Aug 2016, at 22:30, Dale R. Worley <[email-masked]> wrote:
> 
Note that RFC 2782 (DNS SRV records) use a similar approach:

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

/O

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 22 Aug 2016 11:40:17 -0400

"Olle E. Johansson" <[email-masked]> writes:
>    RR's, AAAA RR's, or their most modern equivalent."

Indeed, the definition of "address records" at the end of section 2 of
draft-ietf-sipcore-dns-dual-stack-07 was derived from that definition in
RFC 2782.

Dale

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Thu, 25 Aug 2016 03:50:05 +0000

Hi Suresh -

Just following up on this.  The updated draft (-08) attempts to address your DISCUSS.  You can see the diffs here:

and the entire current draft can be found here:

http://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore-dns-du=
al-stack-08.txt<http://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore-dns-dual-stack-08.txt>

Once you confirm your points are addressed we will publish the -08 version.

Thanks,

Gonzalo

On Aug 19, 2016, at 4:30 PM, Dale R. Worley <[email-masked]<mailto:[email-masked]>> wrote:

"Suresh Krishnan" <[email-masked]<mailto:[email-masked]>> writes:
* Section 3.1

* Section 4

hostname/FQDN (say sip-1.example.com<http://sip-1.example.com>) and this results in a set of

Dale

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 30 Aug 2016 14:48:18 +0000

Hi Gonzalo,
   Looks good to me. I will clear once the new rev hits.

Thanks
Suresh

Gonzalo Salgueiro (gsalguei) wrote:
> al-stack-08.txt
> <http://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore-dns-dual-stack-08.txt>
>
>> "Suresh Krishnan" <[email-masked]
>> <mailto:[email-masked]>> writes:
>>> * Section 3.1
>>>
>>> hostname/FQDN (say sip-1.example.com <http://sip-1.example.com>) and this
>>> results in a set of

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Wed, 31 Aug 2016 20:49:53 +0000

Hi Suresh - 

We’ve posted the new version.

Thanks,

Gonzalo

> On Aug 30, 2016, at 10:48 AM, Suresh Krishnan <[email-masked]> wrote:
> 
> Hi Gonzalo,