Hej Olle, thanks for the feedback and sorry about the slow response
time. Comments inline.
On 7/24/14, 2:19 AM, Olle E. Johansson wrote:
Hi!
Sorry for not having followed the details of the discussion lately,
so please excuse me if I'm too late with comments or ask about stuff
discussed in a gazillion emails before.
Section 3:
I really like this here, but would like it to be expanded a bit to
help implementors. The DNS SRV RFC is not easy to understand and in
the IP world RFC 3263 has confused a lot of people. DNS SRV says that
all candidates for a given priority should be attempted before one
moves to the next priority. It doesn't say anything about order,
which this document does when you say "SHOULD be performed in
parallell". If one given priority have two hosts with two IPv4 and
three IPv6 each - should all of them be tried in parallell?
This is a big issue and may be too big an issue for this document to
cover, especially with normative language.
I agree that normative language might not be appropriate. However, the
authors of this spec do think that performing the DNS queries (not, as
noted, the final application connection attempts) in parallel can help
to expedite things significantly. Here is some alternate wording:
OLD
To expedite connection to the intended service, where possible the
queries described in the following sections SHOULD be performed in
parallel (this is similar to the "happy eyeballs" approach for IPv4
and IPv6 connections described in [RFC6555]).
NEW
Developers of application clients that depend on DANE-SRV often
would like to prepare as quickly as possible for making a connection
to the intended service, thus reducing the wait time for end users.
To make this possible, a DNS library might perform the queries
described in the following sections in parallel, rather than waiting
for one set of queries to be completed (say, all SRV queries) before
performing additional queries (say, address queries and TLSA
queries).
Section 3.2
Please change "A/AAAA" to "A and AAAA" to be very clear that it's not
a choice if the client is dual stack.
Ack.
In fact the DNS SRV rfc talks
about "any address family" - now and in the future ;-)
We can always replace this spec when IPv12 is deployed. :-)
Section 5:
It would help me if you add a bullet like
* Handling in the case of protocols using NAPTR for transport
selection, like the Session Initiation Protocol
How is this?
o Use of SRV records with additional discovery technologies, such as
the use of both SRV records and NAPTR records [RFC2915] for
transport selection in the Session Initiation Protocol (SIP).
That will help me in sipcore :-)
We're here for you!
Section 6:
I think it would help implementors to explain a bit more detail -
that if you have multiple names in the cert, one could be the CN and
the others Subject Alt Names.
According to the SIP domain cert RFC the CN should be disregarded and
NOT used if there are any SANs. I don't know the reasoning behind
this. Anyone? Should we do that here too or just forget it?
I'd prefer to leave identity verification rules up to RFC 6125 or the
application-specific equivalent. There's a reason why RFC 6125 ended up
at 57 pages...
Peter
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
