Subject: [dane] Closing some more (non-)issues.

From: Warren Kumari <[email-masked]>
Date: Wed, 2 Nov 2011 16:16:15 -0400

Hi there all,

I am attempting to do some cleanup before the face to face meeting in Taipei and so am trying to close some issues that I think have been addressed in newer version of the documents, in general discussions, or are not really applicable any more.
Many of these were opened back when the protocol doc was at -01 and have been addressed over time, folded into newer versions of the document. It is your chairs fault for not having closed these earlier...

Please clearly object, preferably by Friday if you feel that any of these are still issues that need to stay open / need to be addressed....

#6.
I believe that this is addressed in draft-ietf-dane-protocol-12 in Sections 1.2 Section 4.4, para. 4, 5 and Appendix B. 

#13
I believe that this addressed in draft-ietf-dane-protocol-12 in Sections 2.1, 2.2, 2.3, most of section 4 and Appendix B.

#18.
This was a somewhat exploratory question, and has been addressed in multiple discussion, and in the protocol document, Version -12, Section 4.x, Section 1.2 and Appendix B.

#34:
This issue is low on details ("waiting on me to make either one or the other proposal public..."), but much of this was discussed in #24 (http://www.ietf.org/mail-archive/web/dane/current/msg03169.html) and we think that the text in draft-ietf-dane-protocol-12 Appendix A.1, A.1.1 addresses it. Going to close it as worksforme, 

Open issues on which there was only vague consensus: 
#28: Interaction of SRV and TLSA records
The chairs *think* that the consensus is that this is adequately addressed in draft-ietf-dane-protocol-12, but the discussion just sort of petered out. Get your final knocks in now, or it will be "closed as addressed in -12".

Open issues on which there may have been consensus, but we were not able to figure out what it was :-P 
#35: Behavior for a supported algorithm that is not considered "strong" by the client. 
We will be reopening this discussion for a quick summary...

We are planning on going ahead with all this on Monday / Tuesday -- sorry for the short call... Please *clearly* and *concisely* indicate if you disagree with the above issues / resolutions, what *specifically* you are objecting to, and a proposed solution.

I will be on a plane for most of Sunday / Monday (IAD -> NRT -> TPE) and so will not be available.
W

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 03 Nov 2011 00:45:54 -0700

On Wed, 2011-11-02 at 16:16 -0400, Warren Kumari wrote:
> #34:
> This issue is low on details ("waiting on me to make either one or the
> other proposal public..."), but much of this was discussed in #24
> (http://www.ietf.org/mail-archive/web/dane/current/msg03169.html) and
> we think that the text in draft-ietf-dane-protocol-12 Appendix A.1,
> A.1.1 addresses it. Going to close it as worksforme, 

As I discussed with Ondřej back when we were considering ticket #24, the
problem is not solved: you cannot have different TLSA RRsets for
different ports in combination with wildcard hostnames.  However, I've
been slow in advancing either proposed solution, and it's not fair for
this to hold the document up.  The functionality can be added in a later
update, or even provided via a separate mechanism that composes with
DANE.  So please feel free to mark the issue as not to be addressed in
the initial DANE standard, but understand that it is not solved, nor
have we made the decision not to ever solve it.

-- 
Matt

---

From: Warren Kumari <[email-masked]>
Date: Thu, 3 Nov 2011 14:36:43 -0400

On Nov 3, 2011, at 3:45 AM, Matt McCutchen wrote:

> this to hold the document up.  

Thank you, appreciate it.

> The functionality can be added in a later
> DANE.  
> So please feel free to mark the issue as not to be addressed in

Understood.

We were originally hoping that DANE could be spun up, pound out a doc or two, declare victory and shut down, never to meet again... but it is becoming increasingly apparent that we are going to learn things as this gets deployed, that there are likely to be extensions / updates, / new uses, etc. 
This does means that we don't have to solve every problem in this round, and can punt some things to DANEbis (or a new WG, with new chairs).

W