Subject: [tcpm] Fwd: Experimental RFC to be: draft-simpson-tcpct-02.txt

From: Lars Eggert <[email-masked]>
Date: Tue, 27 Apr 2010 09:42:53 +0100

FYI, since this ID has been discussed on this list.

Begin forwarded message:

> From: The IESG <[email-masked]>
> Date: April 26, 2010 20:14:47 GMT+01:00
> To: RFC Editor <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, The IESG <[email-masked]>, "[email-masked]" <[email-masked]>
> 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 
> (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.
>