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

Lars Eggert <lars.eggert@nokia.com> Mon, 31 January 2011 15:03 UTC

Return-Path: <lars.eggert@nokia.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 86CFE3A6C0C; Mon, 31 Jan 2011 07:03:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.768
X-Spam-Level:
X-Spam-Status: No, score=-103.768 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 J3HHYGNYih1W; Mon, 31 Jan 2011 07:03:20 -0800 (PST)
Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 684753A6C07; Mon, 31 Jan 2011 07:03:20 -0800 (PST)
Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0VF6VWf028591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Jan 2011 17:06:33 +0200
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
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.96.5 at fit.nokia.com
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: multipart/signed; boundary="Apple-Mail-18-351603736"; protocol="application/pkcs7-signature"; micalg="sha1"
From: Lars Eggert <lars.eggert@nokia.com>
In-Reply-To: <4D46CC62.1040006@vpnc.org>
Date: Mon, 31 Jan 2011 17:06:23 +0200
Message-Id: <3EEDEA1C-C34B-4F39-8E6E-AEDE50C1E504@nokia.com>
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>
To: Paul Hoffman <paul.hoffman@vpnc.org>
X-Mailer: Apple Mail (2.1082)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Mon, 31 Jan 2011 17:06:28 +0200 (EET)
X-Nokia-AV: Clean
Cc: Cullen Jennings <fluffy@cisco.com>, tsvwg@ietf.org, IETF discussion list <ietf@ietf.org>, IESG IESG <iesg@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 15:03:21 -0000

Hi,

On 2011-1-31, at 16:51, Paul Hoffman wrote:
> On 1/31/11 12:23 AM, Lars Eggert wrote:
>> On 2011-1-30, at 17:12, Paul Hoffman wrote:
>>> The above emphatic statements means that IANA can reject a request for an IETF-approved protocol that needs two ports without recourse.
>> 
>> I don't follow. Assignments through IETF-stream documents do not go
>> through expert review.
> 
> Then this should be made *much* clearer in the document. In fact, the document says:
> 
>   A key element of the procedural streamlining specified in this
>   document is to establish identical assignment procedures for all IETF
>   transport protocols.
> 
> I assumed that "all" meant "all", not "all except those through IETF-stream documents"; others might have read it the same way I did.

The sentence you quote isn't related to the issue we're discussing. It is intended to say "a goal is that the procedures to get ports and service names are the same for UDP, TCP, DCCP and SCTP." (Maybe it would be clearer by explicitly naming these protocols in the document.)

But I see the point you're raising. The document should somewhere say that "Expert Review" is the procedure used for assignment requests made directly to IANA, whereas for documents on the IETF Stream, "IETF Consensus" is sufficient to make the assignment. In other words, no expert review doesn't really need to happen for those, since IETF Review and IESG Approval are at least equivalent.

Did I get that right?

>> But even if they did, there is an appeals procedure.
> 
> That is slim comfort to a WG that has designed a protocol that has good design reasons for needing two ports and, at the last minute is told that they either have to re-design from scratch or go through an appeals process to justify their design to IANA. It's fine that they have to justify it to the IESG (well, fine to me; other greybeards seem to not like that so much these days), but there should be no way that IANA can say "you cannot get ports assigned because this new RFC says that you designed your protocol wrong". If what you say above about "Assignments through IETF-stream documents do not go through expert review." is true, it should be plainly stated in the introduction to the document.

Right. I think the change I outlined above would address this.

Thanks!

Lars