Moving DNSSEC Lookaside Validation (DLV) to Historic Status
draft-ietf-dnsop-obsolete-dlv-02

[Ballot discuss]
This document needs to incorporate the boilerplate about normative keywords from RFC 8174 as well as references to RFC 8174 and RFC 2119.

[Ballot comment]
A couple of suggestions since this is being written for posterity as a consensus document of the IETF:

s/not every validator actually implements DLV/not every validator actually implemented DLV/

s/The authors are not aware of any such use of DLV./There are no known uses of DLV for this./

[Ballot comment]
Section 1

It's probably best to consistently use the past tense here.

Section 3

  Historic status.  This is a clear signal to implementers that the DLV
  resource record and the DLV mechanism SHOULD NOT be implemented or
  deployed.

I suppose the debate about "SHOULD NOT" vs. "MUST NOT" has already happened
and does not need to be reopened, so I'll just leave it at that.

[Ballot comment]
** Section 1.  Is there a reference that can be cited to support the metric that 1389 of 1531 TLDs have secure delegation?

** Editorial.  From idnits: The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. 
    RFC 2119 keyword, line 117: '...he DLV mechanism SHOULD NOT be impleme...'

** Editorial -- The Table of Contents doesn’t appear to have generated the Section-to-Page Number mapping

[Ballot comment]
Hello,

thank you for this document.
IMHO it would be clearer if this document were to propose the new text for the updated RFCs, especially for 6840.

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

The IANA Functions Operator has completed its review of draft-ietf-dnsop-obsolete-dlv-01. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that upon approval of this document, there is a single action which we must complete.

In the Resource Record (RR) TYPEs registry on the Domain Name System (DNS) Parameters registry page located at

https://www.iana.org/assignments/dns-parameters/

the existing entry for

Type: DLV
Value: 32769
Meaning: DNSSEC Lookaside Validation
Reference: RFC4331
Template:
Registration Date:

will be marked Obsolete, and its reference will be changed to

[ RFC-to-be ][RFC4331]

This modification has already been reviewed and approved by a designated expert.

Note:  The action requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Amanda Baber
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-10-25):

From: The IESG
To: IETF-Announce
CC: tjw.ietf@gmail.com, Tim Wicinski , dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-obsolete-dlv@ietf.org, warren@kumari.net
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Moving DNSSEC Lookaside Validation (DLV) to Historic Status) to Proposed Standard

Please note that this document was originally Last Called on 2019-09-18 as Informational -- https://mailarchive.ietf.org/arch/msg/ietf-announce/RmSJ_aEt_522jT9rqEYmALxCvag
It was originally intended that the document text be copied into the status-change document -- but, that doesn't work, because we need a document to exist to actually update RFC 6698 and RFC 6840.
So, this requires a second IETF LC, with the header noting that this updates RFC 6698 and RFC 6840, and with the document now being Std Track.




The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'Moving DNSSEC Lookaside
Validation (DLV) to Historic Status'
  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 2019-10-25. 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


  This document obsoletes DNSSEC lookaside validation (DLV) and
  reclassifies RFCs 4431 and 5074 as Historic.  Furthermore, this
  document updates RFC 6698 by excluding the DLV resource record from
  certificates, and updates RFC 6840 by excluding the DLV registries
  from the trust anchor selection.




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

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-obsolete-dlv/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:
    rfc5074: DNSSEC Lookaside Validation (DLV) (Informational - IETF stream)
    rfc4431: The DNSSEC Lookaside Validation (DLV) DNS Resource Record (Informational - IETF stream)

I have reviewed the document and it is fine,
after the RFC is published the line should read
DLV 32769 DNSSEC Lookaside Validation (OBSOLETE)    [RFCXYZZ] [RFC4431]

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

The IANA Functions Operator has completed its review of draft-ietf-dnsop-obsolete-dlv-00. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Resource Record (RR) TYPEs registry on the Domain Name System (DNS) Parameters registry page located at:

https://www.iana.org/assignments/dns-parameters/

the existing entry for

Type: DLV
Value: 32769
Meaning: DNSSEC Lookaside Validation
Reference: RFC4331
Template:
Registration Date:

will be marked Obsolete.

IANA Question --> Should the reference be changed to [ RFC-to-be ] or have [ RFC-to-be ] added to the existing RFC4331?

As this document requests changes in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-09-18):

From: The IESG
To: IETF-Announce
CC: tjw.ietf@gmail.com, Tim Wicinski , dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-obsolete-dlv@ietf.org, warren@kumari.net
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Moving DNSSEC Lookaside Validation (DLV) to Historic Status) to Informational RFC


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'Moving DNSSEC Lookaside
Validation (DLV) to Historic Status'
  as Informational RFC

  Please note that this is primarily to support:
    https://datatracker.ietf.org/doc/status-change-dlv-to-historic
  and should be read with that.

We are using option 2 of
  https://www.ietf.org/about/groups/iesg/statements/designating-rfcs-historic-2014-07-20/


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 2019-09-18. 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


  This document obsoletes DNSSEC lookaside validation (DLV) and
  reclassifies RFCs 4431 and 5074 as Historic.




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

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


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

1. Summary

Document Shepherd:  Tim Wicinski
Area Director:      Warren Kumari

Document Type:

Document is Informational, but documents the moving of two standards to HISTORIC.

This document obsoletes DNSSEC lookaside validation (DLV) and
reclassifies RFCs 4431 and 5074 as Historic.


2. Review and Consensus

  Explain how actively the document was reviewed and discussed, by the
  working group and external parties, and explain in a general sense how
  much of the interested community is behind the document. Explain anything
  notable about the discussion of the document.

Consensus was Brought and Solid.

3. Intellectual Property

N/A

4. Other Points

  Note any downward references (see RFC 3967)
  and whether they appear in the DOWNREF Registry
  (http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry),
  as these need to be announced during Last Call.

N/A



-----
Checklist

This section is not meant to be submitted, but is here as a useful
checklist of things the document shepherd is expected to have verified
before publication is requested from the responsible Area Director. If
the answers to any of these is "no", please explain the situation in
the body of the writeup.

X Does the shepherd stand behind the document and think the document is
  ready for publication?

X Is the correct RFC type indicated in the title page header?

X Is the abstract both brief and sufficient, and does it stand alone as
  a brief summary?

X Is the intent of the document accurately and adequately explained in
  the introduction?

X Have all required formal reviews (MIB Doctor, Media Type, URI, etc.)
  been requested and/or completed?

X Has the shepherd performed automated checks -- idnits (see
  http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist),
  checks of BNF rules, XML code and schemas, MIB definitions, and so
  on -- and determined that the document passes the tests? (In general,
  nits should be fixed before the document is sent to the IESG.  If there
  are reasons that some remain (false positives, perhaps, or abnormal
  things that are necessary for this particular document), explain them.)

X Has each author stated that their direct, personal knowledge of any
  IPR related to this document has already been disclosed, in conformance
  with BCPs 78 and 79?

X Have all references within this document been identified as either
  normative or informative, and does the shepherd agree with how they
  have been classified?

X Are all normative references made to documents that are ready for
  advancement and are otherwise in a clear state?

X If publication of this document changes the status of any existing
  RFCs, are those RFCs listed on the title page header, and are the
  changes listed in the abstract and discussed (explained, not just
  mentioned) in the introduction?

N/A If this is a "bis" document, have all of the errata been considered?

X IANA Considerations:
    - Are the IANA Considerations clear and complete? Remember that IANA
      have to understand unambiguously what's being requested, so they
      can perform the required actions.
    - Are all protocol extensions that the document makes associated
      with the appropriate reservations in IANA registries?
    - Are all IANA registries referred to by their exact names (check
      them in http://www.iana.org/protocols/ to be sure)?
    - Have you checked that any registrations made by this document
      correctly follow the policies and procedures for the appropriate
      registries?
    - For registrations that require expert review (policies of Expert
      Review or Specification Required), have you or the working group
      had any early review done, to make sure the requests are ready
      for last call?
    - For any new registries that this document creates, has the working
      group actively chosen the allocation procedures and policies and
      discussed the alternatives? Have reasonable registry names been
      chosen (that will not be confused with those of other registries),
      and have the initial contents and valid value ranges been clearly
      specified?

1. Summary

Document Shepherd:  Tim Wicinski
Area Director:      Warren Kumari

Document Type:

Document is Informational, but documents the moving of two standards to HISTORIC.

This document obsoletes DNSSEC lookaside validation (DLV) and
reclassifies RFCs 4431 and 5074 as Historic.


2. Review and Consensus

  Explain how actively the document was reviewed and discussed, by the
  working group and external parties, and explain in a general sense how
  much of the interested community is behind the document. Explain anything
  notable about the discussion of the document.

Consensus was Brought and Solid.

3. Intellectual Property

N/A

4. Other Points

  Note any downward references (see RFC 3967)
  and whether they appear in the DOWNREF Registry
  (http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry),
  as these need to be announced during Last Call.

N/A



-----
Checklist

This section is not meant to be submitted, but is here as a useful
checklist of things the document shepherd is expected to have verified
before publication is requested from the responsible Area Director. If
the answers to any of these is "no", please explain the situation in
the body of the writeup.

X Does the shepherd stand behind the document and think the document is
  ready for publication?

X Is the correct RFC type indicated in the title page header?

X Is the abstract both brief and sufficient, and does it stand alone as
  a brief summary?

X Is the intent of the document accurately and adequately explained in
  the introduction?

X Have all required formal reviews (MIB Doctor, Media Type, URI, etc.)
  been requested and/or completed?

X Has the shepherd performed automated checks -- idnits (see
  http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist),
  checks of BNF rules, XML code and schemas, MIB definitions, and so
  on -- and determined that the document passes the tests? (In general,
  nits should be fixed before the document is sent to the IESG.  If there
  are reasons that some remain (false positives, perhaps, or abnormal
  things that are necessary for this particular document), explain them.)

X Has each author stated that their direct, personal knowledge of any
  IPR related to this document has already been disclosed, in conformance
  with BCPs 78 and 79?

X Have all references within this document been identified as either
  normative or informative, and does the shepherd agree with how they
  have been classified?

X Are all normative references made to documents that are ready for
  advancement and are otherwise in a clear state?

X If publication of this document changes the status of any existing
  RFCs, are those RFCs listed on the title page header, and are the
  changes listed in the abstract and discussed (explained, not just
  mentioned) in the introduction?

N/A If this is a "bis" document, have all of the errata been considered?

X IANA Considerations:
    - Are the IANA Considerations clear and complete? Remember that IANA
      have to understand unambiguously what's being requested, so they
      can perform the required actions.
    - Are all protocol extensions that the document makes associated
      with the appropriate reservations in IANA registries?
    - Are all IANA registries referred to by their exact names (check
      them in http://www.iana.org/protocols/ to be sure)?
    - Have you checked that any registrations made by this document
      correctly follow the policies and procedures for the appropriate
      registries?
    - For registrations that require expert review (policies of Expert
      Review or Specification Required), have you or the working group
      had any early review done, to make sure the requests are ready
      for last call?
    - For any new registries that this document creates, has the working
      group actively chosen the allocation procedures and policies and
      discussed the alternatives? Have reasonable registry names been
      chosen (that will not be confused with those of other registries),
      and have the initial contents and valid value ranges been clearly
      specified?