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

Eliot Lear <lear@cisco.com> Mon, 31 January 2011 16:24 UTC

Return-Path: <lear@cisco.com>
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 6628A3A6827; Mon, 31 Jan 2011 08:24:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.22
X-Spam-Level:
X-Spam-Status: No, score=-110.22 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 aym9kKrf6bTe; Mon, 31 Jan 2011 08:24:41 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id E29003A67B6; Mon, 31 Jan 2011 08:24:40 -0800 (PST)
Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 31 Jan 2011 16:27:55 +0000
Received: from dhcp-10-61-100-10.cisco.com (dhcp-10-61-100-10.cisco.com [10.61.100.10]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p0VGRsC0015449; Mon, 31 Jan 2011 16:27:54 GMT
Message-ID: <4D46E2FF.7010203@cisco.com>
Date: Mon, 31 Jan 2011 17:27:43 +0100
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: Cullen Jennings <fluffy@cisco.com>
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> <ECA80A72-4E72-44D2-B40E-C90D7197E8C5@nokia.com> <4D421795.70505@isi.edu> <EFADE5D0-BB33-4418-B743-DFEC11B12740@cisco.com> <4D44F85D.5030407@isi.edu> <4D457FD9.5030905@vpnc.org> <B1E38EDF-E78E-47E2-B9A9-D7320A908217@nokia.com> <4D46CC62.1040006@vpnc.org> <3EEDEA1C-C34B-4F39-8E6E-AEDE50C1E504@nokia.com> <4D46D1D3.10701@vpnc.org> <F2152494-8C79-4A0F-951F-B3DB1D274A61@cisco.com>
In-Reply-To: <F2152494-8C79-4A0F-951F-B3DB1D274A61@cisco.com>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: IESG IESG <iesg@ietf.org>, IETF discussion list <ietf@ietf.org>, Paul Hoffman <paul.hoffman@vpnc.org>, tsvwg@ietf.org
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: Mon, 31 Jan 2011 16:24:42 -0000

On 1/31/11 5:13 PM, Cullen Jennings wrote:
> Hmm ... I don't agree that solves the issue. 
>
> Well lets say the request was coming from 3GPP for a protocol they designed - why should IANA be able to tell them no but IETF yes. 

Who, ultimately, is the steward of this precious resource?  If it is not
the IANA and it is not the IETF, then who?  To say that it is everyone's
responsibility is to avoid responsibility entirely.  Who gets to say
which standards organizations are stewards and which are not?

> I think the policy issue here is fairly clear. We do not have consensus that in all cases that one should not have a second port for security (I'm basing this assertion on Magnus read of WG consensus and my read of IETF LC consensus). Therefore that should not be a ground for the expert reviewer (or IANA) to reject the registration. The document needs to be updated to make that clear or it does not reflect consensus. If the authors of the draft want to propose text for conditions when it would be ok to reject a second port for security purposes and see if they can get consensus for that text, that seems perfectly reasonable. 

This is a VERY VERY dangerous approach you propose, Cullen.  It is akin
to saying, "you can think about security later, because we'll have to
give you a port for it later."  We don't want to be saying that.