Telechat Review of draft-ietf-dnsop-edns-key-tag-04

Request Review of draft-ietf-dnsop-edns-key-tag
Requested rev. no specific revision (document currently at 05)
Type Telechat Review
Team Ops Directorate (opsdir)
Deadline 2017-02-14
Requested 2017-01-01
Authors Duane Wessels, Warren Kumari, Paul Hoffman
Draft last updated 2017-02-01
Completed reviews Opsdir Telechat review of -04 by Mahesh Jethanandani (diff)
Genart Last Call review of -03 by Christer Holmberg (diff)
Secdir Last Call review of -03 by Scott Kelly (diff)
Genart Telechat review of -04 by Christer Holmberg (diff)
Assignment Reviewer Mahesh Jethanandani 
State Completed
Review review-ietf-dnsop-edns-key-tag-04-opsdir-telechat-jethanandani-2017-02-01
Reviewed rev. 04 (document currently at 05)
Review result Has Nits
Review completed: 2017-02-01


I have reviewed this document as part of the Operational directorate’s ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

Document reviewed:  draft-ietf-dnsop-edns-key-tag-04


Ready with comments


This document specifies two different ways for validating resolvers to signal to a server which keys are referenced in their chain-of-trust.  The data from such signaling allow zone administrators to monitor the progress of rollovers in a DNSSEC-signed zone.

Operational considerations:

The draft does say that the new signaling mechanism is optional to implement, and the data is used to monitor the progress of rollovers.  However, this is going into an existing environment. What is the migration path for this new signaling mechanism, or impact, if any on network operations?

Management considerations:

The draft needs to clearly outline management considerations for the new signaling method. It needs to state how the client, resolver, server, or any other nodes will be configured for signaling to work as defined. 

For example, it says in the draft that validating recursive resolver should be configured by at least one trust anchor. Even if the initial values for this trust anchor are out of the scope of the document, it would be helpful to know how the trust anchor itself is configured.

Fault management:

The draft clearly outlines some of the shortcoming of the different approaches of sending the Key Tags. If that is the case, and the signaling does not work, how would the fault be detected and/or corrected? 

What information for example would be helpful for an administrator to be able to do a root cause analysis or fault isolation.

Verifying correct operation:

As stated earlier, it is not clear how is it determined that the signaling is operating correctly when configured.

Accounting management:

Since this draft is about providing data to a zone administrator on rollover, what is the information that is being collected to monitor this information, and how is this information being collected for analysis.

A run of idnits revealed one issue that might need to be addressed:

  Checking nits according to :

  == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document.  If these are example addresses, they should be changed.


Mahesh Jethanandani
mjethanandani at