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 (https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=19765&rfc_flag=0) 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: http://www.ietf.org/internet-drafts/draft-simpson-tcpct-02.txt The process for such documents is described at http://www.rfc-editor.org/indsubs.html. 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 deployments. (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. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
