Re: Questions about draft-lear-iana-no-more-well-known-ports-00.txt

Eliot Lear <lear@cisco.com> Wed, 24 May 2006 13:11 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fit98-00026Y-9k; Wed, 24 May 2006 09:11:30 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fit96-00023i-Ur for ietf@ietf.org; Wed, 24 May 2006 09:11:28 -0400
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fit95-0006CT-Kz for ietf@ietf.org; Wed, 24 May 2006 09:11:28 -0400
Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-2.cisco.com with ESMTP; 24 May 2006 06:11:28 -0700
X-IronPort-AV: i="4.05,165,1146466800"; d="scan'208"; a="323335382:sNHT31721720"
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k4ODBRTi010551; Wed, 24 May 2006 06:11:27 -0700
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k4ODBQsF010197; Wed, 24 May 2006 06:11:26 -0700 (PDT)
Received: from [10.33.78.51] (che-vpn-cluster-1-217.cisco.com [10.86.240.217]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4OD8VDV013995; Wed, 24 May 2006 06:08:31 -0700
Message-ID: <44745B81.8000508@cisco.com>
Date: Wed, 24 May 2006 15:11:29 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308)
MIME-Version: 1.0
To: John C Klensin <john-ietf@jck.com>
References: <883F4A921E26D32C08E569F0@p3.JCK.COM>
In-Reply-To: <883F4A921E26D32C08E569F0@p3.JCK.COM>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Authentication-Results: sj-dkim-8.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; );
DKIM-Signature: a=rsa-sha1; q=dns; l=2818; t=1148476287; x=1149340287; c=relaxed/simple; s=sjdkim8001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20<lear@cisco.com> |Subject:Re=3A=20Questions=20about=20draft-lear-iana-no-more-well-known-ports-00. txt; X=v=3Dcisco.com=3B=20h=3DP1ZcSnKSt0/B7RXoWBE/S7zgV/Y=3D; b=iT1ia8Mqbs/jjXstoLqfXUTWHymXVhnpQT2TLZvqi3EzyUhIgJI9h/tQRb1jZsQxzpZ/Amao 0GHYTjsZ7MWdYgfouStBaRDyaY48vj1WgAMWxtaK91DRrRjaPPe+u7R5;
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Cc: ietf@ietf.org
Subject: Re: Questions about draft-lear-iana-no-more-well-known-ports-00.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org

John C Klensin wrote:
> Eliot,
>
> I haven't made up my mind whether I think this is a good idea or
> not

I'm not sure all the ideas in the document are a good idea either!

> (1) At present, the IESG reviews and approves applications for
> well-known ports.  If the IESG does not believe a particular
> protocol proposal is "worthy" (my terminology, not theirs), then
> a low-numbered port is not assigned although the author is free
> to go to IANA for a higher-numbered one.   Would the effect, and
> intention, of deprecating the distinction between "well known"
> and other ports be to take the IESG entirely out of the approval
> loop for port assignments except as described in the first two
> paragraphs of section 2?
>   

Yes, the distinction between well known ports and just assigned ports is
outdated.  The overarching theme of the document is that the IANA should
be treated as a group of adults and that they should use some discretion
with oversight only where needed.
> (2) Your charging plan ties a potential charge to port requests
> originating outside the IETF process for which there is no
> corresponding RFC.  However, there have been cases in which IANA
> has assigned a port number, the requester has submitted a
> document for RFC publication, but the RFC Editor has not found
> the description of the associated protocol to be of sufficient
> interest to the community to be worth publishing.  It seems to
> me that this creates an uncomfortable situation which could be
> resolved by:
>
> 	(i) Requiring that the RFC Editor publish, on request,
> 	any protocol description for which IANA assigns a port
> 	number of for which it has assigned a port number in the
> 	past.  or
> 	
> 	(ii) Permits that charge only for ports and protocols
> 	for which no documentation has been submitted to the RFC
> 	Editor for publication.  or
> 	
> 	(iii) Creates a two-track process for assignment of port
> 	numbers that are not based on IETF-approved protocols.
> 	In one, the RFC Editor approves a specification document
> 	and then requests that the port assignment be made,
> 	while, in the other, requesters go to IANA directly but
> 	agree to pay any fees necessary.    Of course, our
> 	normal procedures and conventions would presumably
> 	require an appeals procedure if the RFC Editor turned
> 	something down. That would raise all sorts of other
> 	issues that might not make either the community or the
> 	RFC Editor very happy (see
> 	draft-klensin-rfc-independent-01.txt)
>
> So, what did you have in mind?
>   

What I have in mind is that the protocol be documented in some normative
way, not necessarily via the RFC Editor.  But your observations are
astute and deserve further consideration in the next revision.

Eliot

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf