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

Lars Eggert <lars.eggert@nokia.com> Tue, 27 April 2010 08:43 UTC

Return-Path: <lars.eggert@nokia.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F9BF3A696D for <tcpm@core3.amsl.com>; Tue, 27 Apr 2010 01:43:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.446
X-Spam-Level:
X-Spam-Status: No, score=-6.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSq3qhfL8RWc for <tcpm@core3.amsl.com>; Tue, 27 Apr 2010 01:43:31 -0700 (PDT)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 58A5E3A6969 for <tcpm@ietf.org>; Tue, 27 Apr 2010 01:43:28 -0700 (PDT)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o3R8gcuu024394 for <tcpm@ietf.org>; Tue, 27 Apr 2010 03:43:15 -0500
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Apr 2010 11:43:05 +0300
Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Apr 2010 11:43:04 +0300
Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o3R8h42q019760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <tcpm@ietf.org>; Tue, 27 Apr 2010 11:43:04 +0300
From: Lars Eggert <lars.eggert@nokia.com>
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.96 at fit.nokia.com
Content-Type: multipart/signed; boundary=Apple-Mail-49--154686176; protocol="application/pkcs7-signature"; micalg=sha1
Date: Tue, 27 Apr 2010 09:42:53 +0100
References: <20100426191447.55E2C28C0F4@core3.amsl.com>
To: "tcpm@ietf.org Extensions" <tcpm@ietf.org>
Message-Id: <4D03DBD4-2A0D-4820-AEE1-154B79499BE4@nokia.com>
Mime-Version: 1.0 (Apple Message framework v1078)
X-Mailer: Apple Mail (2.1078)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Tue, 27 Apr 2010 11:42:54 +0300 (EEST)
X-OriginalArrivalTime: 27 Apr 2010 08:43:04.0600 (UTC) FILETIME=[A706E980:01CAE5E5]
X-Nokia-AV: Clean
Subject: [tcpm] Fwd: Experimental RFC to be: draft-simpson-tcpct-02.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Apr 2010 08:43:32 -0000

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

Begin forwarded message:

> From: The IESG <iesg-secretary@ietf.org>
> Date: April 26, 2010 20:14:47 GMT+01:00
> To: RFC Editor <rfc-editor@rfc-editor.org>
> Cc: "iana@iana.org" <iana@iana.org>rg>, The IESG <iesg@ietf.org>rg>, "ietf-announce@ietf.org" <ietf-announce@ietf.org>
> 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.
>