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

["Suresh Krishnan" <[e-mail]>]

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.