Re: Last Call: <draft-ietf-tsvwg-iana-ports-09.txt> (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

Paul Hoffman <paul.hoffman@vpnc.org> Thu, 27 January 2011 16:38 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42C473A690E for <ietf@core3.amsl.com>; Thu, 27 Jan 2011 08:38:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.742
X-Spam-Level:
X-Spam-Status: No, score=-101.742 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100]
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 Mvf2a255w6O7 for <ietf@core3.amsl.com>; Thu, 27 Jan 2011 08:38:15 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 801773A690F for <ietf@ietf.org>; Thu, 27 Jan 2011 08:38:15 -0800 (PST)
Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0RGfIw8063145 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for <ietf@ietf.org>; Thu, 27 Jan 2011 09:41:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Message-ID: <4D41A02E.7070701@vpnc.org>
Date: Thu, 27 Jan 2011 08:41:18 -0800
From: Paul Hoffman <paul.hoffman@vpnc.org>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: Last Call: <draft-ietf-tsvwg-iana-ports-09.txt> (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP
References: <20110118212603.5733.34489.idtracker@localhost> <B88A8A82-9C4A-40AC-89AF-F177260760F7@cisco.com> <37255E32-37F1-4907-8A5A-6AB7B590562F@ietf.org>
In-Reply-To: <37255E32-37F1-4907-8A5A-6AB7B590562F@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jan 2011 16:38:16 -0000

On 1/27/11 8:12 AM, IETF Chair wrote:
> Originally, two ports were assigned for plain and over-TLS, which for HTTP mapped to two different URL schemes: http and https.
>
> Many people thought that this was a waste of a port, and the STARTTLS approach was developed.  You say that it does not work in some cases, and you seem to be suggesting that we go back to the original way.
>
> Maybe it works in some cases and not others.  Can we say which is which?

In a word: no. We have very little operational experience, and where we 
do, it gives conflicting results. Some mail client developers say that 
POP and IMAP STARTTLS works fine, some say that it is unreliable and so 
they just use the alternate ports.

Note that Cullen's example for where it almost certainly would not work 
is for non-stream UDP. Making UDP developers have to come up with a 
stream-like capability to do a STARTTLS-style single port solution 
defeats the purpose of using UDP. The benefit of "we saved another 
port!" over "we forced someone to make UDP more like TCP!" seems like a 
false one.