TCP Cookie Transactions (TCPCT)
RFC 6013

Approval announcement
Draft of message to be sent after approval:

From: The IESG <>
To: RFC Editor <>
Cc: The IESG <>, <>,
Subject: Re: Experimental RFC to be: draft-simpson-tcpct-02.txt

The IESG has no problem with the publication of 'TCP Cookie Transactions (TCPCT)' <draft-simpson-tcpct-02.txt> as an Experimental RFC.

The IESG would also like the IRSG or RFC-Editor to review the comments in 
the datatracker 
related to this document and determine whether or not they merit 
incorporation into the document. Comments may exist in both the ballot 
and the comment log. 

The IESG contact person is Lars Eggert.

A URL of this Internet-Draft is:

The process for such documents is described at

Thank you,

The IESG Secretary

RFC Editor and IANA Note

TCP Option numbers are assigned following an "IESG Approval" or
"Standards Action" process [RFC2780]. The ID draft-simpson-tcpct is a
technical description to support a request to the IESG to approve the
assignment of two TCP Option numbers for the "TCP Cookie Option" and the
"TCP Timestamps Extended Option". It has also been submitted to the RFC
Editor for publication on the Independent Stream.

IESG members and external TCP and security experts reviewed
draft-simpson-tcpct for conflicts with the IETF standards process or work
done in the IETF community [RFC5742], and to determine whether an IANA
assignment of the two requested TCP Option numbers should be approved by
the IESG. [RFC5226] states the following conditions for an IANA assignment
by IESG Approval:

>   IESG Approval is not intended to be used often or as a
>   "common case"; indeed, it has seldom been used in practice
>   during the period RFC 2434 was in effect.  Rather, it is
>   intended to be available in conjunction with other policies
>   as a fall-back mechanism in the case where one of the other
>   allowable approval mechanisms cannot be employed in a timely
>   fashion or for some other compelling reason.  IESG Approval
>   is not intended to circumvent the public review processes
>   implied by other policies that could have been employed for
>   a particular assignment.  IESG Approval would be
>   appropriate, however, in cases where expediency is desired
>   and there is strong consensus for making the assignment
>   (e.g., WG consensus).
>   The following guidelines are suggested for any evaluation
>   under IESG Approval:
>   - The IESG can (and should) reject a request if another path
>     for registration is available that is more appropriate and
>     there is no compelling reason to use that path.
>   - Before approving a request, the community should be
>     consulted, via a "call for comments" that provides as much
>     information as is reasonably possible about the request.

Based on this review, the IESG has decided that at this time it will not
approve the request for the assignment of two TCP Option numbers for the
mechanisms described in draft-simpson-tcpct. The IESG notes that a more
appropriate path for the registration is available under [RFC2780],
namely, publication of a Standards Track RFC, typically produced by an
IETF working group ("Standards Action"). The IESG also notes that no
strong consensus exists in the IETF community that expediency is desired
to assign these TCP Option numbers via IESG Approval.

The IESG recommends that the authors of draft-simpson-tcpct submit their
draft as a proposed work item for the TCP Maintenance and Minor Extensions
(TCPM) working group, instead of pursuing publication on the Independent
Stream, with the intent of producing a Standards Track document.

If the authors instead decide to pursue publication on the Independent
Stream, the IESG wishes to inform the RFC Editor that two conditions would
need to be met:

(1) The (unnumbered) "IANA Considerations" section on page 26 is removed
by the RFC Editor prior to publication, because no IANA assignment of TCP
Option numbers has occurred. In place of that section, the IESG suggests
informing readers of the document that two TCP Option numbers are already
reserved for general experimental use under the rules laid out in
[RFC4727] and [RFC3692], Section 1. Such values reserved for experimental
use are never to be made permanent; permanent assignments should be
obtained through standard processes. Experimental numbers are intended for
experimentation and testing and are not intended for wide or general

(2) The text in Section 3 is changed such that it no longer refers to
unassigned TCP Option number values. Instead, the IESG suggests referring
readers to the modified IANA Considerations section discussing the
availability of TCP Option numbers for general experimentation, which can
be used for this experiment.

If the authors decide to pursue publication on the Independent Stream and
the two changes above are made to the document, the IESG wishes to inform
the RFC Editor that following Section 3 of [RFC5742]:

   2. The IESG has concluded that this work is related to IETF work done
      in WG TCPM, but this relationship does not prevent publishing.

publication on the Independent Stream may occur.