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

Joe Touch <touch@isi.edu> Tue, 01 February 2011 17:46 UTC

Return-Path: <touch@isi.edu>
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 C38883A6959; Tue, 1 Feb 2011 09:46:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.516
X-Spam-Level:
X-Spam-Status: No, score=-104.516 tagged_above=-999 required=5 tests=[AWL=2.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 XzykfvE1q0Xx; Tue, 1 Feb 2011 09:46:22 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 5F17B3A6E88; Tue, 1 Feb 2011 09:46:17 -0800 (PST)
Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p11HnGxm001001 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 1 Feb 2011 09:49:16 -0800 (PST)
Message-ID: <4D48479C.3010104@isi.edu>
Date: Tue, 01 Feb 2011 09:49:16 -0800
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 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> <4D413827.7040407@ericsson.com> <B4F0B107-4D84-43A5-A091-B6877D24C23B@cisco.com> <4D46B3B9.4050804@ericsson.com> <755A9333-6960-4BCC-B996-3775E76B5D9E@cisco.com>
In-Reply-To: <755A9333-6960-4BCC-B996-3775E76B5D9E@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, tsvwg@ietf.org, IESG IESG <iesg@ietf.org>, IETF discussion list <ietf@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: Tue, 01 Feb 2011 17:46:23 -0000

On 2/1/2011 9:19 AM, Cullen Jennings wrote:
>
> So to summarize what you are saying, ports are allocated based on an
> arbitrary view of the expert review. When this person will say yes or no
> too can't be described and will change over time.

See my other post. Section 8.1.1 already states that there are other 
means besides expert review.

> If that's how it works, there is not even any grounds for appeal of
> any given decision.

The grounds are "disagree with the advice of the Expert Review". The 
IESG can overturn those decisions on that basis alone. They can - and 
have - held up decisions that have come from community consensus as 
well. I.e., this is no different from other appeals process. It is based 
on the strength of the argument.

 From your earlier post:

> I put in a request for a latency sensitive protocol that uses DTLS
> and request a different port for the secure version. Joe as expert
> review says we should redesign the protocol to use something like
> STARTLS and run on one port. I assert, with very little evidence,
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                                          **************************
> that will not meet the latency goals of the protocol. Joe does not
> agree.

The burden of proof, especially when asking for multiple ports, ought to 
be on the applicant. "very little evidence" is the issue, and if that 
didn't convince me, then there's an appeals process listed in RFC 5226 
which you could have used to take that "very little evidence" to 
convince the IESG to overturn the decision.

Joe