Skip to main content

Shepherd writeup
draft-ietf-dnsop-maintain-ds

1. Summary

Document Shepherd:   Tim Wicinski
Area Director:       Joel Jaggeli

Document Type: Standards Track

This document describes an in-band method for introducing and removing the
Initial DNSSEC trust anchor between a parent and a child domain.  This is done
by using the CDS/CDNSKEY DNS RR Types introduced in RFC7344. The document also
attempts to produce reasonable initial acceptance policy.

This work is extending the work done in RFC7344, which was published as an
Information document.  Time and experience has given the working group insight
that the use and deployment of the CDS/CDNSKEY are useful in DNSSEC adoption. 
Therefore, with the publication of this document, the previous document should
be elevated to Standards Track.

2. Review and Consensus

This working group was very supportive of this document, and discussion was
centered around assisting the adoption of DNSSEC, but also the management of
the DS Records. There was many constructive comments on the draft that have all
been addressed.  The consensus was broad across the working group and the
authors addressed all issues raised.

The shepherd also did a detailed editorial review during WGLC to ensure that
the document was in a more polished state.

3. Intellectual Property

There are no IPR related to this document.

IANA Considerations

The only IANA Considerations for this document is that the prior document
RFC7344 will be elevated from Informational to Standards Track.  Real world
experience has should that deploying CDS/CDNSKEY records are useful in the
deployment of DNSSEC.

4. Other Points

Once the IANA Considerations above are addressed, There are no downward
references in this document,

the

Explain anything else that the IESG might need to know when reviewing this
document. If there is significant discontent with the document or the process,
which might result in appeals to the IESG or especially bad feelings in the
working group, explain this in a separate email message to the responsible Area
Director.

Checklist

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),

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?
Back