DNS Root Name Service Protocol and Deployment Requirements
draft-iab-2870bis-03
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-12-07
|
03 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2015-12-02
|
03 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2015-11-30
|
03 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2015-11-25
|
03 | (System) | RFC Editor state changed to EDIT from AUTH |
2015-10-14
|
03 | (System) | Notify list changed from jari.arkko@piuha.net, housley@vigilsec.com, marc.blanchet@viagenie.ca, liman@netnod.se to housley@vigilsec.com, jari.arkko@piuha.net |
2015-09-30
|
03 | (System) | RFC Editor state changed to AUTH from EDIT |
2015-09-30
|
03 | (System) | RFC Editor state changed to EDIT |
2015-09-30
|
03 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2015-09-30
|
03 | (System) | Announcement was received by RFC Editor |
2015-09-29
|
03 | (System) | IANA Action state changed to No IC from In Progress |
2015-09-29
|
03 | (System) | IANA Action state changed to In Progress |
2015-09-29
|
03 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2015-09-29
|
03 | Amy Vezza | IESG has approved the document |
2015-09-29
|
03 | Amy Vezza | Closed "Approve" ballot |
2015-09-29
|
03 | Amy Vezza | Ballot approval text was generated |
2015-09-29
|
03 | Amy Vezza | Ballot writeup was changed |
2015-09-29
|
03 | Amy Vezza | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2015-09-24
|
03 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2015-09-24
|
03 | Marc Blanchet | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2015-09-24
|
03 | Marc Blanchet | New version available: draft-iab-2870bis-03.txt |
2015-07-02
|
02 | Jean Mahoney | Closed request for Telechat review by GENART with state 'No Response' |
2015-03-21
|
02 | Gunter Van de Velde | Request for Telechat review by OPSDIR Completed: Has Nits. Reviewer: Mahalingam Mani. |
2015-03-12
|
02 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2015-03-12
|
02 | Cindy Morgan | Changed consensus to Yes from Unknown |
2015-03-12
|
02 | Richard Barnes | [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes |
2015-03-12
|
02 | Alia Atlas | [Ballot comment] I do agree with Adrian's discuss as far as normative references go. |
2015-03-12
|
02 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2015-03-12
|
02 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2015-03-11
|
02 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2015-03-11
|
02 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Mahalingam Mani |
2015-03-11
|
02 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Mahalingam Mani |
2015-03-11
|
02 | Ted Lemon | [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon |
2015-03-11
|
02 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2015-03-10
|
02 | Spencer Dawkins | [Ballot Position Update] Position for Spencer Dawkins has been changed to No Objection from Discuss |
2015-03-10
|
02 | Spencer Dawkins | [Ballot discuss] This is an educate-Spencer Discuss, but MUST generate checksums when sending UDP datagrams and MUST verify checksums … [Ballot discuss] This is an educate-Spencer Discuss, but MUST generate checksums when sending UDP datagrams and MUST verify checksums when receiving UDP datagrams containing a non-zero checksum. is unchanged from RFC 2870, dated in 2000. Has anything changed in the past 15 years that would make rejecting UDP packets with zero checksums from root servers a better idea? A simple "no" will suffice, of course. But at least one TSV AD should ask. |
2015-03-10
|
02 | Spencer Dawkins | [Ballot Position Update] New position, Discuss, has been recorded for Spencer Dawkins |
2015-03-10
|
02 | Stephen Farrell | [Ballot comment] - I assume only copy editing changes will happen to rssac001 between now and publication. If not then, I'm confused. - I'm not … [Ballot comment] - I assume only copy editing changes will happen to rssac001 between now and publication. If not then, I'm confused. - I'm not sure whether anycast ought be a protocol or a service requirement. For now it's only in the rssac doc but is that right? (I can buy that it's good enough.) - I like E.3.1-B in the rssac doc, that should calm any worries I'd have thought. (Maybe we should thank them?) |
2015-03-10
|
02 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2015-03-09
|
02 | Kathleen Moriarty | [Ballot comment] Thanks for your work on this draft. I agree with the other suggestions made by Barry, Pete, & Adrian. The SecDir review mentions … [Ballot comment] Thanks for your work on this draft. I agree with the other suggestions made by Barry, Pete, & Adrian. The SecDir review mentions the need for a privacy discussion, but I don't think this draft is the right place for that as it really should be in the referenced drafts for each of the stated requirements (IMO). If they get updated, it would be good to add those as appropriate for each of the drafts. |
2015-03-09
|
02 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2015-03-08
|
02 | Adrian Farrel | [Ballot discuss] Adding a Discuss to by previous Comments (thanks to Deborah for raising this with me). Sections 2 and 3 tell us that implementations … [Ballot discuss] Adding a Discuss to by previous Comments (thanks to Deborah for raising this with me). Sections 2 and 3 tell us that implementations "MUST" do stuff described in a number of RFCs. I think that makes those RFCs normative references. I'm happy to be talked out of that, but you may a long way to go to persuade me. |
2015-03-08
|
02 | Adrian Farrel | [Ballot Position Update] Position for Adrian Farrel has been changed to Discuss from No Objection |
2015-03-06
|
02 | Brian Haberman | [Ballot comment] I agree with the points raised by Adrian, Barry, & Pete. |
2015-03-06
|
02 | Brian Haberman | [Ballot Position Update] New position, Yes, has been recorded for Brian Haberman |
2015-03-06
|
02 | Adrian Farrel | [Ballot comment] I'm balloting No Objection, but there are some relatively trivial things that could be done to improve the document. --- It's a shame … [Ballot comment] I'm balloting No Objection, but there are some relatively trivial things that could be done to improve the document. --- It's a shame about the passive voice in the Abstract. It makes it unclear who has the expectation. Additionally, the choice of words makes it unclear whether you are saying "we have an expectation that you will do this" or "we are predict this will happen." In fact, they are "implementation and deployment requirements." Is there a need to say more? --- Section 2 Operative details are documented in [RSSAC-001] and implementation is left to the operators of the root name service. Implementation of what? --- The document really should make clear whether there are any changes to the requirements originally espoused in 2870. If there are, they can be flagged. If not, it is just a few words to say so. --- The Abstract should make note of Obsoleting 2870. I believe idnits tells you to do this. |
2015-03-06
|
02 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2015-03-05
|
02 | Barry Leiba | [Ballot comment] -- Section 3 -- The root name service: MUST answer queries from any entity conforming to [RFC1122] … [Ballot comment] -- Section 3 -- The root name service: MUST answer queries from any entity conforming to [RFC1122] with a valid IP address. During discussion, Liman agreed that it might be good to add "subject to operational considerations", or something like that. That sounds like a wise and useful addition. Thanks for discussing it with me. |
2015-03-05
|
02 | Barry Leiba | [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss |
2015-03-05
|
02 | Barry Leiba | [Ballot discuss] -- Section 3 -- The root name service: MUST answer queries from any entity conforming to [RFC1122] … [Ballot discuss] -- Section 3 -- The root name service: MUST answer queries from any entity conforming to [RFC1122] with a valid IP address. Does this mean that the root name service is not allowed to stop answering queries in order to address DoS attacks? Or is this somehow covered by 1122? |
2015-03-05
|
02 | Barry Leiba | [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba |
2015-03-04
|
02 | Pete Resnick | [Ballot discuss] [Updating per Jari's suggestion that the words should be different now that RSSAC-001 is done.] I strongly agree with Paul Hoffman's suggested rewording … [Ballot discuss] [Updating per Jari's suggestion that the words should be different now that RSSAC-001 is done.] I strongly agree with Paul Hoffman's suggested rewording in section 1: OLD The operational requirements are defined in [RSSAC-001]. This document defines the protocol requirements and some deployment requirements. NEW This document only defines the protocol requirements and some deployment requirements; the operational requirements that were defined in RFC 2870 are removed. Operational requirements are now defined by the Root Server System Advisory Committee of ICANN and are documented in [RSSAC-001]. END Stating it as it is currently written (along with the text in 1.1) makes it sound like RSSAC is somehow part of the BCP, which it obviously cannot be. Please make the above change. Please strike section 1.1. My understanding is that the IAB does not consider it necessary to move 2870 to Historic, and the fact that this is obsoleting 2870 and replacing it in the BCP series is sufficient. (Even if this weren't so, documents don't "reclassify" other document as Historic.) Further, the above change in section 1 makes the second part of 1.1 unnecessary. In the header: Please add "BCP: 40 (if approved)" |
2015-03-04
|
02 | Pete Resnick | Ballot discuss text updated for Pete Resnick |
2015-03-04
|
02 | Jari Arkko | Sponsoring AD's view of the current state: I wanted to come back to the status of the discussions. We have an ongoing discussion of the … Sponsoring AD's view of the current state: I wanted to come back to the status of the discussions. We have an ongoing discussion of the changes Marc made on the -02. My read of the feedback is that the update has done the right things, but: 1) Paul Hoffman’s clarifications & editorial changes seem useful, but I would like to hear what others think. Marc, you should respond to those as well. 2) Mark Andrews’ suggestion of further requirements regarding reserved bits was discussed, but should proceed separately. 3) Mark Andrews' suggestion of further requirements regarding EDNS0 has not been discussed, but I would note that at this stage we should not add major requirements without substantial community portion indicating that this is needed. I’m not hearing it. 4) I’ve also received feedback from IESG members that the text about moving 2870 to Historic in Section 1.1 could be problematic. While I’m not sure that is necessarily the case, I think this draft merely replaces 2870, so I am not sure we need to say anything more. I have confirmed with the IAB that it does not believe the part about moving 2870 to Historic is necessary. Does anyone object to this change? With regards to the earlier discussions in the last call in the summer, Marc’s message discussed some of the things where an agreement was clearly found. I don’t think I need to report further on that. However, I wanted to highlight a few other items: I believe there is rough consensus to publish an updated BCP (subject to some detailed clarifications, still ongoing). There was some discussion about whether it is appropriate for the IETF to do this, but my read of the discussion is that the topic was explored and that a reasonable division of work between the RSSAC and IETF exists, even with some roughness of the opinions within the group. The IETF role in this case is to provide high-level requirements for the service. Specifically for this service, even if some broader statements have been made about all nodes previously. But is not our role to enforce anything or deal with the operational issues. There was some discussion of the meaning of the requirements currently in the document, and whether clarifying text was needed to specify whether they apply to individual nodes or the service. Michael Richardsson (among others) has supported the current text as it really is about the service. This is another topic where there is some roughness in the group, but I believe the initial question has been adequately answered and has at least some support in the group. A big problem last summer was that we did not yet have a document from the RSSAC. With the stable RSSAC document now available, it is possible to proceed. From my read of the commentary, the following items may deserve further thought. Marc, can you deal with these? * Joe Abley’s comment about qualifying the requirement to answer queries from any valid IP address with respect to operational events (such as attacks). While I believe the operational issues are indeed in the RSSAC scope, I think we should qualify our requirement to be subject to operational issues. * Klaas Wieranga’s Secdir review made a suggestion about privacy related to root queries, and how caching mitigates some of the concerns. Text could be added about this, although it is of course somewhat obvious state of affairs. I’ll leave it to the editor’s discretion what to do here. |
2015-03-04
|
02 | Jari Arkko | Telechat date has been changed to 2015-03-12 from 2015-03-05 |
2015-03-04
|
02 | Jari Arkko | There are still some issues, or at least unfinished discussion, with this document, but it is being brought forward to IESG review. |
2015-03-04
|
02 | Jari Arkko | IESG state changed to IESG Evaluation from Waiting for Writeup |
2015-03-04
|
02 | Pete Resnick | [Ballot discuss] I strongly agree with Paul Hoffman's suggested rewording in section 1: Current: The operational requirements are defined in [RSSAC-001]. This document … [Ballot discuss] I strongly agree with Paul Hoffman's suggested rewording in section 1: Current: The operational requirements are defined in [RSSAC-001]. This document defines the protocol requirements and some deployment requirements. Proposed: This document only defines the protocol requirements and some deployment requirements; the operational requirements that were defined in RFC 2870 are removed. It is expected that ICANN's RSSAC [RSSAC] will define the operational requirements. Stating it as it is currently written (along with the text in 1.1) makes it sound like RSSAC is somehow part of the BCP, which it obviously cannot be. Please make the above change. Please strike section 1.1. My understanding is that the IAB does not consider it necessary to move 2870 to Historic, and the fact that this is obsoleting 2870 and replacing it in the BCP series is sufficient. (Even if this weren't so, documents don't "reclassify" other document as Historic.) Further, the above change in section 1 makes the second part of 1.1 unnecessary. In the header: Please add "BCP: 40 (if approved)" |
2015-03-04
|
02 | Pete Resnick | [Ballot Position Update] New position, Discuss, has been recorded for Pete Resnick |
2015-03-04
|
02 | Jari Arkko | Notification list changed to jari.arkko@piuha.net, housley@vigilsec.com, marc.blanchet@viagenie.ca, liman@netnod.se from jari.arkko@piuha.net,housley@vigilsec.com,marc.blanchet@viagenie.ca |
2015-03-04
|
02 | Jari Arkko | Ballot has been issued |
2015-03-04
|
02 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko |
2015-03-04
|
02 | Jari Arkko | Created "Approve" ballot |
2015-03-04
|
02 | Jari Arkko | Ballot writeup was changed |
2015-03-04
|
02 | Jari Arkko | Note field has been cleared |
2015-02-25
|
02 | Jean Mahoney | Request for Telechat review by GENART is assigned to Martin Thomson |
2015-02-25
|
02 | Jean Mahoney | Request for Telechat review by GENART is assigned to Martin Thomson |
2015-02-19
|
02 | Jari Arkko | Telechat date has been changed to 2015-03-05 from 2015-02-19 |
2015-02-19
|
02 | Amanda Baber | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2015-02-14
|
02 | Marc Blanchet | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2015-02-14
|
02 | Marc Blanchet | New version available: draft-iab-2870bis-02.txt |
2015-02-12
|
01 | Jean Mahoney | Request for Telechat review by GENART is assigned to Martin Thomson |
2015-02-12
|
01 | Jean Mahoney | Request for Telechat review by GENART is assigned to Martin Thomson |
2015-02-03
|
01 | Jari Arkko | Note added 'Note: a new version is being prepared before the IESG review can happen. Waiting for -02 to appear soon.' |
2015-02-03
|
01 | Jari Arkko | Placed on agenda for telechat - 2015-02-19 |
2015-02-03
|
01 | Jari Arkko | Confirmed the status with Marc Blanchet. Now that the RSSAC document is out, Marc needs to provide a new revision with LC comments and feedback … Confirmed the status with Marc Blanchet. Now that the RSSAC document is out, Marc needs to provide a new revision with LC comments and feedback from RSSAC, and then I will take the document to the IESG for final approval. |
2014-06-24
|
01 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Mahalingam Mani. |
2014-06-20
|
01 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2014-06-08
|
01 | Jari Arkko | Notification list changed to : jari.arkko@piuha.net,housley@vigilsec.com,marc.blanchet@viagenie.ca |
2014-06-03
|
01 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2014-06-03
|
01 | Pearl Liang | IESG/Authors/WG Chairs: IANA has reviewed draft-iab-2870bis-01, which is currently in Last Call, and has the following comments: We understand that, upon approval of this … IESG/Authors/WG Chairs: IANA has reviewed draft-iab-2870bis-01, which is currently in Last Call, and has the following comments: We understand that, upon approval of this document, there are no IANA Actions that need completion. While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object. If this assessment is not accurate, please respond as soon as possible. |
2014-05-30
|
01 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Klaas Wierenga. |
2014-05-26
|
01 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Mahalingam Mani |
2014-05-26
|
01 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Mahalingam Mani |
2014-05-23
|
01 | Martin Thomson | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Martin Thomson. |
2014-05-22
|
01 | Jean Mahoney | Request for Last Call review by GENART is assigned to Martin Thomson |
2014-05-22
|
01 | Jean Mahoney | Request for Last Call review by GENART is assigned to Martin Thomson |
2014-05-22
|
01 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Klaas Wierenga |
2014-05-22
|
01 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Klaas Wierenga |
2014-05-20
|
01 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2014-05-20
|
01 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (DNS Root Name Service Protocol … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (DNS Root Name Service Protocol and Deployment Requirements) to Best Current Practice The IESG has received a request from the Internet Architecture Board (iab) to consider the following document: - 'DNS Root Name Service Protocol and Deployment Requirements' as Best Current Practice 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 2014-06-20. 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 Root Name service is a critical part of the Internet architecture. The protocol and deployment requirements expected to be implemented for the DNS root name service are defined in this document. Operational requirements are out of scope. The file can be obtained via http://datatracker.ietf.org/doc/draft-iab-2870bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-iab-2870bis/ballot/ No IPR declarations have been submitted directly on this I-D. |
2014-05-20
|
01 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2014-05-20
|
01 | Jari Arkko | Last call was requested |
2014-05-20
|
01 | Jari Arkko | Ballot approval text was generated |
2014-05-20
|
01 | Jari Arkko | Ballot writeup was generated |
2014-05-20
|
01 | Jari Arkko | IESG state changed to Last Call Requested from AD Evaluation |
2014-05-20
|
01 | Jari Arkko | Last call announcement was changed |
2014-05-20
|
01 | Jari Arkko | Last call announcement was generated |
2014-05-20
|
01 | Jari Arkko | Last call announcement was generated |
2014-05-20
|
01 | Jari Arkko | IESG state changed to AD Evaluation from Publication Requested |
2014-05-09
|
01 | Jari Arkko | IESG process started in state Publication Requested |
2014-05-09
|
01 | (System) | Earlier history may be found in the Comment Log for /doc/draft-blanchet-iab-2870bis/ |
2014-05-09
|
01 | Jari Arkko | Intended Status changed to Best Current Practice from None |
2014-02-11
|
01 | Marc Blanchet | New version available: draft-iab-2870bis-01.txt |
2013-07-10
|
00 | Cindy Morgan | Stream changed to IETF from IAB |
2013-07-10
|
00 | Marc Blanchet | New version available: draft-iab-2870bis-00.txt |