Skip to main content

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