On 19 Aug 2014, at 18:33, Peter Saint-Andre <[email protected]> wrote:
> 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). > Much better >> 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. 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. :-) Deal. > >> 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). Great. > >> That will help me in sipcore :-) > > We're here for you! Thank 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... Right. /O _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
