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

Joe Touch <touch@ISI.EDU> Tue, 06 April 2010 22:24 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 CD52A3A68BF for <port-srv-reg@core3.amsl.com>; Tue, 6 Apr 2010 15:24:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level:
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 1fEs0B86kakT for <port-srv-reg@core3.amsl.com>; Tue, 6 Apr 2010 15:24:55 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 519073A6A62 for <port-srv-reg@ietf.org>; Tue, 6 Apr 2010 15:21:27 -0700 (PDT)
Received: from [75.213.197.194] (194.sub-75-213-197.myvzw.com [75.213.197.194]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o36MKuT5010617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Apr 2010 15:20:58 -0700 (PDT)
Message-ID: <4BBBB3C8.9060402@isi.edu>
Date: Tue, 06 Apr 2010 15:20:56 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
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>
In-Reply-To: <4BABC04D.206@isi.edu>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1EEF6926A3838A70FFF9CA0C"
X-MailScanner-ID: o36MKuT5010617
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] 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: Tue, 06 Apr 2010 22:24:56 -0000

Hi all,

For the item I had:



> ------------------------------------------------------------------------------
> 
> - names for table entries to coordinate with Olafur's tables
> 
> Joe:
> 
> Will clarify list of table entries and ensure they are described
> completely in the current doc.

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)
      Service Code (only REQUIRED for DCCP)
      Description (REQUIRED)
      Reference (REQUIRED)

This provides a list from which the table can be created, with one
correction (transport protocol(s) are always REQUIRED; this should be
corrected in Sec 8.1). This is as is already contained in the example
table provided for feedback at
http://www.viagenie.ca/ianaxml/port-numbers.xhtml

      *Service Name
      *Transport Protocol(s)
      Port Number (where applicable)
      Service Code (for DCCP)
      Short description
      +Comments (typically lists unauthorized uses by squatters,
		also lists deprecated, changes, etc.)
      References
      Registration Admin Contact (listed as Registrant)
      Registration Technical Contact (listed as Point of Contact)

(* = the pair {service name, transport protocol} forms a unique key into
this table)

All the items above except for "Comments" are described in the doc, and
constitute the registration information. The comments field should, IMO,
be broken down into a few separate fields; I'm not sure any of these
need to be listed in the doc, however, since the information it presents
is administrative 'out-of-band' context.

Here's what I would break it into two fields:

	Known Unauthorized Uses
	Assignment comments (de-registration, owner change, name change)

I'm not sure it's appropriate to list the known unauthorized uses in the
same table as the authorized ones; I would prefer de-valuing that list
to a separate table on a separate page.

Joe