Managing DS Records from the Parent via CDS/CDNSKEY
draft-ietf-dnsop-maintain-ds-06
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2017-03-07
|
06 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2017-02-10
|
06 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2017-01-31
|
06 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2017-01-11
|
06 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2017-01-10
|
06 | Paul Wouters | New version available: draft-ietf-dnsop-maintain-ds-06.txt |
2017-01-10
|
06 | (System) | New version approved |
2017-01-10
|
06 | (System) | Request for posting confirmation emailed to previous authors: "Olafur Gudmundsson" , "Paul Wouters" |
2017-01-10
|
06 | Paul Wouters | Uploaded new revision |
2017-01-10
|
05 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2017-01-10
|
05 | Paul Wouters | New version available: draft-ietf-dnsop-maintain-ds-05.txt |
2017-01-10
|
05 | (System) | New version approved |
2017-01-10
|
05 | (System) | Request for posting confirmation emailed to previous authors: "Olafur Gudmundsson" , "Paul Wouters" |
2017-01-10
|
05 | Paul Wouters | Uploaded new revision |
2017-01-09
|
04 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2017-01-09
|
04 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2017-01-09
|
04 | (System) | IANA Action state changed to In Progress |
2017-01-09
|
04 | (System) | RFC Editor state changed to EDIT |
2017-01-09
|
04 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2017-01-09
|
04 | (System) | Announcement was received by RFC Editor |
2017-01-09
|
04 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2017-01-09
|
04 | Amy Vezza | IESG has approved the document |
2017-01-09
|
04 | Amy Vezza | Closed "Approve" ballot |
2017-01-09
|
04 | Amy Vezza | Ballot approval text was generated |
2017-01-08
|
04 | Joel Jaeggli | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2017-01-08
|
04 | Joel Jaeggli | IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation::AD Followup |
2016-12-15
|
04 | Cindy Morgan | IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation |
2016-12-15
|
04 | Terry Manderson | [Ballot comment] Thank you for addressing my concerns. Clearing my DISCUSS. |
2016-12-15
|
04 | Terry Manderson | [Ballot Position Update] Position for Terry Manderson has been changed to No Objection from Discuss |
2016-12-15
|
04 | Kathleen Moriarty | [Ballot comment] Thanks for the added text. |
2016-12-15
|
04 | Kathleen Moriarty | [Ballot Position Update] Position for Kathleen Moriarty has been changed to No Objection from Discuss |
2016-12-15
|
04 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss |
2016-12-15
|
04 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2016-12-14
|
04 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2016-12-13
|
04 | Alvaro Retana | Ballot comment text updated for Alvaro Retana |
2016-12-12
|
04 | Joel Jaeggli | [Ballot comment] Separate standards action was carried for the RFC 7344 Standards action. Draft 04 moved the status change to the front-matter. Was Discuss: Place … [Ballot comment] Separate standards action was carried for the RFC 7344 Standards action. Draft 04 moved the status change to the front-matter. Was Discuss: Place holder for the discussion of a standards action for 7344 discussion I'm taking this off agendas until I get an update and the standards action. |
2016-12-12
|
04 | Joel Jaeggli | [Ballot Position Update] Position for Joel Jaeggli has been changed to Yes from Discuss |
2016-12-12
|
04 | Joel Jaeggli | Removed telechat returning item indication |
2016-12-12
|
04 | Joel Jaeggli | Placed on agenda for telechat - 2016-12-15 |
2016-12-12
|
04 | Joel Jaeggli | IESG state changed to IESG Evaluation from IESG Evaluation - Defer |
2016-11-12
|
04 | Jean Mahoney | Closed request for Last Call review by GENART with state 'No Response' |
2016-10-31
|
04 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2016-10-31
|
04 | Paul Wouters | New version available: draft-ietf-dnsop-maintain-ds-04.txt |
2016-10-31
|
04 | (System) | New version approved |
2016-10-31
|
03 | (System) | Request for posting confirmation emailed to previous authors: "Olafur Gudmundsson" , "Paul Wouters" |
2016-10-31
|
03 | Paul Wouters | Uploaded new revision |
2016-10-22
|
03 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'No Response' |
2016-10-11
|
03 | Joel Jaeggli | Removed from agenda for telechat |
2016-09-28
|
03 | Joel Jaeggli | Telechat date has been changed to 2016-10-13 from 2016-09-29 |
2016-09-28
|
03 | Joel Jaeggli | IESG state changed to IESG Evaluation - Defer from IESG Evaluation |
2016-09-28
|
03 | Joel Jaeggli | [Ballot discuss] Place holder for the discussion of a standards action for 7344 discussion I'm taking this off agendas until I get an update and … [Ballot discuss] Place holder for the discussion of a standards action for 7344 discussion I'm taking this off agendas until I get an update and the standards action. |
2016-09-28
|
03 | Joel Jaeggli | Ballot discuss text updated for Joel Jaeggli |
2016-09-28
|
03 | Alissa Cooper | [Ballot Position Update] Position for Alissa Cooper has been changed to No Objection from No Record |
2016-09-28
|
03 | Alissa Cooper | [Ballot comment] Will be following the resolutions of others' DISCUSSes. One more place where normative language seems inappropriate: "Turning off DNSSEC reduces the security of … [Ballot comment] Will be following the resolutions of others' DISCUSSes. One more place where normative language seems inappropriate: "Turning off DNSSEC reduces the security of the domain and thus should only be done carefully, and that decision SHOULD be fully under the child domain's control." |
2016-09-28
|
03 | Alissa Cooper | Ballot comment text updated for Alissa Cooper |
2016-09-26
|
03 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2016-09-12
|
03 | Joel Jaeggli | Telechat date has been changed to 2016-09-29 from 2016-09-15 |
2016-08-31
|
03 | Suresh Krishnan | [Ballot comment] Agree with Jari, Terry and would like to see the 7344 situation resolved. |
2016-08-31
|
03 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2016-08-31
|
03 | Alvaro Retana | [Ballot comment] I don't have an objection to this document changing the status RFC7344 -- but as others have mentioned, the change should be more … |
2016-08-31
|
03 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2016-08-31
|
03 | Joel Jaeggli | Telechat date has been changed to 2016-09-15 from 2016-09-01 |
2016-08-31
|
03 | Joel Jaeggli | [Ballot discuss] Place holder for the discussion of a standards action for 7344 discussion |
2016-08-31
|
03 | Joel Jaeggli | [Ballot Position Update] Position for Joel Jaeggli has been changed to Discuss from Yes |
2016-08-31
|
03 | Mirja Kühlewind | [Ballot comment] One technical comment: How does the client know that the parent supports the DNSSEC Delete Algorithm and it actually can turn of DNSSEC … [Ballot comment] One technical comment: How does the client know that the parent supports the DNSSEC Delete Algorithm and it actually can turn of DNSSEC after a while? What how long is a while? Would it be possible to define a reply message from the parent to the client to confirm that the deletion was understood? One more or less editorial comment: I agree with Spencer that the use of normative language in the security section is odd. All used SHOULDs should be lower case. But I would also recommend to rephrase to give clear guidance, e.g. OLD: "A parent zone might also consider sending an email to its contact addresses to give the child zone a warning that security will be enabled after a certain amount of wait time - thus allowing a child administrator to cancel the request." NEW: "A parent zone may send an email to its contact addresses to give the child zone a warning that security will be enabled after a defind amount of wait time - thus allowing a child administrator to cancel the request." OR: "A parent zone MAY send an email to its contact addresses to give the child zone a warning that security will be enabled after a defined amount of wait time - thus allowing a child administrator to cancel the request." |
2016-08-31
|
03 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2016-08-30
|
03 | Ben Campbell | [Ballot comment] I agree with Jari's and Terry's respective discusses. I will watch for the outcome of those discussions. Some other minor comments (I've skipped … [Ballot comment] I agree with Jari's and Terry's respective discusses. I will watch for the outcome of those discussions. Some other minor comments (I've skipped some that other people have already commented on, but I'm sure there's still overlap): - 1.2: It seems like scenarios 1 and 3 are restatements of the same thing. That is, cannot/does-not-want-to seems to count as an operational limitation. -4, 3rd paragraph: "If a validator sees a DNSKEY or DS record with this algorithm value, it MUST treat it as unknown." I suspect that, in the context of "Right now", this is talking about the current state of affairs, rather than defining a new requirement. Thus the 2119 MUST is probably not appropriate. -- 4th paragraph: I think this MUST is also not appropriate. It's part of the definition of algorithm "0", and not a procedural requirement. Editorial Comments: -1.3, first paragaph: "When this document uses the word CDS it implies that the same applies to CDNSKEY and vice verse." I don't understand this sentence. -2, first paragraph: s/influence/performe -2, operation 2: Please expand KSK on first use -2, 5th paragraph: It’s sort of confusing to talk about options labeled with ordinal numbers in a different order than their labels. -3, first paragraph: First Sentence: I'm not sure what "... enable... for the future." means. Does that mean “for the foreseeable future”, or perhaps “indefinitely enable”? -- 2nd sentence is hard to parse. I suggest the following: OLD Thus during the period from the time the child publishes the CDS until the corresponding DS is published at the parent is the period that DNS answers for the child could be forged. NEW DNS answers could be forged during the period between when the child publishes the CDS until the parent publishes the corresponding DS. -4, third paragraph: "Right now, ..." That language will quickly become dated. I suggest "At the time of this writing, ..." |
2016-08-30
|
03 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2016-08-30
|
03 | Terry Manderson | [Ballot discuss] Thanks for writing this and I think its useful for DNSSEC adoption, my DISCUSS is as follows. I have a concern about changing … [Ballot discuss] Thanks for writing this and I think its useful for DNSSEC adoption, my DISCUSS is as follows. I have a concern about changing the status of RFC7344 in this document from informational to standards track, especially given that this document builds on, or as I see it updates, 7344. This will surely be raised on the telechat. Especially given I still see gaps in the larger picture, such as: "In this case there is a possibility of setting up some kind of authentication mechanism and submission mechanism that is outside the scope of this document.." for enabling DNSSEC via CDS/CDNSKEY Can you please promote the first 2 paragraphs of the security considerations section to either the abstract or introduction. When reading this document I had almost exactly those words echoing in my head, and having them up front would better set the scene for why this document should exist - since you have written them already. |
2016-08-30
|
03 | Terry Manderson | [Ballot comment] can you please clarify: "In many people's minds, those two operations carry more risk than the first one." I read this as; … [Ballot comment] can you please clarify: "In many people's minds, those two operations carry more risk than the first one." I read this as; 'In many people's minds, those two operations carry more risk than operation 2." There are other nits in this document, but I think Stephen has already identified them. |
2016-08-30
|
03 | Terry Manderson | [Ballot Position Update] New position, Discuss, has been recorded for Terry Manderson |
2016-08-30
|
03 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2016-08-30
|
03 | Stephen Farrell | [Ballot comment] - I support Jari's discuss - but it might be fine to just chat about the 7344 status change, not sure. But that … [Ballot comment] - I support Jari's discuss - but it might be fine to just chat about the 7344 status change, not sure. But that said, I'm balloting yes, as this bootstrapping is definitely needed if DNSSEC is going to prosper. - please check and respond to the secdir review, [1] which overlaps a bit (but not totally) with my comments. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06685.html - 1.3: s/digiest/digest/ - 1.3: definition of RRR isn't clear (enough) - I think you want to define RRR to mean the current public DNS ecosystem maybe, but not sure if there's a subtlety somewhere in e.g. 3rd level and other domains. This might be clearer if you mention the PSL as a way to explain (not define) RRR. OTOH, you don't use RRR later at all, so you could just delete that term entirely and say a parent is typically an entity one above what's in the PSL, but can be lower down the naming hierarchy, e.g. within an enterprise. - section 2: calling operation 2 the "first one" is confusing, maybe re-order for clarity. Oh, and then you later mean "first one" == "operation 1" - so that does need fixing. Or just delete that para. - 2.1: I think you need to say that the acceptance policy for the very first use of CDS requires some out-of-band agreement, or is just done at the whim of the parent based on a possibly unknown policy. Ah, you do say that in section 3 - maybe consider re-doing the split into sections, e.g. make 2.1 be text at the start of 3. - section 3: I think it'd be good to call out the case where the domain is brand-new (i.e. never before existed) and has a CDS from the very first instant. That might fit in to 3.1, but I think it is worth a mention as a) it's a good goal to have (since it minimises the window without DNSSEC to zero) and so hopefully worth supporting and b) there's arguably no additional risk due to the CDS in this case, since the parent is also adding the delegation at the same time and c) it makes for better automation. That said, I'm not sure what s/w changes supporting that'd imply, but since a lot of parent registry code (APIs and such) are likely home-grown today, calling it out here might help ensure that parents don't all e.g. follow 3.3 or otherwise make DNSSEC-from-the-getgo hard or impossible. - 3.4: Do you need to say that the parent in this case ought monitor the child's DNS and react when the right challenge is visible? If it wasn't already done, this section might also be worth checking with some folks working on acme, as they have analysed such cases. |
2016-08-30
|
03 | Stephen Farrell | [Ballot Position Update] New position, Yes, has been recorded for Stephen Farrell |
2016-08-30
|
03 | Jari Arkko | [Ballot discuss] Thanks for this document. I have today reviewed both draft-ietf-dnsop-maintain-ds and RFC 7344, and personally find the recommendations and actions reasonable. I … [Ballot discuss] Thanks for this document. I have today reviewed both draft-ietf-dnsop-maintain-ds and RFC 7344, and personally find the recommendations and actions reasonable. I do have a similar concern as Robert did in his Gen-ART review, however, in making sure that the change to 7344 is properly highlighted. We should talk about this on the call on Thursday. |
2016-08-30
|
03 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded for Jari Arkko |
2016-08-29
|
03 | Spencer Dawkins | [Ballot comment] I understand why most of the 2119 language appears in this draft, but the SHOULDs in this text Users SHOULD keep in … [Ballot comment] I understand why most of the 2119 language appears in this draft, but the SHOULDs in this text Users SHOULD keep in mind that re-establishing trust in delegation can be hard and takes a long time. Before deciding to complete the rollover via an unsigned state, all options SHOULD be considered. don't look like 2119 SHOULDs to me. I also note that there's a SHOULD in section 1.2, but 2119 terminology isn't introduced until section 1.4 (easy enough to fix, by moving section 1.4 up, but). |
2016-08-29
|
03 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2016-08-29
|
03 | Alexey Melnikov | [Ballot comment] I agree with Kathleen that this is useful document. I also agree with her DISCUSS. I wish you could mandate use of S/MIME … [Ballot comment] I agree with Kathleen that this is useful document. I also agree with her DISCUSS. I wish you could mandate use of S/MIME or OpenPGP for confirmation emails suggested in the document, but this might be too much to ask for. |
2016-08-29
|
03 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2016-08-29
|
03 | Kathleen Moriarty | [Ballot discuss] Overall, this draft seems like a very useful and helpful draft. In reading it, I would like to see some security considerations around … [Ballot discuss] Overall, this draft seems like a very useful and helpful draft. In reading it, I would like to see some security considerations around the methods in section 3, in particular section 3.2, which is the loosest. Just seeing that the domain has been transferred seems like a risky check to rely on to me. The risks of using these proposed methods should be stated. Thanks. |
2016-08-29
|
03 | Kathleen Moriarty | [Ballot Position Update] New position, Discuss, has been recorded for Kathleen Moriarty |
2016-08-08
|
03 | Joel Jaeggli | Ballot has been issued |
2016-08-08
|
03 | Joel Jaeggli | [Ballot Position Update] New position, Yes, has been recorded for Joel Jaeggli |
2016-08-08
|
03 | Joel Jaeggli | Created "Approve" ballot |
2016-08-08
|
03 | Joel Jaeggli | Ballot writeup was changed |
2016-08-08
|
03 | Joel Jaeggli | Placed on agenda for telechat - 2016-09-01 |
2016-08-08
|
03 | Joel Jaeggli | IESG state changed to IESG Evaluation from Waiting for Writeup |
2016-07-14
|
03 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Benjamin Kaduk. |
2016-07-11
|
03 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2016-07-08
|
03 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2016-07-08
|
03 | Sabrina Tanamal | (Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-dnsop-maintain-ds-03.txt. If any part of this review is inaccurate, please let us know. NOTE: … (Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-dnsop-maintain-ds-03.txt. If any part of this review is inaccurate, please let us know. NOTE: Because Section 6.1 does not involve IANA, its text should be moved to another section of the document. IANA understands that, upon approval of this document, there is a single action which IANA must complete. In the DNS Security Algorithm Numbers subregistry of the Domain Name System Security (DNSSEC) Algorithm Numbers registry located at: https://www.iana.org/assignments/dns-sec-alg-numbers/ the existing entry for number 0 is to be modified. The reference [ RFC-to-be ] is to be added to the list of references for this value. IANA 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 only to confirm what actions will be performed. Thank you, Sabrina Tanamal IANA Specialist ICANN |
2016-06-30
|
03 | Jean Mahoney | Request for Last Call review by GENART is assigned to Robert Sparks |
2016-06-30
|
03 | Jean Mahoney | Request for Last Call review by GENART is assigned to Robert Sparks |
2016-06-30
|
03 | Jean Mahoney | Closed request for Last Call review by GENART with state 'Withdrawn' |
2016-06-30
|
03 | Jean Mahoney | Request for Last Call review by GENART is assigned to Brian Carpenter |
2016-06-30
|
03 | Jean Mahoney | Request for Last Call review by GENART is assigned to Brian Carpenter |
2016-06-30
|
03 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Benjamin Kaduk |
2016-06-30
|
03 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Benjamin Kaduk |
2016-06-29
|
03 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Suzanne Woolf |
2016-06-29
|
03 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Suzanne Woolf |
2016-06-27
|
03 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2016-06-27
|
03 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: "IETF-Announce" CC: tjw.ietf@gmail.com, dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-maintain-ds@ietf.org, "Tim Wicinski" , … The following Last Call announcement was sent out: From: The IESG To: "IETF-Announce" CC: tjw.ietf@gmail.com, dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-maintain-ds@ietf.org, "Tim Wicinski" , joelja@gmail.com Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Managing DS records from parent via CDS/CDNSKEY) to Proposed Standard The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Managing DS records from parent via CDS/CDNSKEY' 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 2016-07-11. 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 RFC7344 specifies how DNS trust can be partially maintained in-band between parent and child. There are two features missing in that specification: initial trust setup and removal of trust anchor. This document addresses both these omissions. Changing a domain's DNSSEC status can be a complicated matter involving multiple unrelated parties. Some of these parties, such as the DNS operator, might not even be known by all the organizations involved. The inability to disable DNSSEC via in-band signalling is seen as a problem or liability that prevents some DNSSEC adoption at large scale. This document adds a method for in-band signalling of these DNSSEC status changes. Initial trust is considered in general to be a hard technical problem, this document sets forth reasonable policies that clarify and simplify the initial acceptance policy. Elevating RFC 7344 to standards-track. Of note, the policy framework described in this document normatively references (thereby including it) a method described in the informational document RFC 7344 . This transition. should be considered it context of advancing this draft. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/ballot/ No IPR declarations have been submitted directly on this I-D. |
2016-06-27
|
03 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2016-06-27
|
03 | Joel Jaeggli | Last call was requested |
2016-06-27
|
03 | Joel Jaeggli | Ballot approval text was generated |
2016-06-27
|
03 | Joel Jaeggli | Ballot writeup was generated |
2016-06-27
|
03 | Joel Jaeggli | IESG state changed to Last Call Requested from AD Evaluation |
2016-06-27
|
03 | Joel Jaeggli | Last call announcement was changed |
2016-06-27
|
03 | Joel Jaeggli | Last call announcement was generated |
2016-06-21
|
03 | Joel Jaeggli | IESG state changed to AD Evaluation from Publication Requested |
2016-06-21
|
03 | Tim Wicinski | 1. Summary Document Shepherd: Tim Wicinski Area Director: Joel Jaggeli Document Type: Standards Track This document describes an in-band method for introducing and … 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? |
2016-06-21
|
03 | Tim Wicinski | Responsible AD changed to Joel Jaeggli |
2016-06-21
|
03 | Tim Wicinski | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2016-06-21
|
03 | Tim Wicinski | IESG state changed to Publication Requested |
2016-06-21
|
03 | Tim Wicinski | IESG process started in state Publication Requested |
2016-06-21
|
03 | Tim Wicinski | Changed document writeup |
2016-06-10
|
03 | Ólafur Guðmundsson | New version available: draft-ietf-dnsop-maintain-ds-03.txt |
2016-04-25
|
02 | Tim Wicinski | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2016-04-07
|
02 | Tim Wicinski | Changed consensus to Yes from Unknown |
2016-04-07
|
02 | Tim Wicinski | Intended Status changed to Proposed Standard from Informational |
2016-04-03
|
02 | Ólafur Guðmundsson | New version available: draft-ietf-dnsop-maintain-ds-02.txt |
2016-03-20
|
01 | Ólafur Guðmundsson | New version available: draft-ietf-dnsop-maintain-ds-01.txt |
2015-12-14
|
00 | Tim Wicinski | Notification list changed to "Tim Wicinski" <tjw.ietf@gmail.com> |
2015-12-14
|
00 | Tim Wicinski | Document shepherd changed to Tim Wicinski |
2015-12-14
|
00 | Tim Wicinski | Intended Status changed to Informational from None |
2015-12-14
|
00 | Tim Wicinski | This document now replaces draft-ogud-dnsop-maintain-ds instead of None |
2015-12-14
|
00 | Ólafur Guðmundsson | New version available: draft-ietf-dnsop-maintain-ds-00.txt |