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

["Gonzalo Salgueiro (gsalguei)" <[e-mail]>]

Hi Suresh - 

We’ve posted the new version.

Thanks,

Gonzalo



> On Aug 30, 2016, at 10:48 AM, Suresh Krishnan <[e-mail]> wrote:
> 
> 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
>> 
>