Aggressive Use of DNSSEC-Validated Cache
draft-ietf-dnsop-nsec-aggressiveuse-10

[Ballot comment]
I should ballot Discuss, so we can all tell Warren how awesome this draft is on the telechat itself.

More seriously, I'm pretty sure I was Gen-ART reviewer for the RFC being updated, and this update seems very much like the right thing to do.

[Ballot comment]
I agree with Adam's comment about the parenthetical phrasing in the abstract.

I see the intent for text in square brackets to be removed. Did I miss instructions to the RFC Editor to that effect? Most likely they will figure it out, but explicit instructions would be better.

[Ballot comment]
This seems like a good change; the description is well written and easy to understand; and the logic seems sounds and well-explained.

The abstract should remove the parentheses from the second paragraph, as they form an important (as opposed to incidental) part of the description of the update.

[Ballot comment]
One smallish, unimportant editorial comment:
In section 5, e.g.: "If the negative cache of the validating resolver has sufficient
  information to validate the query, the resolver SHOULD use NSEC,
  NSEC3 and wildcard records aggressively."
it seems like the word "aggressive" has some meaning which was at least not clear to me. Is there a difference in negative caching and aggressive negative caching? If this word should provide any additional information on what to do could you maybe further explain?

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Document: draft-ietf-dnsop-nsec-aggressiveuse

1)

RFC Type: Proposed Standard
Correct RFC type indicated in title:  yes

This Document is the correct type as it updates an existing Standards
Track Document (RFC4035)

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

(2)

Technical Summary

This document specifies the use of NSEC/NSEC3 resource records to
allow  DNSSEC validating resolvers to generate negative answers within
a range, and positive answers from wildcards.  This increases
performance / decreases latency, decreases resource utilization on
both authoritative and recursive servers, and also increases privacy.
It may also help increase resilience to certain DoS attacks in some
circumstances.-33


Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Document Shepherd: Tim Wicinski

Area Director:    Joel Jaeggli

(3)
The document shepherd did a deep dive on the document for technical
correctness, as well as an editorial pass for grammar and diction.
The shepherd feels this document is ready for publication.

(4)
The document shepherd does not have any concerns about the depth or breath of
the reviews.

(5)
No additional reviews needed.

(6)
The document shepherd has no concerns about this document for the Area
Directors.

(7) The authors have confirmed they are not aware of any IPR against this
document.

(9)
The working group is in strong consenus for this document.

(10)
There has been no extreme discontent.

(11)
No Nits found

(12)

(13)
All references have been identified as normative or informative

(14)
There are no normative references in an unclear state

(15)
There are normative references to RFCs 7129 and 7719.  Those are informational RFCs.

(16)
Publication of this document will update RFC 4035.

(17)
The IANA Considerations section requests the assignment of a new
EDNS0 option code.  Discussing with the Expert Reviewer of DNS parameters,
this section is correctly structured

(18)
No new IANA Registries

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-dnsop-nsec-aggressiveuse-08.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: tjw.ietf@gmail.com, dnsop-chairs@ietf.org, joelja@gmail.com, draft-ietf-dnsop-nsec-aggressiveuse@ietf.org, Tim Wicinski , dnsop@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Aggressive use of DNSSEC-validated Cache) to Proposed Standard


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document:
- 'Aggressive use of DNSSEC-validated Cache'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-03-27. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The DNS relies upon caching to scale; however, the cache lookup
  generally requires an exact match.  This document specifies the use
  of NSEC/NSEC3 resource records to allow DNSSEC validating resolvers
  to generate negative answers within a range, and positive answers
  from wildcards.  This increases performance / decreases latency,
  decreases resource utilization on both authoritative and recursive
  servers, and also increases privacy.  It may also help increase
  resilience to certain DoS attacks in some circumstances.

  This document updates RFC4035 by allowing validating resolvers to
  generate negative answers based upon NSEC/NSEC3 records (and positive
  answers in the presence of wildcards).

  [ Ed note: Text inside square brackets ([]) is additional background
  information, answers to frequently asked questions, general musings,
  etc.  They will be removed before publication.This document is being
  collaborated on in Github at: https://github.com/wkumari/draft-ietf-
  dnsop-nsec-aggressiveuse.  The most recent version of the document,
  open issues, etc should all be available here.  The authors
  (gratefully) accept pull requests.]




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc6982: Improving Awareness of Running Code: The Implementation Status Section (Experimental - IETF stream)
    draft-fujiwara-dnsop-nsec-aggressiveuse: Aggressive use of NSEC/NSEC3 (None - IETF stream)
    rfc7129: Authenticated Denial of Existence in the DNS (Informational - Independent Submission Editor stream)
    rfc7719: DNS Terminology (Informational - IETF stream)
Note that some of these references may already be listed in the acceptable Downref Registry.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Document: draft-ietf-dnsop-nsec-aggressiveuse

1)

RFC Type: Proposed Standard
Correct RFC type indicated in title:  yes

This Document is the correct type as it updates an existing Standards
Track Document (RFC4035)

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

(2)

Technical Summary

This document specifies the use of NSEC/NSEC3 resource records to
allow  DNSSEC validating resolvers to generate negative answers within
a range, and positive answers from wildcards.  This increases
performance / decreases latency, decreases resource utilization on
both authoritative and recursive servers, and also increases privacy.
It may also help increase resilience to certain DoS attacks in some
circumstances.-33


Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Document Shepherd: Tim Wicinski

Area Director:    Joel Jaeggli

(3)
The document shepherd did a deep dive on the document for technical
correctness, as well as an editorial pass for grammar and diction.
The shepherd feels this document is ready for publication.

(4)
The document shepherd does not have any concerns about the depth or breath of
the reviews.

(5)
No additional reviews needed.

(6)
The document shepherd has no concerns about this document for the Area
Directors.

(7) The authors have confirmed they are not aware of any IPR against this
document.

(9)
The working group is in strong consenus for this document.

(10)
There has been no extreme discontent.

(11)
No Nits found

(12)

(13)
All references have been identified as normative or informative

(14)
There are no normative references in an unclear state

(15)
There are no downward normative references


(16)
Publication of this document will update RFC 4035.

(17)
The IANA Considerations section requests the assignment of a new
EDNS0 option code.  Discussing with the Expert Reviewer of DNS parameters,
this section is correctly structured

(18)
No new IANA Registries