Subject: [dane] Ben Campbell's Yes on draft-ietf-dane-srv-13: (with COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Tue, 21 Apr 2015 16:00:25 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-dane-srv-13: Yes

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 http://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:
http://datatracker.ietf.org/doc/draft-ietf-dane-srv/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this.  Protocols using SRV have been left out of the DANE
party for too long :-) But I still have a couple of comments:

3.1, 2nd paragraph (note)

I have mixed emotions about smtp-with-dane as an informational reference.
Putting it in a "note" aside, can one safely implement and use dane-srv
without reading that draft? (If the answer is really "yes", then I'm okay
with it.)

3.2, first paragraph:

Is this meant to imply that one must resolve every SRV target? I would
assume that it follows the normal SRV rules and application protocol
rules, which may or may not result in queries for every SRV target in the
set.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 22 Apr 2015 00:10:43 +0000

> without reading that draft? (If the answer is really "yes", then I'm okay

It was decided after some WG discussion (for lack of an obvious
alternative home) that the text describing how to deal with DNS
errors was to remain in the SMTP draft rather than be duplicated
in both.  So I think that readers of the SRV draft need to read
the DNS error handling text from the SMTP draft.

> rules, which may or may not result in queries for every SRV target in the

I would *not* expect that every SRV target needs to be resolved.
Rather it should suffice to resolve the targets one by one if the
application wishes to move from one target to the next, until a
satisfactory connection is established, at which point unresolved
targets are simply ignored.  All this subject to the usual precedence
and weight rules.

So the text (which I just noticed contains one "n" too many in
"connnection"):

   For each SRV target server connnection endpoint, the client makes A
   and/or AAAA queries, performs DNSSEC validation on the address (A or
   AAAA) response, and continues as follows based on the results:

really means for each "in turn", and only for as many as necessary.
Though some applications might resolves them all "in parallel", in
order to avoid latency costs when otherwise the first few might
fail to resolve.

-- 
	Viktor.