Skip to main content

Telechat Review of draft-ietf-dnsop-edns-key-tag-04
review-ietf-dnsop-edns-key-tag-04-opsdir-telechat-jethanandani-2017-02-01-00

Request Review of draft-ietf-dnsop-edns-key-tag
Requested revision 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 "Ace" Kumari , Paul E. Hoffman
I-D 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 G. Kelly (diff)
Genart Telechat review of -04 by Christer Holmberg (diff)
Assignment Reviewer Mahesh Jethanandani
State Completed
Request Telechat review on draft-ietf-dnsop-edns-key-tag by Ops Directorate Assigned
Reviewed revision 04 (document currently at 05)
Result Has nits
Completed 2017-02-01
review-ietf-dnsop-edns-key-tag-04-opsdir-telechat-jethanandani-2017-02-01-00
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

Status:

Ready with comments

Summary:

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 http://www.ietf.org/id-info/checklist :
  --------------------------------------------------------------------------

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

Thanks.

Mahesh Jethanandani
mjethanandani at gmail.com