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

[Suresh Krishnan <[e-mail]>]

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

Thanks
Suresh

Gonzalo Salgueiro (gsalguei) wrote:
> Hi Suresh -
>
>
> Just following up on this.  The updated draft (-08) attempts to address your
> DISCUSS.  You can see the diffs here:
>
> 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 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 <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>> "Suresh Krishnan" <[e-mail]
>> <mailto:[e-mail]>> writes:
>>> * 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.
>>
>> 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.
>>
>>> * 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 <http://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.
>>
>> 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
>