Last Call Review of draft-ietf-dnsop-edns-key-tag-03
review-ietf-dnsop-edns-key-tag-03-secdir-lc-kelly-2017-01-12-00

Request Review of draft-ietf-dnsop-edns-key-tag
Requested rev. no specific revision (document currently at 05)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2017-01-16
Requested 2017-01-02
Other Reviews Opsdir Telechat review of -04 by Mahesh Jethanandani (diff)
Genart Last Call review of -03 by Christer Holmberg (diff)
Genart Telechat review of -04 by Christer Holmberg (diff)
Review State Completed
Reviewer Scott Kelly
Review review-ietf-dnsop-edns-key-tag-03-secdir-lc-kelly-2017-01-12
Posted at https://mailarchive.ietf.org/arch/msg/secdir/SxO4kmS6GFId-yfXIzhzODpahCc
Reviewed rev. 03 (document currently at 05)
Review result Ready
Draft last updated 2017-01-12
Review completed: 2017-01-12

Review
review-ietf-dnsop-edns-key-tag-03-secdir-lc-kelly-2017-01-12

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

Summary: this draft is ready.

From the introduction, 

   This draft sets out to specify a way for validating resolvers to tell
   a server in a DNS query which DNSSEC key(s) they would use to
   validate responses from that zone.  This is done in two ways: using
   an EDNS option for use in the OPT meta-RR [RFC6891] that contains the
   key tags (described in Section 4), and by periodically sending
   special "key tag queries" to a server authoritative for the zone
   (described in Section 5).

That pretty well sums it up. The security and privacy considerations sections cover all relevant issues. I see no problems with this document.

Minor editorial comment: section 5.3 ends with this bracketed comment:

 [ Note RFC1035 says NULL
   RRs are not allowed in master files, but I believe that to be
   incorrect ]

I assume this will be resolved prior to publication?

--Scott