Re: [tsvwg] [Fwd: Re: AD review: draft-ietf-tsvwg-port-randomization-05]

Joe Touch <touch@ISI.EDU> Fri, 05 February 2010 16:47 UTC

Return-Path: <touch@ISI.EDU>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57ED428C1DC; Fri, 5 Feb 2010 08:47:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 Lc+xttL9eQkX; Fri, 5 Feb 2010 08:47:23 -0800 (PST)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 75A5B3A687B; Fri, 5 Feb 2010 08:47:23 -0800 (PST)
Received: from [75.214.178.5] (5.sub-75-214-178.myvzw.com [75.214.178.5]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o15GkXiB015202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Feb 2010 08:46:34 -0800 (PST)
Message-ID: <4B6C4B69.20402@isi.edu>
Date: Fri, 05 Feb 2010 08:46:33 -0800
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: "tom.petch" <cfinss@dial.pipex.com>
Subject: Re: [tsvwg] [Fwd: Re: AD review: draft-ietf-tsvwg-port-randomization-05]
References: <C78C9824.20159%michelle.cotton@icann.org> <004201caa654$6f5e5fc0$0601a8c0@allison>
In-Reply-To: <004201caa654$6f5e5fc0$0601a8c0@allison>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="------------enig2E8135001CBFA1866A76D80D"
X-MailScanner-ID: o15GkXiB015202
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: apps-discuss <apps-discuss@ietf.org>, Michelle Cotton <michelle.cotton@icann.org>, tsvwg <tsvwg@ietf.org>
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Feb 2010 16:47:24 -0000

Tom,

The problem is that the two ideas (the list below, 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. Further, this doc is about IANA issues, not the expert
review process.

Joe


tom.petch wrote:
> ----- Original Message -----
> From: "Michelle Cotton" <michelle.cotton@icann.org>
> To: "Fernando Gont" <fernando@gont.com.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.
> 
> Tom Petch
> 
> </tp>
> 
> 
> Michelle
> IANA
> 
> On 1/27/10 11:20 AM, "Fernando Gont" <fernando@gont.com.ar> wrote:
> 
>>> Have there any cases in which use of a port has been rejected?
>> Yes.
>>
>>> If so, what has been that reason?
>> Depends :-) Maybe IANA can give some examples.
>>
>>> And what has been the criteria for actually "granting" the use of
>>> ports (as the above)?
>> Satisfying the Expert Reviewer.