The edns-tcp-keepalive EDNS0 Option
RFC 7828
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2018-12-20
|
06 | (System) | Received changes through RFC Editor sync (changed abstract to 'DNS messages between clients and servers may be received over either UDP or TCP. UDP transport … Received changes through RFC Editor sync (changed abstract to 'DNS messages between clients and servers may be received over either UDP or TCP. UDP transport involves keeping less state on a busy server, but can cause truncation and retries over TCP. Additionally, UDP can be exploited for reflection attacks. Using TCP would reduce retransmits and amplification. However, clients commonly use TCP only for retries and servers typically use idle timeouts on the order of seconds. This document defines an EDNS0 option ("edns-tcp-keepalive") that allows DNS servers to signal a variable idle timeout. This signalling encourages the use of long-lived TCP connections by allowing the state associated with TCP transport to be managed effectively with minimal impact on the DNS transaction time.') |
|
2016-04-06
|
06 | (System) | RFC published |
|
2016-04-06
|
06 | (System) | RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc7828">AUTH48-DONE</a> from AUTH48 |
|
2016-04-05
|
06 | (System) | RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc7828">AUTH48</a> from EDIT |
|
2016-04-05
|
06 | (System) | RFC Editor state changed to EDIT from MISSREF |
|
2016-03-25
|
06 | (System) | RFC Editor state changed to MISSREF from AUTH48 |
|
2016-03-21
|
06 | (System) | RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc7828">AUTH48</a> from RFC-EDITOR |
|
2016-03-14
|
06 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
|
2016-03-01
|
06 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
|
2016-02-29
|
06 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
|
2016-02-29
|
06 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
|
2016-02-25
|
06 | (System) | IANA Action state changed to In Progress |
|
2016-02-25
|
06 | (System) | RFC Editor state changed to EDIT |
|
2016-02-25
|
06 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
|
2016-02-25
|
06 | (System) | Announcement was received by RFC Editor |
|
2016-02-24
|
06 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
|
2016-02-24
|
06 | Cindy Morgan | IESG has approved the document |
|
2016-02-24
|
06 | Cindy Morgan | Closed "Approve" ballot |
|
2016-02-24
|
06 | Cindy Morgan | Ballot approval text was generated |
|
2016-02-24
|
06 | Cindy Morgan | Ballot writeup was changed |
|
2016-02-24
|
06 | Joel Jaeggli | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
|
2016-02-22
|
06 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
|
2016-02-22
|
06 | Sara Dickinson | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
|
2016-02-22
|
06 | Sara Dickinson | New version available: draft-ietf-dnsop-edns-tcp-keepalive-06.txt |
|
2016-01-14
|
05 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'No Response' |
|
2016-01-07
|
05 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation |
|
2016-01-07
|
05 | Stephen Farrell | [Ballot comment] This used be a discuss but since the answer is probably that no change is needed, Joel said he'd figure it out with … [Ballot comment] This used be a discuss but since the answer is probably that no change is needed, Joel said he'd figure it out with the WG. Before I ballot yes on this I have a question to ask. Most likely the answer will be the obvious one and we'll be done, but I want to check and if the answer is not the obvious one then holding the discuss as we fix stuff would be correct I think. The question: how does this option play with DNS over DTLS? [1] The reason I ask is that there may be a need in that case for some similar option (or a TLS extension maybe) though for the DTLS session lifetime and not a TCP session lifetime. At present you are saying that this option is not it. And that's a fine answer but you could also have said that this could also be used for DTLS session lifetime handling. And that last might make sense for operational reasons (not sure really, but could be). [1] https://tools.ietf.org/html/draft-ietf-dprive-dnsodtls-03 old comments - intro: "However, TCP transport as currently deployed has expensive setup overhead." That seems a bit wrong as the 3-way h/s is an inherent part of TCP and isn't really specific to DNS with TCP trasnport not is it a deployment issue. I'd suggest just delete the sentence and merge the remaining part of tha para with the next. - 3.3.2: What's the last sentence of this section about? A case where a TCP session is handed over? Might be no harm saying why (via a reference to anything would be fine) |
|
2016-01-07
|
05 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to Yes from Discuss |
|
2016-01-07
|
05 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
|
2016-01-07
|
05 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
|
2016-01-07
|
05 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
|
2016-01-06
|
05 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
|
2016-01-06
|
05 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
|
2016-01-06
|
05 | Stephen Farrell | [Ballot discuss] Before I ballot yes on this I have a question to ask. Most likely the answer will be the obvious one and we'll … [Ballot discuss] Before I ballot yes on this I have a question to ask. Most likely the answer will be the obvious one and we'll be done, but I want to check and if the answer is not the obvious one then holding the discuss as we fix stuff would be correct I think. The question: how does this option play with DNS over DTLS? [1] The reason I ask is that there may be a need in that case for some similar option (or a TLS extension maybe) though for the DTLS session lifetime and not a TCP session lifetime. At present you are saying that this option is not it. And that's a fine answer but you could also have said that this could also be used for DTLS session lifetime handling. And that last might make sense for operational reasons (not sure really, but could be). [1] https://tools.ietf.org/html/draft-ietf-dprive-dnsodtls-03 |
|
2016-01-06
|
05 | Stephen Farrell | [Ballot comment] - intro: "However, TCP transport as currently deployed has expensive setup overhead." That seems a bit wrong as the 3-way h/s is an … [Ballot comment] - intro: "However, TCP transport as currently deployed has expensive setup overhead." That seems a bit wrong as the 3-way h/s is an inherent part of TCP and isn't really specific to DNS with TCP trasnport not is it a deployment issue. I'd suggest just delete the sentence and merge the remaining part of tha para with the next. - 3.3.2: What's the last sentence of this section about? A case where a TCP session is handed over? Might be no harm saying why (via a reference to anything would be fine) |
|
2016-01-06
|
05 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
|
2016-01-06
|
05 | Ben Campbell | [Ballot comment] - 3.2.2: I think it would be helpful to give some more guidance about the “timeout” period. That is, when does it start, … [Ballot comment] - 3.2.2: I think it would be helpful to give some more guidance about the “timeout” period. That is, when does it start, does it reset when a new query is sent, etc? This is somewhat implied by the term “idle”, but it would be better to be explicit. -3.3.2: I understand from later in the draft that the OPT RR in a query does not necessarily need to have include edns-tcp-keepalive for the server to include it in the response. A careless reader might easily miss that distinction. It would be helpful to emphasize it here. === Editorial=== - Abstract: The abstract is rather long. The first paragraph might be better left to the introduction section. - 1: The introduction sort of buries the lede. The idea that clients and servers need to manage idle connections is not mentioned until paragraphs 8 and 9. That's the whole point of the document. |
|
2016-01-06
|
05 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
|
2016-01-06
|
05 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
|
2016-01-06
|
05 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
|
2016-01-06
|
05 | Sara Dickinson | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
|
2016-01-06
|
05 | Sara Dickinson | New version available: draft-ietf-dnsop-edns-tcp-keepalive-05.txt |
|
2016-01-05
|
04 | Barry Leiba | [Ballot comment] -- Section 1 -- Long-lived TCP connections can result in lower request latency than the case where UDP transport is … [Ballot comment] -- Section 1 -- Long-lived TCP connections can result in lower request latency than the case where UDP transport is used and truncated responses are received, since clients that have fallen back to TCP transport in response to a truncated response typically only uses the TCP session for a single (request, response) pair, continuing with UDP transport for subsequent queries. This is a really long, awkward sentence, and it appears to have an error in it that makes it unparseable. May I suggest a replacement?: NEW Responses over UDP might be truncated, and when that happens many clients will retry the query over TCP. Such retries typically use the TCP session only for one request/response pair, and the clients then revert back to UDP for subsequent queries. Using long-lived TCP connections in the first place avoids these situations and can result in lower request latency. END In general, calling the retry over TCP "fallback" is misleading, and I suggest not doing that. The term "fallback" generally refers to a situation where an optimization fails, and you "fall back" to the non-optimized method. That's not the case here; here, UDP is the normal method, and you retry over TCP when the response is too big to work with UDP. The use of "fall back to UDP" in Section 3.4 is an apt use of "fall back", in that sense, as is the use of "fallback" in Section 3.5. But the use in the abstract and at the top of page 4 are not. I suggest "clients commonly use TCP only for retries" in the abstract, and "received over UDP with retries over TCP" on page 4. |
|
2016-01-05
|
04 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
|
2016-01-05
|
04 | Martin Stiemerling | [Ballot comment] Two comments for your considerations: 1) Section 3.3.2 is talking about this "It is reasonable for this value to change [...] or in … [Ballot comment] Two comments for your considerations: 1) Section 3.3.2 is talking about this "It is reasonable for this value to change [...] or in consideration of intermediary behaviour (for example TCP middleboxes or NATs)." Can you please clarify how the DNS client or server is able to inspect the behaviour of intermediated devices and adapt its behaviour accordingly? This smells a bit like a half-baked idea which does not belong into a standards track document. 2) Section 3.6. talks about using Multipath TCP. Please note that Multipath TCP is still experimental and has known security issues, which are dealt with right now. Further, I would recommend to move this to a non-normative appendix, noting that this is a potential future way forward, but that is has not yet been tested and deployed. This would also honor that RFC 6824 is listed in the informative part of the references. |
|
2016-01-05
|
04 | Martin Stiemerling | Ballot comment text updated for Martin Stiemerling |
|
2016-01-05
|
04 | Martin Stiemerling | [Ballot comment] Two comments for your considerations: 1) Section 3.3.2 is talking about this "It is reasonable for this value to change [...] or in … [Ballot comment] Two comments for your considerations: 1) Section 3.3.2 is talking about this "It is reasonable for this value to change [...] or in consideration of intermediary behaviour (for example TCP middleboxes or NATs)." Can you please clarify how the DNS client or server is able to inspect the behaviour of intermediated devices and adapt its behaviour accordingly? This smells a bit like a half-baked idea which does not belong into a standards track document. 2) Section 3.6. talks about using Multipath TCP. Please note that Multipath TCP is still experimental and has known security issues, which are dealt with right now. Further, I would recommend to move this to a non-normative appendix, noting that this is a potential future way forward, but that is has not yet been tested and deployed. This would also honor that RFC 6824 is listed in the informative part of the references. |
|
2016-01-05
|
04 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
|
2016-01-05
|
04 | Brian Haberman | [Ballot comment] Thanks for the quick resolution to my DISCUSS point. The proposed change is recorded below for posterity. OLD: It SHOULD honour the timeout … [Ballot comment] Thanks for the quick resolution to my DISCUSS point. The proposed change is recorded below for posterity. OLD: It SHOULD honour the timeout and initiate close of the connection before the timeout expires. NEW: It SHOULD honour the timeout received in that response (overriding any previous timeout) and initiate close of the connection before the timeout expires. |
|
2016-01-05
|
04 | Brian Haberman | [Ballot Position Update] Position for Brian Haberman has been changed to No Objection from Discuss |
|
2016-01-04
|
04 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
|
2016-01-04
|
04 | Brian Haberman | [Ballot discuss] I support the publication of this document, but I have a point I want to discuss to help with the clarity of the … [Ballot discuss] I support the publication of this document, but I have a point I want to discuss to help with the clarity of the spec. Section 3.2.1 says that clients send this option with the first query sent on a TCP connection and Section 3.2.2 says it should honor the timeout provided by the server and close the socket when appropriate. What is not discussed is how the client should manage the timer with respect to the reception of multiple query responses that may, or may not, include edns-tcp-keepalive option. Section 3.3.2 says the server MAY send the option, so it is up to the server to decide when to include the option and the corresponding timeout value. Should the client's timer simply reflect the value sent in the latest response? The smallest remaining time? I think a few sentences on client timer management would be beneficial. |
|
2016-01-04
|
04 | Brian Haberman | [Ballot Position Update] New position, Discuss, has been recorded for Brian Haberman |
|
2015-12-31
|
04 | Brian Carpenter | Request for Telechat review by GENART Completed: Ready with Issues. Reviewer: Brian Carpenter. |
|
2015-12-31
|
04 | Jean Mahoney | Request for Telechat review by GENART is assigned to Brian Carpenter |
|
2015-12-31
|
04 | Jean Mahoney | Request for Telechat review by GENART is assigned to Brian Carpenter |
|
2015-12-29
|
04 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
|
2015-12-20
|
04 | Joel Jaeggli | Ballot has been issued |
|
2015-12-20
|
04 | Joel Jaeggli | [Ballot Position Update] New position, Yes, has been recorded for Joel Jaeggli |
|
2015-12-20
|
04 | Joel Jaeggli | Created "Approve" ballot |
|
2015-12-20
|
04 | Joel Jaeggli | Ballot writeup was changed |
|
2015-12-20
|
04 | Joel Jaeggli | 1. Summary Document Shepherd: Tim Wicinski Area Director: Joel Jaggeli Document Type: Proposed Standard This document defines an EDNS0 option ("edns-tcp-keepalive") … 1. Summary Document Shepherd: Tim Wicinski Area Director: Joel Jaggeli Document Type: Proposed Standard This document defines an EDNS0 option ("edns-tcp-keepalive") that allows DNS servers to signal a variable idle timeout. This signalling facilitates a better balance of UDP and TCP transport between individual clients and servers, reducing the impact of problems associated with UDP transport and allowing the state associated with TCP transport to be managed effectively with minimal impact on the DNS transaction time. 2. Review and Consensus This document originally was adopted but had a few points of controversy over the initial size of the keep alive option. Another draft was written at one with a different solution. The authors ended up collaborating on this document and the final solution with input from several working group members. 3. Intellectual Property There is no IPR claims made, and the authors have no direct, personal knowledge of any IPR. 4. Other Points - Downward References There are no downward references - IANA Considerations: Registry: DNS EDNS0 Option Codes (OPT) IANA is directed to assign an EDNS0 option code for edns-tcp-keepalive. IANA has been contacted and awaiting response. The Expert Review for the EDNS Option Code has approved this. 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 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? X- If this is a "bis" document, have all of the errata been considered? |
|
2015-12-20
|
04 | Joel Jaeggli | Placed on agenda for telechat - 2016-01-07 |
|
2015-12-20
|
04 | Joel Jaeggli | IESG state changed to IESG Evaluation from Waiting for Writeup |
|
2015-11-30
|
04 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
|
2015-11-29
|
04 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Jon Mitchell. |
|
2015-11-25
|
04 | Sabrina Tanamal | (Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-dnsop-edns-tcp-keepalive-04.txt. If any part of this review is inaccurate, please let us know. Updated … (Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-dnsop-edns-tcp-keepalive-04.txt. If any part of this review is inaccurate, please let us know. Updated review, to account for the fact that this assignment has already been made: IANA understands that, upon approval of this document, there is a single action which IANA must complete. However, there may still be an action for the authors. QUESTION: should the status for this registration read "Standard" rather than "Optional"? If so, the IANA Considerations section should be edited to tell IANA to update it. In the DNS EDNS0 Option Codes (OPT) subregistry of the Domain Name System (DNS) Parameters registry located at: https://www.iana.org/assignments/dns-parameters/ IANA will update the reference for the following registration to point to the IESG-approved version of this document: Value: [ TBD-at-Registration ] Name: edns-tcp-keepalive Status: Optional Reference: [ RFC-to-be ] IANA understands that this action is the only one 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 |
|
2015-11-25
|
04 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
|
2015-11-25
|
04 | Sabrina Tanamal | (Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-dnsop-edns-tcp-keepalive-04.txt. If any part of this review is inaccurate, please let us know. IANA … (Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-dnsop-edns-tcp-keepalive-04.txt. If any part of this review is inaccurate, please let us know. IANA understands that, upon approval of this document, there is a single action which IANA must complete. First, in the DNS EDNS0 Option Codes (OPT) subregistry of the Domain Name System (DNS) Parameters registry located at: https://www.iana.org/assignments/dns-parameters/ a new option code is to be registered as follows: Value: [ TBD-at-Registration ] Name: edns-tcp-keepalive Status: Optional Reference: [ RFC-to-be ] As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) 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. IANA understands that this action is the only one 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. Thanks you, Sabrina Tanamal IANA Specialist ICANN |
|
2015-11-23
|
04 | Tim Wicinski | Changed consensus to Yes from Unknown |
|
2015-11-23
|
04 | Brian Carpenter | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Brian Carpenter. |
|
2015-11-19
|
04 | Jean Mahoney | Request for Last Call review by GENART is assigned to Brian Carpenter |
|
2015-11-19
|
04 | Jean Mahoney | Request for Last Call review by GENART is assigned to Brian Carpenter |
|
2015-11-19
|
04 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Steve Hanna |
|
2015-11-19
|
04 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Steve Hanna |
|
2015-11-16
|
04 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jon Mitchell |
|
2015-11-16
|
04 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jon Mitchell |
|
2015-11-16
|
04 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
|
2015-11-16
|
04 | Amy Vezza | The following Last Call announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org> To: "IETF-Announce" <ietf-announce@ietf.org> CC: tjw.ietf@gmail.com, draft-ietf-dnsop-edns-tcp-keepalive@ietf.org, joelja@gmail.com, … The following Last Call announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org> To: "IETF-Announce" <ietf-announce@ietf.org> CC: tjw.ietf@gmail.com, draft-ietf-dnsop-edns-tcp-keepalive@ietf.org, joelja@gmail.com, dnsop-chairs@ietf.org, dnsop@ietf.org Reply-To: ietf@ietf.org Sender: <iesg-secretary@ietf.org> Subject: Last Call: <draft-ietf-dnsop-edns-tcp-keepalive-04.txt> (The edns-tcp-keepalive EDNS0 Option) to Proposed Standard The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'The edns-tcp-keepalive EDNS0 Option' <draft-ietf-dnsop-edns-tcp-keepalive-04.txt> 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 2015-11-30. 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 DNS messages between clients and servers may be received over either UDP or TCP. UDP transport involves keeping less state on a busy server, but can cause truncation and retries over TCP. Additionally, UDP can be exploited for reflection attacks. Using TCP would reduce retransmits and amplification. However, clients commonly use TCP only for fallback and servers typically use idle timeouts on the order of seconds. This document defines an EDNS0 option ("edns-tcp-keepalive") that allows DNS servers to signal a variable idle timeout. This signalling facilitates a better balance of UDP and TCP transport between individual clients and servers, reducing the impact of problems associated with UDP transport and allowing the state associated with TCP transport to be managed effectively with minimal impact on the DNS transaction time. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-tcp-keepalive/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-tcp-keepalive/ballot/ No IPR declarations have been submitted directly on this I-D. |
|
2015-11-16
|
04 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
|
2015-11-16
|
04 | Amy Vezza | Last call announcement was changed |
|
2015-11-15
|
04 | Joel Jaeggli | Last call was requested |
|
2015-11-15
|
04 | Joel Jaeggli | Last call announcement was generated |
|
2015-11-15
|
04 | Joel Jaeggli | Ballot approval text was generated |
|
2015-11-15
|
04 | Joel Jaeggli | Ballot writeup was generated |
|
2015-11-15
|
04 | Joel Jaeggli | IESG state changed to Last Call Requested from AD Evaluation |
|
2015-11-05
|
04 | Joel Jaeggli | IESG state changed to AD Evaluation from Publication Requested |
|
2015-11-03
|
04 | Tim Wicinski | 1. Summary Document Shepherd: Tim Wicinski Area Director: Joel Jaggeli Document Type: Proposed Standard This document defines an EDNS0 option ("edns-tcp-keepalive") … 1. Summary Document Shepherd: Tim Wicinski Area Director: Joel Jaggeli Document Type: Proposed Standard This document defines an EDNS0 option ("edns-tcp-keepalive") that allows DNS servers to signal a variable idle timeout. This signalling facilitates a better balance of UDP and TCP transport between individual clients and servers, reducing the impact of problems associated with UDP transport and allowing the state associated with TCP transport to be managed effectively with minimal impact on the DNS transaction time. 2. Review and Consensus This document originally was adopted but had a few points of controversy over the initial size of the keep alive option. Another draft was written at one with a different solution. The authors ended up collaborating on this document and the final solution with input from several working group members. 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. 3. Intellectual Property There is no IPR claims made, and the authors have no direct, personal knowledge of any IPR. 4. Other Points - Downward References There are no downward references - IANA Considerations: Registry: DNS EDNS0 Option Codes (OPT) IANA is directed to assign an EDNS0 option code for edns-tcp-keepalive. IANA has been contacted and awaiting response. The Expert Review for the EDNS Option Code has approved this. 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 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? X- If this is a "bis" document, have all of the errata been considered? |
|
2015-11-01
|
04 | Tim Wicinski | 1. Summary Document Shepherd: Tim Wicinski Area Director: Joel Jaggeli Document Type: Proposed Standard This document defines an EDNS0 option ("edns-tcp-keepalive") … 1. Summary Document Shepherd: Tim Wicinski Area Director: Joel Jaggeli Document Type: Proposed Standard This document defines an EDNS0 option ("edns-tcp-keepalive") that allows DNS servers to signal a variable idle timeout. This signalling facilitates a better balance of UDP and TCP transport between individual clients and servers, reducing the impact of problems associated with UDP transport and allowing the state associated with TCP transport to be managed effectively with minimal impact on the DNS transaction time. 2. Review and Consensus This document originally was adopted but had a few points of controversy over the initial size of the keep alive option. Another draft was written at one with a different solution. The authors ended up collaborating on this document and the final solution with input from several working group members. 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. 3. Intellectual Property There is no IPR claims made, and the authors have no direct, personal knowledge of any IPR. 4. Other Points - Downward References There are no downward references - IANA Considerations: Registry: DNS EDNS0 Option Codes (OPT) IANA is directed to assign an EDNS0 option code for edns-tcp-keepalive 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 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? X- If this is a "bis" document, have all of the errata been considered? |
|
2015-11-01
|
04 | Tim Wicinski | Responsible AD changed to Joel Jaeggli |
|
2015-11-01
|
04 | Tim Wicinski | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
|
2015-11-01
|
04 | Tim Wicinski | IESG state changed to Publication Requested |
|
2015-11-01
|
04 | Tim Wicinski | IESG process started in state Publication Requested |
|
2015-11-01
|
04 | Tim Wicinski | Changed document writeup |
|
2015-11-01
|
04 | Tim Wicinski | Intended Status changed to Proposed Standard from Informational |
|
2015-10-27
|
04 | Tim Wicinski | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
|
2015-10-21
|
04 | Naveen Khan | New revision available |
|
2015-10-05
|
03 | Tim Wicinski | IETF WG state changed to In WG Last Call from WG Document |
|
2015-09-30
|
03 | Sara Dickinson | New version available: draft-ietf-dnsop-edns-tcp-keepalive-03.txt |
|
2015-07-03
|
02 | Ray Bellis | New version available: draft-ietf-dnsop-edns-tcp-keepalive-02.txt |
|
2014-10-27
|
01 | Paul Wouters | New version available: draft-ietf-dnsop-edns-tcp-keepalive-01.txt |
|
2014-07-27
|
00 | Tim Wicinski | Document shepherd changed to Tim Wicinski |
|
2014-05-10
|
00 | Tim Wicinski | Intended Status changed to Informational from None |
|
2014-04-12
|
00 | Tim Wicinski | This document now replaces draft-wouters-edns-tcp-keepalive instead of None |
|
2014-04-11
|
00 | Paul Wouters | New version available: draft-ietf-dnsop-edns-tcp-keepalive-00.txt |