Re: [port-srv-reg] Fwd: [tsvwg] [Fwd: Re: AD review: draft-ietf-tsvwg-port-randomization-05]
Joe Touch <touch@ISI.EDU> Fri, 05 February 2010 14:44 UTC
Return-Path: <touch@ISI.EDU>
X-Original-To: port-srv-reg@core3.amsl.com
Delivered-To: port-srv-reg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix)
with ESMTP id CB0043A6DA7 for <port-srv-reg@core3.amsl.com>;
Fri, 5 Feb 2010 06:44:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300,
BAYES_00=-2.599, J_CHICKENPOX_35=0.6]
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 XK7rHcmKUH-A for
<port-srv-reg@core3.amsl.com>; Fri, 5 Feb 2010 06:44:11 -0800 (PST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com
(Postfix) with ESMTP id F37973A6AA3 for <port-srv-reg@ietf.org>;
Fri, 5 Feb 2010 06:44:07 -0800 (PST)
Received: from [192.168.1.95] (pool-71-106-88-10.lsanca.dsl-w.verizon.net
[71.106.88.10] (may be forged)) (authenticated bits=0) by vapor.isi.edu
(8.13.8/8.13.8) with ESMTP id o15Egpji028975 (version=TLSv1/SSLv3
cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
Fri, 5 Feb 2010 06:42:53 -0800 (PST)
Message-ID: <4B6C2E6A.4030202@isi.edu>
Date: Fri, 05 Feb 2010 06:42:50 -0800
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Lars Eggert <lars.eggert@nokia.com>
References: <004201caa654$6f5e5fc0$0601a8c0@allison>
<781C9E2F-F351-4627-994B-E1FCB6B4CDFC@nokia.com>
In-Reply-To: <781C9E2F-F351-4627-994B-E1FCB6B4CDFC@nokia.com>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="------------enig3CD0DB5B274BF4AE91226F7B"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: port-srv-reg@ietf.org
Subject: Re: [port-srv-reg] Fwd: [tsvwg] [Fwd: Re: AD
review: draft-ietf-tsvwg-port-randomization-05]
X-BeenThere: port-srv-reg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of updates to service name and transport protocol port
registry <port-srv-reg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/port-srv-reg>,
<mailto:port-srv-reg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/port-srv-reg>
List-Post: <mailto:port-srv-reg@ietf.org>
List-Help: <mailto:port-srv-reg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/port-srv-reg>,
<mailto:port-srv-reg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Feb 2010 14:44:11 -0000
Lars Eggert wrote: > > Begin forwarded message: > >> From: tom.petch <cfinss@dial.pipex.com> >> Date: February 5, 2010 10:28:44 GMT+02:00 >> To: Michelle Cotton <michelle.cotton@icann.org>rg>, "Eggert Lars (Nokia-NRC/Espoo)" <lars.eggert@nokia.com> >> Cc: tsvwg <tsvwg@ietf.org>rg>, apps-discuss <apps-discuss@ietf.org> >> Subject: Re: [tsvwg] [Fwd: Re: AD review: draft-ietf-tsvwg-port-randomization-05] >> Reply-To: tom.petch <cfinss@dial.pipex.com> >> >> ----- Original Message ----- >> From: "Michelle Cotton" <michelle.cotton@icann.org> >> To: "Fernando Gont" <fernando@gont.com.ar>ar>; "Lars Eggert" >> <lars.eggert@nokia.com> >> Cc: "tsvwg" <tsvwg@ietf.org> >> Sent: Monday, February 01, 2010 11:39 PM >> >> >> Fernando/Lars, >> >> Following-up on the thread below. >> >> Port Number requests are rejected for many reasons. Here are three of the most >> common reasons: >> >> 1 - Duplicates a function or protocol already in existence >> 2 - Is the secure version of a port already applied for or already in existence >> 3 - Port applied for is of local use only and traffic does not flow over the >> public Internet >> >> In general, a port number request is granted when an applicant can show a >> well-defined, public Internet protocol. The port must identify a named service >> that allows sessions to be created over the public Internet. The protocol, in a >> successful application, will be sufficiently documented to ensure that it is not >> local or a version of another service already in use. >> >> I hope this information helps. Please let me know if there is anything I can >> clarify. >> >> <tp> >> >> Michelle >> >> How straightforward and clear the above paragraphs are. Honest. Brilliant. >> >> I need to say this because recently I was critical of >> draft-ietf-tsvwg-iana-ports-04 >> for the lack of just this information, for describing the bureaucracy of port >> assignment/allocation/registration/reservation/request/grant........ >> without >> a) explaining what if anything is the difference between these terms >> b) describing what the point of the bureaucracy is. >> >> Your paragraphs above do more good than the whole of section 7, so please ditch >> section 7, include something along the lines above, and place it right at the >> front of the I-D, section 2. I would place reasons for granting before reasons >> for rejecting but otherwise I would change little. The problem is that the two ideas (the list above, vs. Sec 7) have completely different purposes. Section 7 describe IANA policies and changes therein. The above describes expert review, which is a separate matter. I hesitate to encode expert review rules - even the "most common" ones - because then can too easily change, and putting them in a doc promotes them as static. Joe