Re: [port-srv-reg] ACTION ITEMS - final updates - ports doc

Joe Touch <touch@isi.edu> Wed, 19 May 2010 14:21 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 3025228C118 for <port-srv-reg@core3.amsl.com>; Wed, 19 May 2010 07:21:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.919
X-Spam-Level:
X-Spam-Status: No, score=-0.919 tagged_above=-999 required=5 tests=[AWL=-0.734, BAYES_40=-0.185]
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 bEzoRBbqx7OH for <port-srv-reg@core3.amsl.com>; Wed, 19 May 2010 07:21:22 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id BAEA328C0F6 for <port-srv-reg@ietf.org>; Wed, 19 May 2010 07:19:18 -0700 (PDT)
Received: from [192.168.1.92] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o4JEI0ZC020940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 May 2010 07:18:14 -0700 (PDT)
Message-ID: <4BF3F313.40805@isi.edu>
Date: Wed, 19 May 2010 07:17:55 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Lars Eggert <lars.eggert@nokia.com>
References: <201002190143.CAA21850@TR-Sys.de> <4B7F0FF4.5050904@isi.edu> <4B98AE6D.4040704@erg.abdn.ac.uk> <4B9AB98F.5080802@isi.edu> <4B9B6F07.7090105@erg.abdn.ac.uk> <4B9B9F8C.6080900@isi.edu> <4BABC04D.206@isi.edu> <4BBBB3C8.9060402@isi.edu> <4BE1B8C6.6010706@isi.edu> <7ECE5396-364E-4365-8E1B-F782E25727B0@nokia.com> <4BF33873.8010309@isi.edu> <4D0497EE-FD49-445E-942D-1388C66A2701@nokia.com>
In-Reply-To: <4D0497EE-FD49-445E-942D-1388C66A2701@nokia.com>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6025F3A5F1D7F4A32FB4DF9F"
X-MailScanner-ID: o4JEI0ZC020940
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "port-srv-reg@ietf.org" <port-srv-reg@ietf.org>
Subject: Re: [port-srv-reg] ACTION ITEMS - final updates - ports doc
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: Wed, 19 May 2010 14:21:24 -0000

Hi, Lars,

Lars Eggert wrote:
> Hi,
> 
> On 2010-5-19, at 4:01, Joe Touch wrote:
>>>> The current list of registration information is listed in Section 8.1:
>>>>
>>>>     Registration Administrative Contact (REQUIRED)
>>>>     Registration Technical Contact (REQUIRED)
>>>>     Service Name (REQUIRED)
>>>>     Port Number (OPTIONAL)
>>>>     Transport Protocol(s) (REQUIRED if port number requested)
>> I think we agreed to make this "(REQUIRED)" in all cases.
> 
> a port number isn't required for when only a service name is requested, no?

Correct. Port number remains OPTIONAL (see a few lines up).

The transport protocol is not, as per our discussion on the list (TCP,
UDP, SCTP, etc.). I.e., even if an applicant requests a service name
without a port number, they still need to indicate at least one
transport protocol for that service, and only those indicated are
registered.

I.e., here are the specific changes:

<orig>
	Transport Protocol(s) (REQUIRED if port number requested)
<new>
	Transport Protocol(s) (REQUIRED)

<orig>
   o  Transport Protocol(s): If assignment of a port number is desired,
      the transport protocol(s) for which the allocation is requested
      MUST be provided.  This field is currently limited to one or more
      of TCP, UDP, SCTP, and DCCP.
<new>
   o  Transport Protocol(s): The transport protocol(s) for which the
      allocation is requested MUST be provided.  This field is currently
      limited to one or more of TCP, UDP, SCTP, and DCCP. This field is
      required even for services with no port number.

>>>>     Service Code (only REQUIRED for DCCP)
>>>>     Description (REQUIRED)
>>>>     Reference (REQUIRED)
>> It might be useful to move the service name and transport protocol to
>> the top of the list, and indicate that the pair are the "key", i.e.,
>> they define the service.
>>
>> I would suggest adding the following two OPTIONAL fields to the set
>> above, which are NOT provided by the applicant:
>>
>> 	Known Unauthorized Uses
>> 	Assignment comments (de-registration, owner/name change, etc.)
> 
> Can you provide text for those two, so we understand a little better what they'd be about?

<new - insert after Reference (REQUIRED)>
	Known Unauthorized Uses (OPTIONAL)
	Assignment Notes (OPTIONAL)

<new - insert after full description of Reference>

o Known Unauthorized Uses: A list of uses by applications or
organizations who are not the assignee. This list may be augmented by
IANA after assignment when unauthorized uses are reported.

o Assignment Notes: Indications of owner/name change, or any other
assignment process issue. This list may be updated by IANA after
assignment to help track changes to an assignment, e.g.,
de-registration, owner/name changes, etc.

------