Re: [dane] Draft ietf-dane-srv-07

["Olle E. Johansson" <[e-mail]>]

On 19 Aug 2014, at 18:33, Peter Saint-Andre <[e-mail]> 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