Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE)
RFC 7218

Note: This ballot was opened for revision 03 and is now closed.

(Richard Barnes) Yes

Comment (2014-02-19)
No email
send info
I am fine with changing this to Informational.

(Stephen Farrell) Yes

(Sean Turner) Yes

(Jari Arkko) No Objection

(Stewart Bryant) No Objection

Comment (2014-02-11 for -03)
No email
send info
Please expand DANE and TLSA on first use.

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

(Spencer Dawkins) No Objection

Comment (2014-02-20)
No email
send info
I would support either document class ("don't care").

(Adrian Farrel) No Objection

(Brian Haberman) No Objection

Comment (2014-02-18)
No email
send info
I agree with Pete's point that this should be an Informational document.

(Joel Jaeggli) No Objection

Barry Leiba No Objection

(Ted Lemon) No Objection

Comment (2014-02-19)
No email
send info
In section 2.2, right after the caption for Table 1, the following text appears:

   Other options suggested for 0: PKIX-TA

It appears that this is what is actually in the table, so this text makes no sense.

(Martin Stiemerling) No Objection

(Pete Resnick) (was Discuss) Abstain

Comment (2014-02-20)
No email
send info
Stephen and I spent a couple of billion nanoseconds on this. That's enough of them.

I do think that this document should be Informational. Any normative information is buried in an IANA Considerations section that I suspect will not be read after publication. Nothing requires that this be standards track, and the odds that it will advance are zero. The fact that it "Updates" a standards track document or that it is "changing a registry defined by a standards track document" does not require it to be standards track.

But the world will continue to spin. The number of bits spent on this has perturbed the spinning quite enough.