Subject: [port-srv-reg] Please review: (Revised) Application for User (Registered) Service Name and Port Number

From: Pearl Liang <[email-masked]>
Date: Wed, 25 May 2011 16:18:02 -0700

Hello All,

Below is another revised version of Application for Service Name and Port
Number that included further feedback I have received.  Thank you.
However, questions related to SCTP from Lars and Magnus are not yet
answered:

From Magnus:
>7. If I want to change some of the SCTP specific info from the
>registration template, how do I do that?

From Lars:

>>IF SCTP is requested, please describe the following: Is there an
>>existing TCP and/or UDP?

>Sentence misses a subject?

It would be great if you can provide any helps on these.

Changes to this version of the template:
- Desired port number question;
- FAQ regarding to add a new proto;

Please feel free to edit as needed and provide your feedback so that we
can conclude that we have completed all actions for the
I-D.ietf-tsvwg-iana-ports. :)

Thank you,
~pl

###########

TITLE: Application for Service Name and User Port Number

The User (Registered) Ports are those from 1024 through 49151. (See
http://www.iana.org/assignments/port-numbers. (/* internal comment: this
URL will change to the later merged registry of port number and
service name.)

* UNASSIGNED PORT NUMBERS SHOULD NOT BE USED.  THE IANA WILL ASSIGN *
* THE NUMBER FOR THE PORT AFTER YOUR APPLICATION HAS BEEN APPROVED. *

Please fill in the below application as required by RFCXXXX.
If you require more than one port number, please submit separate templates.

Assignee Name (REQUIRED): _______________________________
Assignee E-mail (REQUIRED): _______________________________
Contact Name (REQUIRED) _______________________________
Contact E-mail (REQUIRED) _______________________________
See RFCXXXX section 8.1

Transport Protocol(s) (REQUIRED): (Please check one(s) that is
currently applied.)
[  ] TCP 	[  ] UDP	[  ] SCTP	[  ] DCCP

Service Code (REQUIRED for DCCP only)
Please see RFCXXXX section 10.3 and RFC4340 section 8.1.2

____________________________

Service Name (REQUIRED, 15 Character): See RFCXXX section 5.1

____________________________
See FAQs below.

Description Name (REQUIRED) (For example: Super User Messaging)
See FAQs below.

________________________________________________________________

Reference (REQUIRED): Please provide a brief and basic technical
description including message formats, types, sequences,
functionalities, of your  protocol. Please also address the specific
questions to the extent possible.

________________________________________________________________
  
________________________________________________________________

________________________________________________________________
  
________________________________________________________________

________________________________________________________________

Q: If broadcast/multicast is used, how and what for?

______________________________________________________________

Q: If UDP is requested, please explain how traffic is limited, and
whether the protocol reacts to congestion.

_______________________________________________________________

Q: If UDP is requested, please indicate whether the service is solely
for the discovery of hosts supporting this protocol.

_______________________________________________________________

Q: Please explain how your protocol supports versioning.

_______________________________________________________________

Q: If your request is for more than one transport, please explain in
detail how the protocol differs over each transport.

_______________________________________________________________

Q: Please describe how your protocol supports security. Please note that
there is current debate as to whether additional future ports will be
allocated for newly assigned services that lack security, e.g., solely
for the addition of a secure variant. Applicants are strongly advised to
address this issue as early as possible in the design of their protocols.

________________________________________________________________

Q: Please explain the state of development of your protocol.

________________________________________________________________

Please provide any other information that would be helpful in
understanding how this protocol differs from existing assigned services.

________________________________________________________________

IF SCTP is requested, please describe the following: Is there an
existing TCP and/or UDP?
If so, please indicate the details below:

Port number: _______________; Service Name: _______________

What specific SCTP capability is used by the application such that an
user who has the choice of both TCP (and/or UDP) and SCTP ports for
this application would choose SCTP? See RFC4960 section 7.1
(http://tools.ietf.org/html/rfc4960#section-7.1)

__________________________________________________________________
  
__________________________________________________________________

Desired Port Number (OPTIONAL)

__________________________________________

NOTE: It is inappropriate to use a port number until your application has
been approved for assignment.  Leave it blank if no number preference.

*********
FAQs:

* User ports allocations require ³Expert Review² procedure as described
in [RFC5226] because User ports are a scarce resource.  This is
described in RFCXXX section 8.1.2

* Assignment of a port number does not in any way imply an endorsement of
an application or product, and the fact that network traffic is flowing to
or from a registered port does not mean that it is "good" traffic.
Firewall and system administrators should choose how to configure their
systems based on their knowledge of the traffic in question, and any other
relevant criteria.

* Please note that a particular application or service should be able
to operate only one registered user port number. For applications or
services that offer multiple functions it is usually possible to use
one port as a multiplexer or rendezvous service. That is, the client
always initiates the use of a service by contacting the rendezvous
port and indicating in its first message which function is needed.
The rendezvous service then either (A) creates (forks, spawns) a
process to perform that function and passes the connection to it; or
(B) dynamically selects a (high-numbered) port and starts a process
to perform the function listening on that port and sends a message
back to the client telling it to call the new process on that port.

* Assignee Name:
The Assignee is the organization, company or individual person responsible
for the initial assignment.  For assignments done through RFCs published
via the "IETF Document Stream" [RFC4844], the Assignee will be the IESG
<[email-masked]>.  See RFCXXXX section 8.1

* Contact Name:
The Contact person is the responsible person for the Internet community to
send questions  to.  This person is also authorized to submit changes on
behalf of the Assignee; in cases of conflict between the Assignee and the
Contact, the Assignee decisions take precedence.  For assignments done
through RFCs published via the "IETF Document Stream" [RFC4844], the
Contact will be the IETF Chair <[email-masked]>.  See RFCXXXX section 8.1

* Service Name and Description Name:
Please avoid the terms and acronyms referring to "service" and "protocol",
as these are implied for all assignments. Please also avoid
version-specific
information, as new assignments are expected to be version-independent.

###

---

From: Lars Eggert <[email-masked]>
Date: Thu, 26 May 2011 08:54:16 +0300

Hi,

> It would be great if you can provide any helps on these.

I think this means to ask if an assignment for the service already exists for TCP or UDP.

> (http://tools.ietf.org/html/rfc4960#section-7.1)

I also note that the template you attached was missing quite a number of the edits I suggested earlier?

Lars

---

From: "David Harrington" <[email-masked]>
Date: Thu, 26 May 2011 08:38:31 -0400

Hi,

since this has moved from discussion of a document to discussion of
the template, should this be opened to tsvwg WG discussion?

I am not sure whether it should be or not. I suppose this could
treated as IANA seeking expert review. But if this is something the
IETF community might have concerns with, such as removal of SCTP
questions from the template, an open discussion might be best.

David Harrington
Director, IETF Transport Area
[email-masked] (preferred for ietf)
[email-masked]
+1 603 828 1401 (cell)

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Lars Eggert
> Sent: Thursday, May 26, 2011 1:54 AM
> To: Pearl Liang
> Cc: [email-masked]
> Subject: Re: [port-srv-reg] Please review: (Revised) 
> Application for User(Registered) Service Name and Port Number
> 
> Hi,
> 
> I also note that the template you attached was missing quite 
> a number of the edits I suggested earlier?
> 
> Lars

---

From: Lars Eggert <[email-masked]>
Date: Thu, 26 May 2011 15:44:04 +0300

Hi,

> questions from the template, an open discussion might be best.

the content of the IANA template wasn't created by the IETF community to begin with, so I'm not sure we need to run changes by the community. I'm all for being open, but an open discussion can add significant delay here.

(I'm somewhat surprised to begin with that IANA is only now beginning to figure out how their template will be affected - it's not like this hasn't been coming for years...)

Lars