Skip to main content

Automatic DNSSEC Bootstrapping using Authenticated Signals from the Zone's Operator
draft-ietf-dnsop-dnssec-bootstrapping-11

Revision differences

Document history

Date Rev. By Action
2024-07-16
(System)
Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-dnsop-dnssec-bootstrapping and RFC 9615, changed IESG state to RFC …
Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-dnsop-dnssec-bootstrapping and RFC 9615, changed IESG state to RFC Published)
2024-07-16
11 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2024-07-15
11 Carlos Pignataro Request closed, assignment withdrawn: Sheng Jiang Last Call OPSDIR review
2024-07-15
11 Carlos Pignataro Closed request for Last Call review by OPSDIR with state 'Overtaken by Events'
2024-07-13
11 Carlos Pignataro Request for Last Call review by OPSDIR is assigned to Sheng Jiang
2024-07-10
11 (System) RFC Editor state changed to AUTH48
2024-07-03
11 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2024-06-19
11 Barry Leiba Closed request for Last Call review by ARTART with state 'Overtaken by Events': Document has finished IESG processing
2024-06-19
11 Barry Leiba Assignment of request for Last Call review by ARTART to Jaime Jimenez was marked no-response
2024-06-04
11 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2024-06-04
11 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2024-06-04
11 (System) IANA Action state changed to In Progress from Waiting on Authors
2024-06-04
11 (System) IANA Action state changed to Waiting on Authors from In Progress
2024-06-04
11 (System) IANA Action state changed to In Progress from Waiting on Authors
2024-06-03
11 (System) IANA Action state changed to Waiting on Authors from In Progress
2024-05-28
11 (System) IANA Action state changed to In Progress
2024-05-28
11 (System) RFC Editor state changed to EDIT
2024-05-28
11 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2024-05-28
11 (System) Announcement was received by RFC Editor
2024-05-28
11 (System) Removed all action holders (IESG state changed)
2024-05-28
11 Liz Flynn IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup
2024-05-28
11 Liz Flynn IESG has approved the document
2024-05-28
11 Liz Flynn Closed "Approve" ballot
2024-05-28
11 Liz Flynn Ballot approval text was generated
2024-05-28
11 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2024-05-28
11 Peter Thomassen New version available: draft-ietf-dnsop-dnssec-bootstrapping-11.txt
2024-05-28
11 (System) New version approved
2024-05-28
11 (System) Request for posting confirmation emailed to previous authors: Nils Wisiol , Peter Thomassen
2024-05-28
11 Peter Thomassen Uploaded new revision
2024-05-27
10 Paul Wouters
[Ballot comment]
Thanks for addressing all my DICSUSS items and comments. I have updated my ballot to Yes,

One last comment left on the new …
[Ballot comment]
Thanks for addressing all my DICSUSS items and comments. I have updated my ballot to Yes,

One last comment left on the new text:

      If all else fails, the domain owner might have to request the removal of
        all DS records (e.g., by using the special-value CDS/CDNSKEY RRset
        specified in [RFC8078] Section 4) and have the transfer performed

I think the "e.g." sentence should be removed. This is "in case the dns operator
is not cooperating", so in that case one would assume they wouldn't update these
records either (and the domain owner would need to go through their registrar
website, which would cause the records to be removed at the parent via EPP.
2024-05-27
10 Paul Wouters [Ballot Position Update] Position for Paul Wouters has been changed to Yes from Discuss
2024-05-22
10 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2024-05-22
10 David Dong IANA Experts State changed to Expert Reviews OK from Reviews assigned
2024-05-20
10 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2024-05-20
10 Peter Thomassen New version available: draft-ietf-dnsop-dnssec-bootstrapping-10.txt
2024-05-20
10 Peter Thomassen New version accepted (logged-in submitter: Peter Thomassen)
2024-05-20
10 Peter Thomassen Uploaded new revision
2024-05-16
09 Jenny Bui IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation
2024-05-16
09 Éric Vyncke
[Ballot comment]
# Éric Vyncke, INT AD, comments for draft-ietf-dnsop-dnssec-bootstrapping-08

Thank you for the work put into this document, if widely used then it could …
[Ballot comment]
# Éric Vyncke, INT AD, comments for draft-ietf-dnsop-dnssec-bootstrapping-08

Thank you for the work put into this document, if widely used then it could help the deployment of DNSSEC.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Tim Wicinski  for the shepherd's detailed write-up including the WG consensus *but* it lacks the justification of the intended status and uses an old template.

Other thanks to Benson Muite, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-dnsop-dnssec-bootstrapping-08-intdir-telechat-muite-2024-05-12/ (and I have read Peter's reply)

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

I am sympathetic to Paul Wouter's comments about 'bailiwick' and the use of "_signal". The latter is probably to late to be changed.

## Section 2

Two normative "SHOULD" but no reason/suggestion on when the SHOULD can be bypassed.

## Section 4.1.1

"example.co.uk" is not a IANA/IETF reserved domain name. Suggest to use an actual reserved domain name.

Suggest to also add the RR type in the example.

Perhaps explain `Publication of signaling records under the in-bailiwick domain _signal.ns3.example.co.uk is not required`.

## Section 7

Like Erik Kline, I wonder whether the IANA considerations should include a request for _dsboot. The use of _dsboot is only briefly mentioned in section 1.1, which is rather weak for a proposed standard document (I was close to open a DISCUSS on this topic).
2024-05-16
09 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2024-05-16
09 Orie Steele [Ballot comment]
I agree with Eric Kline's comment regarding reservation for the "_dsboot".
2024-05-16
09 Orie Steele [Ballot Position Update] New position, No Objection, has been recorded for Orie Steele
2024-05-15
09 Murray Kucherawy
[Ballot comment]
I support Paul's DISCUSS especially with respect to Section 2.  It's peculiar to say a past process is obsolete and you SHOULD NOT …
[Ballot comment]
I support Paul's DISCUSS especially with respect to Section 2.  It's peculiar to say a past process is obsolete and you SHOULD NOT use it, because then continuing to use it is technically still supported by this document.  Don't we want to say that new implementations MUST NOT do the old thing and MUST do the new thing?  Using SHOULD effectively leaves two systems "live" rather than one.

This may be some ignorance talking, but: In Section 4.2, if it's found that the child is already securely delegated, should this be an error, or just treat the whole thing like a no-op?  Redundant verification returning an error seems an odd choice, but I'm probably missing some context.

I think the SHOULD in Section 4.3 should really be more like "Parental agents normally trigger ...".  I'm not clear on why this is a normative SHOULD.  What if I don't do it in those circumstances, but possibly in others?  I'm still compliant with a SHOULD then, right?  Why might I do it in other situations?  The text doesn't say.
2024-05-15
09 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2024-05-15
09 John Scudder [Ballot Position Update] New position, No Objection, has been recorded for John Scudder
2024-05-15
09 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2024-05-15
09 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2024-05-15
09 Peter Thomassen New version available: draft-ietf-dnsop-dnssec-bootstrapping-09.txt
2024-05-15
09 Peter Thomassen New version accepted (logged-in submitter: Peter Thomassen)
2024-05-15
09 Peter Thomassen Uploaded new revision
2024-05-15
08 Zaheduzzaman Sarker [Ballot comment]
Thanks for working on this specification. No objection from transport protocol considerations.
2024-05-15
08 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2024-05-14
08 Mahesh Jethanandani [Ballot Position Update] New position, No Objection, has been recorded for Mahesh Jethanandani
2024-05-14
08 Paul Wouters
[Ballot discuss]
I have a few items to discuss and some comments. I'm leaving out the discussion of _signal as a name, as this discussion …
[Ballot discuss]
I have a few items to discuss and some comments. I'm leaving out the discussion of _signal as a name, as this discussion is taking place on dnsop. While I have a preference, I'll abide by the consensus call of the dnsop wgchairs.

All Sections:

This document uses the term "bailiwick" a lot. The DNS Terminology series of RFCs recommands to avoid this term and use "in-domain" or "not in-domain".

Section 1:

        Readers are expected to be familiar with DNSSEC, including
        [RFC4033], [RFC4034], [RFC4035], [RFC6781], [RFC7344], and
        [RFC8078].

It should say:

        Readers are expected to be familiar with DNSSEC [BCP237].

It includes the same RFCs but BCP237 will get updated in the future.


Section 2:

        The DS enrollment methods described in Section 3 of [RFC8078]
        are deprecated and SHOULD NOT be used.

I find this to be inconsistent with the Update: 8078 clause, as without
"Section 3", you are basically obsoleting the entire 8078. I don't think
this document should obsolete it, it should augment it. I would rewrite
the above like:

        The DS enrollment method described in this document provides more
        security than the methods described in Section 3 of [RFC8078],
        and are therefor RECOMMENDED in favour of the methods specified
        in [RFC8078].

If the authors/WG insists on the "deprecated" language, it should also
Obsolete: 8078. But be aware that the document currently does make references
to it, which it cannot do if it obsoletes the document.

Section 4.1.1:

It is not clear to me if the "signaling domain" really has to be
its own zone or not. eg:

_dsboot.example.co.uk._signal.ns1.example.net

Could this be signed using the DNSKEY of "example.net", or does the
document insist on a zone cut at _signal.ns1.example.net ?

I think zone cut should not be mandatory, in which case the language that
uses "signaling domain" should be cleaned up to make this clear.

That would also mean language like this is no longer needed:

        The records are accompanied by RRSIG records created using the
        key(s) of the respective signaling zone.

It could just state something like:

        These records are signed with DNSSEC just like any other zone data.

Later on in the Operational Considerations, the issue is mentioned and
it states zone cuts are not mandatory. So I do think this needs some cleanup.


        in Step 3: any failure to retrieve the CDS/CDNSKEY RRsets
        located at the signaling name under any signaling domain,
        including failure of DNSSEC validation, or unauthenticated data
        (AD bit not set);

I think it also needs to exclude signaling signatures made by any DNSSEC
keys upstream from the DNS hoster's zone. Eg if we have _signal.ns1.example.net
we also do not want to see the CDS/CDNSKEY RRsets signed by .net or the root.


Section 5:

        CDS/CDNSKEY records and corresponding signaling records MUST
        NOT be published without the zone owner's consent.

This opens a can of worms. How is an implementer going to codify this
MUST? The only usable interpretation I can see is that the DNS hoster,
by being assigned the DNS hoster, has permissions to DNS host the zone
as it sees fit, and thus do DNSSEC. And especially not bother the zone
owner with techno-babble for permissions.

        Likewise, the child DNS operator MUST enable the zone owner

Again, this wades into legalize and contractual matters best left
outside of RFC specifications.


        a zone cut ensures that bootstrapping activities do not require
        modifications of the zone containing the nameserver hostname.

Why does this matter?
2024-05-14
08 Paul Wouters
[Ballot comment]
      If a child DNS operator implements the protocol

If a child DNS operator implements this specification


        …
[Ballot comment]
      If a child DNS operator implements the protocol

If a child DNS operator implements this specification


        (i.e. have a valid DNSSEC chain of trust)

I would say:

        (i.e. have a valid publicly resolvable DNSSEC chain of trust)

Otherwise one could argue the parent has to have some "special configuration"
(eg trustanchors) and then it is "valid".


        that are authoritative for the signaling domains
        _signal.ns1.example.net and _signal.ns2.example.org.

This implies that _signal MUST live at a zone cut. Is that required?
If so, why? [other text seems to say that it is not required]

        as an authenticated signal as described in Section 3.

I find Section 3 is not a real full "description" of the "authenticated
signal". Reading it is not enough to create such a "authenticated signal".


      To avoid relying on the benevolence of a single signaling
        domain parent (such as the corresponding TLD registry), it is
        RECOMMENDED to diversify the path from the root to the child's
        nameserver hostnames. This is best achieved by using different
        and independently operated TLDs for each one.

This should move to a Security Considerations section, and not be part
of the core protocol. Actually, it is ALSO already in there, so I would
just remove this paragraph.


Section 4.2:

        1. verify that the child is not currently securely delegated and
        that at least one of its nameservers is out of bailiwick;

I think the first part should clarify this be "ensuring the domain has
no DS records published at the parent". The way it is written, is that
if .ca would briefly lose its DS record, then nohats.ca can be considered
"not currently securely delegated", even if there is a DS record in .ca.


      2. query the CDS/CDNSKEY records at the child zone apex directly
        from each of the authoritative servers as determined by the
        delegation's NS record set (without caching);

What is "the delegation's NS record set"? Do you mean the NS RRset at
the parent or at the child? I think there should also be some text on
what to do when the parent and child NS RRsets for the domain mismatch.
(abort?)


        all record sets

All RRsets


        If the above steps succeed without error, the CDS/CDNSKEY records
        are successfully validated,

I would use verified instead of validated to avoid confusion with DNSSEC validation.


        However, the parental agent MUST

Remove the word "However, ".


        in Step 1: the child is already securely delegated or has
        in-bailiwick nameservers only;

or the path from the root to the child traverses an insecure delegation.


        CDS/CDNSKEY records [...]
        CDS/CDNSKEY RRsets [...]

USe consistent terminology. I recommend RRsets
2024-05-14
08 Paul Wouters [Ballot Position Update] New position, Discuss, has been recorded for Paul Wouters
2024-05-12
08 Roman Danyliw
[Ballot comment]
Thank you to Peter Yee for the GENART review.

** Section 6.  Editorial.
  The level of rigor in Section 4.2 is needed …
[Ballot comment]
Thank you to Peter Yee for the GENART review.

** Section 6.  Editorial.
  The level of rigor in Section 4.2 is needed to prevent publication of
  a half-baked DS RRset

Is “half-baked DS RRset” a term-of-art?  To improve readability, I recommend not using an idiomatic expression.

** Section 7.  Editorial. Per the reference to [draft-ietf-dnsop-dnssec-bootstrapping], this should likely be something like “[This RFC]” and subsequent comment of that string being replaced by the RFC Editor. 

** idnits reports:
  ** Obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499)
2024-05-12
08 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2024-05-12
08 Benson Muite Request for Telechat review by INTDIR Completed: Ready with Nits. Reviewer: Benson Muite. Sent review to list.
2024-05-09
08 Jim Guichard [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard
2024-05-08
08 Gunter Van de Velde
[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-dnsop-dnssec-bootstrapping-08.txt

Please find https://www.ietf.org/blog/handling-iesg-ballot-positions/ documenting the handling of ballots.

#GENERIC COMMENTS
#================

## idnits: …
[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-dnsop-dnssec-bootstrapping-08.txt

Please find https://www.ietf.org/blog/handling-iesg-ballot-positions/ documenting the handling of ballots.

#GENERIC COMMENTS
#================

## idnits: There seems to be an obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499)
2024-05-08
08 Gunter Van de Velde [Ballot Position Update] New position, No Objection, has been recorded for Gunter Van de Velde
2024-05-04
08 Erik Kline
[Ballot comment]
# Internet AD comments for draft-ietf-dnsop-dnssec-bootstrapping-08
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments …
[Ballot comment]
# Internet AD comments for draft-ietf-dnsop-dnssec-bootstrapping-08
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S7

* Should there be some kind of registration or reservation for the "_dsboot"
  meaning and usage described in this document?
2024-05-04
08 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2024-05-02
08 Bernie Volz Request for Telechat review by INTDIR is assigned to Benson Muite
2024-05-01
08 Éric Vyncke Requested Telechat review by INTDIR
2024-04-29
08 Liz Flynn Placed on agenda for telechat - 2024-05-16
2024-04-29
08 Warren Kumari Ballot has been issued
2024-04-29
08 Warren Kumari [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari
2024-04-29
08 Warren Kumari Created "Approve" ballot
2024-04-29
08 Warren Kumari IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2024-04-29
08 Warren Kumari Ballot writeup was changed
2024-04-26
08 Peter Yee
Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Peter Yee. Sent review to list. Submission of review completed at an earlier …
Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Peter Yee. Sent review to list. Submission of review completed at an earlier date.
2024-04-26
08 Peter Yee Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Peter Yee.
2024-04-26
08 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2024-04-23
08 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2024-04-23
08 David Dong
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-dnsop-dnssec-bootstrapping-08. If any part of this review is inaccurate, please let us know.

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

IANA has completed its review of draft-ietf-dnsop-dnssec-bootstrapping-08. If any part of this review is inaccurate, please let us know.

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

In the Underscored and Globally Scoped DNS Node Names registry located on the Domain Name System (DNS) Parameters registry group located at:

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

two new registrations will be made as follows:

RR Type: CDS
_ NODE NAME: _signal
Reference: [ RFC-to-be ]

RR Type: CDNSKEY
_ NODE NAME: _signal
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

We understand that this is the only action required to be completed upon approval of this document.

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 action that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist
2024-04-19
08 Carlos Pignataro Request for Last Call review by OPSDIR is assigned to Carlos Martínez
2024-04-18
08 Scott Rose Request for Last Call review by DNSDIR Completed: Ready. Reviewer: Scott Rose. Sent review to list.
2024-04-15
08 Jean Mahoney Request for Last Call review by GENART is assigned to Peter Yee
2024-04-13
08 Jim Reid Request for Last Call review by DNSDIR is assigned to Scott Rose
2024-04-13
08 Barry Leiba Request for Last Call review by ARTART is assigned to Jaime Jimenez
2024-04-12
08 David Dong IANA Experts State changed to Reviews assigned
2024-04-12
08 Cindy Morgan IANA Review state changed to IANA - Review Needed
2024-04-12
08 Cindy Morgan
The following Last Call announcement was sent out (ends 2024-04-26):

From: The IESG
To: IETF-Announce
CC: dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-dnssec-bootstrapping@ietf.org, tjw.ietf@gmail.com, warren@kumari.net …
The following Last Call announcement was sent out (ends 2024-04-26):

From: The IESG
To: IETF-Announce
CC: dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-dnssec-bootstrapping@ietf.org, tjw.ietf@gmail.com, warren@kumari.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Automatic DNSSEC Bootstrapping using Authenticated Signals from the Zone's Operator) to Proposed Standard


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'Automatic DNSSEC Bootstrapping
using Authenticated Signals from the
  Zone's Operator'
  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
last-call@ietf.org mailing lists by 2024-04-26. 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 introduces an in-band method for DNS operators to
  publish arbitrary information about the zones they are authoritative
  for, in an authenticated fashion and on a per-zone basis.  The
  mechanism allows managed DNS operators to securely announce DNSSEC
  key parameters for zones under their management, including for zones
  that are not currently securely delegated.

  Whenever DS records are absent for a zone's delegation, this signal
  enables the parent's registry or registrar to cryptographically
  validate the CDS/CDNSKEY records found at the child's apex.  The
  parent can then provision DS records for the delegation without
  resorting to out-of-band validation or weaker types of cross-checks
  such as "Accept after Delay".

  This document deprecates the DS enrollment methods described in
  Section 3 of RFC 8078 in favor of Section 4 of this document, and
  also updates RFC 7344.

  [ Ed note: This document is being collaborated on at
  https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/
  (https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/).
  The authors gratefully accept pull requests. ]




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



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




2024-04-12
08 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2024-04-12
08 Warren Kumari Last call was requested
2024-04-12
08 Warren Kumari Last call announcement was generated
2024-04-12
08 Warren Kumari Ballot approval text was generated
2024-04-12
08 Warren Kumari Ballot writeup was generated
2024-04-12
08 Warren Kumari IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2024-04-11
08 (System) Changed action holders to Warren Kumari (IESG state changed)
2024-04-11
08 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2024-04-11
08 Peter Thomassen New version available: draft-ietf-dnsop-dnssec-bootstrapping-08.txt
2024-04-11
08 Peter Thomassen New version accepted (logged-in submitter: Peter Thomassen)
2024-04-11
08 Peter Thomassen Uploaded new revision
2024-04-10
07 Warren Kumari 2024-04-05: AD Review - https://mailarchive.ietf.org/arch/msg/dnsop/kERF3PJh6yPH5JclJVOLLh-d-bo/
2024-04-10
07 (System) Changed action holders to Warren Kumari, Peter Thomassen, Nils Wisiol (IESG state changed)
2024-04-10
07 Warren Kumari IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested
2024-03-24
07 Tim Wicinski

(1) RFC is Standards Track, and this is the correct RFC type.

(2)

Technical Summary:

  This document introduces an in-band method for DNS operators …

(1) RFC is Standards Track, and this is the correct RFC type.

(2)

Technical Summary:

  This document introduces an in-band method for DNS operators to
  publish arbitrary information about the zones they are authoritative
  for, in an authenticated fashion and on a per-zone basis.  The
  mechanism allows managed DNS operators to securely announce DNSSEC
  key parameters for zones under their management, including for zones
  that are not currently securely delegated.


Working Group Summary:

The working group consensus was strong, and work was done to improve the examples
and the implementation section.

Document Quality:

Document quality is good - implemntations do exist and are documented, and testing
has been done to confirm interoperability.

Personnel:

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

Personnel:

Tim Wicinski is the Document Shepherd.

Warren Kumari is the Area Director.

(3) The Document Shepherd did a detailed review of the document
for content as well as simple editorial checks (spelling/grammar).
The shepherd feels the document is ready for publication.


(4) The Document Shepherd has no concerns on the depth or breadth of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) The WG Consensus on this document is strong.

(10) There has been no appeals.

(11) All nits found have been addressed by the authors.

(12) No formal review needed

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

(14) All normative references are in a clear state

(15) There are no downward normative references

(16) Document will update RFCs 7344 and 8078 and they are listed in the abstract and the introduction.

(17) Review of the IANA considerations is consistent with the document.


(18) No new IANA registries.

(19) N/A
2024-03-24
07 Tim Wicinski IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2024-03-24
07 Tim Wicinski IESG state changed to Publication Requested from I-D Exists
2024-03-24
07 (System) Changed action holders to Warren Kumari (IESG state changed)
2024-03-24
07 Tim Wicinski Responsible AD changed to Warren Kumari
2024-03-24
07 Tim Wicinski Document is now in IESG state Publication Requested
2024-03-24
07 Tim Wicinski Notification list changed to tjw.ietf@gmail.com because the document shepherd was set
2024-03-24
07 Tim Wicinski Document shepherd changed to Tim Wicinski
2024-03-24
07 Tim Wicinski

(1) RFC is Standards Track, and this is the correct RFC type.

(2)

Technical Summary:

  This document introduces an in-band method for DNS operators …

(1) RFC is Standards Track, and this is the correct RFC type.

(2)

Technical Summary:

  This document introduces an in-band method for DNS operators to
  publish arbitrary information about the zones they are authoritative
  for, in an authenticated fashion and on a per-zone basis.  The
  mechanism allows managed DNS operators to securely announce DNSSEC
  key parameters for zones under their management, including for zones
  that are not currently securely delegated.


Working Group Summary:

The working group consensus was strong, and work was done to improve the examples
and the implementation section.

Document Quality:

Document quality is good - implemntations do exist and are documented, and testing
has been done to confirm interoperability.

Personnel:

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

Personnel:

Tim Wicinski is the Document Shepherd.

Warren Kumari is the Area Director.

(3) The Document Shepherd did a detailed review of the document
for content as well as simple editorial checks (spelling/grammar).
The shepherd feels the document is ready for publication.


(4) The Document Shepherd has no concerns on the depth or breadth of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) The WG Consensus on this document is strong.

(10) There has been no appeals.

(11) All nits found have been addressed by the authors.

(12) No formal review needed

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

(14) All normative references are in a clear state

(15) There are no downward normative references

(16) Document will update RFCs 7344 and 8078 and they are listed in the abstract and the introduction.

(17) Review of the IANA considerations is consistent with the document.


(18) No new IANA registries.

(19) N/A
2024-02-14
07 Tim Wicinski IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2024-01-19
07 Peter Thomassen New version available: draft-ietf-dnsop-dnssec-bootstrapping-07.txt
2024-01-19
07 Peter Thomassen New version accepted (logged-in submitter: Peter Thomassen)
2024-01-19
07 Peter Thomassen Uploaded new revision
2023-10-02
06 Peter Thomassen New version available: draft-ietf-dnsop-dnssec-bootstrapping-06.txt
2023-10-02
06 Peter Thomassen New version accepted (logged-in submitter: Peter Thomassen)
2023-10-02
06 Peter Thomassen Uploaded new revision
2023-09-19
05 Tim Wicinski IETF WG state changed to In WG Last Call from WG Document
2023-09-14
05 Tim Wicinski Changed consensus to Yes from Unknown
2023-09-14
05 Tim Wicinski Intended Status changed to Proposed Standard from None
2023-07-17
05 Linda Dunbar Request for Early review by SECDIR Completed: Has Nits. Reviewer: Linda Dunbar. Sent review to list.
2023-07-12
05 Scott Rose Request for Early review by DNSDIR Completed: Ready. Reviewer: Scott Rose. Review has been revised by Scott Rose.
2023-07-10
05 Peter Thomassen New version available: draft-ietf-dnsop-dnssec-bootstrapping-05.txt
2023-07-10
05 Peter Thomassen New version accepted (logged-in submitter: Peter Thomassen)
2023-07-10
05 Peter Thomassen Uploaded new revision
2023-06-29
04 Tero Kivinen Request for Early review by SECDIR is assigned to Linda Dunbar
2023-06-27
04 Scott Rose Request for Early review by DNSDIR Completed: Ready with Issues. Reviewer: Scott Rose. Sent review to list.
2023-06-23
04 Geoff Huston Request for Early review by DNSDIR is assigned to Scott Rose
2023-06-23
04 Tim Wicinski Requested Early review by DNSDIR
2023-06-23
04 Tim Wicinski Requested Early review by SECDIR
2023-05-01
04 Peter Thomassen New version available: draft-ietf-dnsop-dnssec-bootstrapping-04.txt
2023-05-01
04 Peter Thomassen New version accepted (logged-in submitter: Peter Thomassen)
2023-05-01
04 Peter Thomassen Uploaded new revision
2023-02-17
03 Peter Thomassen New version available: draft-ietf-dnsop-dnssec-bootstrapping-03.txt
2023-02-17
03 Peter Thomassen New version accepted (logged-in submitter: Peter Thomassen)
2023-02-17
03 Peter Thomassen Uploaded new revision
2022-08-17
02 Tim Wicinski Changed document external resources from:

github_repo https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping
mailing_list_archive https://mailarchive.ietf.org/arch/browse/dnsop/?q=draft-ietf-dnsop-dnssec-bootstrapping
related_implementations https://github.com/desec-io/dsbootstrap

to:

github_repo https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping
mailing_list_archive https://mailarchive.ietf.org/arch/browse/dnsop/?q=draft-ietf-dnsop-dnssec-bootstrapping
2022-08-17
02 Peter Thomassen New version available: draft-ietf-dnsop-dnssec-bootstrapping-02.txt
2022-08-17
02 (System) New version approved
2022-08-17
02 (System) Request for posting confirmation emailed to previous authors: Nils Wisiol , Peter Thomassen
2022-08-17
02 Peter Thomassen Uploaded new revision
2022-06-17
01 Benno Overeinder Changed document external resources from:

github_repo https://github.com/desec-io/draft-thomassen-dnsop-dnssec-bootstrapping
mailing_list_archive https://mailarchive.ietf.org/arch/browse/dnsop/?q=draft-thomassen-dnsop-dnssec-bootstrapping
related_implementations https://github.com/desec-io/dsbootstrap

to:

github_repo https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping
mailing_list_archive https://mailarchive.ietf.org/arch/browse/dnsop/?q=draft-ietf-dnsop-dnssec-bootstrapping
related_implementations https://github.com/desec-io/dsbootstrap
2022-06-17
01 Peter Thomassen New version available: draft-ietf-dnsop-dnssec-bootstrapping-01.txt
2022-06-17
01 (System) New version approved
2022-06-17
01 (System) Request for posting confirmation emailed to previous authors: Nils Wisiol , Peter Thomassen
2022-06-17
01 Peter Thomassen Uploaded new revision
2022-05-14
00 Benno Overeinder Added to session: interim-2022-dnsop-01
2022-04-21
00 Tim Wicinski Changed document external resources from: None to:

github_repo https://github.com/desec-io/draft-thomassen-dnsop-dnssec-bootstrapping
mailing_list_archive https://mailarchive.ietf.org/arch/browse/dnsop/?q=draft-thomassen-dnsop-dnssec-bootstrapping
related_implementations https://github.com/desec-io/dsbootstrap
2022-04-21
00 Tim Wicinski This document now replaces draft-thomassen-dnsop-dnssec-bootstrapping instead of None
2022-04-21
00 Peter Thomassen New version available: draft-ietf-dnsop-dnssec-bootstrapping-00.txt
2022-04-21
00 Tim Wicinski WG -00 approved
2022-04-21
00 Peter Thomassen Set submitter to "Peter Thomassen ", replaces to draft-thomassen-dnsop-dnssec-bootstrapping and sent approval email to group chairs: dnsop-chairs@ietf.org
2022-04-21
00 Peter Thomassen Uploaded new revision