Subject: Re: [port-srv-reg] status check

From: Lars Eggert <[email-masked]>
Date: Mon, 3 May 2010 22:17:28 +0300

Hi,

On 2010-4-22, at 13:15, Eggert Lars (Nokia-NRC/Espoo) wrote:
> where are we with regards to this document and the issues we identified in Anaheim? The last commit to the svn repository was on 2010-01-11 by Magnus...

so - where are we? 

Lars

---

From: Michelle Cotton <[email-masked]>
Date: Mon, 3 May 2010 12:27:49 -0700

I'm just now coming back to work.  I spoke with Mark McFadden on Friday and we discussed the changes that IANA has to provide for the document.  I expect those to be made very soon.

Michelle

On 5/3/10 12:17 PM, "Lars Eggert" <[email-masked]> wrote:

Hi,

so - where are we?

Lars

---

From: Lars Eggert <[email-masked]>
Date: Tue, 4 May 2010 08:39:38 +0300

Hi,

On 2010-5-3, at 22:27, Michelle Cotton wrote:
> I’m just now coming back to work.  I spoke with Mark McFadden on Friday and we discussed the changes that IANA has to provide for the document.  I expect those to be made very soon.

thank you.

But there were also several other changes to be made by the other editors. It would be good to hear where we are with regards to those. Joe, could you email out the list of edits again that we agreed on in Anaheim?

Lars

---

From: Joe Touch <[email-masked]>
Date: Wed, 05 May 2010 11:28:22 -0700

As requested by Lars, here's the list of action items pending on the
ports doc.

I've included the answer to my action item herein.

Joe

******************************************************************************

Update to the updates:

------------------------------------------------------------------------------

- assigned vs registered

5226 is IANA Considerations, explains what these terms mean.

Mark:

Will give us text & check for consistency throughout the doc.

------------------------------------------------------------------------------

- need to specify transports for service names

Lars:

This focuses on how to ask for a service name.

Ask for just a service name. The entry will be:
	banana TCP
	banana UDP

Olafur's doc will indicate how to use this.

------------------------------------------------------------------------------

- who gets to add transports to a service that exists?

Draft text:

IANA will reserve updates that add transports to existing services with
priority to the owner of the existing registrations, with exceptions
coordinated with the IESG.

------------------------------------------------------------------------------

- WKS needs to be addressed

Olafur:

Remove WKS text from our docs. Point to Olafur's doc, which closes other
registries as a result.

------------------------------------------------------------------------------

- the online tables may need to support "sort on multiple fields"

IANA action item TBD. Does not affect doc.

------------------------------------------------------------------------------

- Alfred's observation that, "looking for "transport"/"protocol", I
found that the draft repeatedly uses "protocol number[s]" or even
"address[es]" where it should say "port number[s]"

Olafur:

Will check for consistency.

------------------------------------------------------------------------------

- the doc should focus on user interfaces to IANA actions

Current intro/abstract are OK. No changes to doc.

------------------------------------------------------------------------------

- Gorry's input that: Section 10.3.1:  It is good to also cite RFC 5595
>>> >>> (you currently cite the draft) for service code information,
since this
>>> >>> updated RFC 4340 in many ways. Also Section 10.3.2 since this
explains
>>> >>> how ports and SC interact and how you can manage without port
allocations
>>> >>> To be added (AFAICT, it wasn't yet)

Gorry:

To fix as request. Check also the appendix for DCCP.

------------------------------------------------------------------------------

- Gorry's input that: We MUST note in the new draft that no registry
>>> >>> allocations can be made for zero or 4294967295, and no registry
>>> >>> allocations can be made for 1056964608-1073741823 (high byte
ASCII "?")
>>> >>> reserved for private use [19.8 of RFC 4340].
>>> >>> To be added.

Gorry:

To fix as requested. Check also the appendix for DCCP.

------------------------------------------------------------------------------

- Gorry's input that: see 10.3.2: IANA MUST NOT allocate a single
>>> >>> Service Code value to more than one DCCP server port. // revise
to MUST
>>> >>> NOT allocate more than one port to a single service code value;
multiple
>>> >>> SC per port is allowed, subject to expert review.
>>> >>> To be added.

Gorry:

To fix as requested. Check also the appendix for DCCP.

------------------------------------------------------------------------------

- Gorry's input that: updates RFC 5595, since the latter states where
>>> >>> ports and service codes are registered
>>> >>> To be added.

Gorry:

To fix as requested. Check also the appendix for DCCP.

------------------------------------------------------------------------------

- Gorry's input that we fix the acknowledgements (ref to Tom - who?)
>>>>> >>>>> GORRY - can you clarify?

Gorry:

To fix as requested. Check also the appendix for DCCP.

------------------------------------------------------------------------------

>> >> [ P.S. The note I sent simply said the "ack" to Tom Phelan isn't
>> >> really the full story. Tom pointed to the text in section 6 of
>> >> draft http://tools.ietf.org/html/draft-ietf-dccp-serv-codes-04.
>> >> This ID was edited by me, with some inputs from Eddie Kohler and
>> >> some from Tom. I removed this text from the DCCP RFC, when it was
>> >> sent to help make this draft. That's all.]

------------------------------------------------------------------------------

- point about multiple names that use the same port number

Two cases:

	www/http = synonyms
	stun/turn = in-band negotiation

Lars:

Will update text as needed.

------------------------------------------------------------------------------

>>>>> >>>>> My suggestion would be to add a section to that draft
grandfathering
>>>>> >>>>> ports 465, 993, 2000 and a few more (adding as much negative
verbiage as
>>>>> >>>>> seems wise; I don't think the exact amount makes and
difference at all).
>>>>> >>>>> IIRC port 2000 can be grandfathered a half-dozen times.

This document does not document protocols no longer used.

No changes to the doc for this.

------------------------------------------------------------------------------

> > There are two separate issues:
> >
> > - previous assignments that don't follow the proposed recommendations
> > 	- as noted, there's no goal to fix that

Already note we're leaving existing stuff alone.

No changes to the doc for this.

------------------------------------------------------------------------------

> > - 'squatting', or use of ports without registering through IANA
> > 	- IMO, these should not be ignored, but clearly cannot be
> > 	treated as equivalent to 'self assigned'
> >
> > 	i.e., IMO, IANA should list these as "unauthorized use",
> > 	as a service to the community to help those using those
> > 	ports as assigned.

Out of scope for this doc.

No changes to the doc for this.

------------------------------------------------------------------------------

- email to registrants whose entries will be modified

Stuart:

Will send/review text.

No changes to the doc for this.

------------------------------------------------------------------------------

- table boilerplate

Michelle:

Will send draft text.

No changes to the doc for this.

------------------------------------------------------------------------------

- 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.

(PS - here's my input)
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. Comments should NOT include
items eligible for other fields, e.g., references.

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.

------------------------------------------------------------------------------

- updates for new transport protocols

Lars:

Will add text for how new transports are handled.

------------------------------------------------------------------------------

- how you get a port number vs ask for a port number

Lars:

Clarify how you either leave this open in the request or ask for a
number. (how you state a preference)

- sec 7.3 / need to add IESG approval to IETF approval for system ports

Michelle:

To update text.

------------------------------------------------------------------------------

-- end.

---

From: Lars Eggert <[email-masked]>
Date: Mon, 10 May 2010 17:21:45 +0300

Hi,

Gorry sent me a version with his changes, and I committed it to svn. I then made the changes I was signed up for, as follow:

> Will update text as needed.

Done (see diff).

> Will add text for how new transports are handled.

Done (see diff).

> number. (how you state a preference)

I re-read the doc, and to me the text is clear. Anyone remember what this was about?

> - sec 7.3 / need to add IESG approval to IETF approval for system ports

Done (see diff).

Lars

PS: Diff has Gorry's and my changes.

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 13 May 2010 15:54:03 +0100

Looks good to me except we don't want to use ports as much as possible;-)

- could we change this from:
/to follow the guidelines and practices around using port	
numbers and service names as much as possible./
to:
/to follow as much as possible the guidelines and practices around using 
  port numbers and service names./

---

It seems Joe, Olafur and Michelle need to contribute their parts and we 
may be done. Any chance we can get these integrated quickly so we can 
ask for some working group review?

Gorry

---

From: Lars Eggert <[email-masked]>
Date: Mon, 17 May 2010 11:03:55 +0300

Applied

On 2010-5-13, at 17:54, Gorry Fairhurst wrote:

> to follow as much as possible the guidelines and practices around using 
>  port numbers and service names.

---

From: Lars Eggert <[email-masked]>
Date: Tue, 18 May 2010 10:52:24 +0300

Hi,

Gorry and me did our to-dos. Which gives me the moral high ground :-) to point the finger and ask all of you to please get to the things that have your name on them in the list below. We need to progress this document to IETF LC before Maastricht.

Lars

On 2010-5-5, at 21:28, Joe Touch wrote:

> <signature.asc><ATT00001..txt>

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 May 2010 18:01:39 -0700

FWIW, my remaining issue dealt with the list of registration info, as below.

Changes indicated by comments.

Joe

I think we agreed to make this "(REQUIRED)" in all cases.

>>      Service Code (only REQUIRED for DCCP)

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.)

Joe

---

From: Lars Eggert <[email-masked]>
Date: Wed, 19 May 2010 14:22:56 +0300

Hi,

> 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?

> 	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?

Thanks,
Lars

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 19 May 2010 13:24:37 +0100

>Hi,
Hi Lars,

>a port number isn't required for when only a service name is requested, no?
I thought Joe was talking about Transport Protocol(s), not about the 
Port Number.

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 May 2010 07:17:55 -0700

Hi, Lars,

> 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.

> 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.

------

---

From: "David Harrington" <[email-masked]>
Date: Wed, 19 May 2010 11:51:15 -0400

Hi,

I recommend against having the "Known Unauthorized Uses" field.
I think this would encourage continued use of the unassigned srv/port.

Syslog WG wrote a document explaining why syslog is not interoprable -
it documented how everybody does it differently - and vendors claim
compliance to that RFC.
Somebody will claim "compliance" to the IANA registry that lists their
unauthorized usage.

dbh

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Lars Eggert
> Sent: Wednesday, May 19, 2010 7:23 AM
> To: Joe Touch
> Cc: [email-masked]
> Subject: Re: [port-srv-reg] ACTION ITEMS - final updates - ports doc
> 
> Hi,
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 May 2010 08:58:26 -0700

Hi, David,

The list cuts both ways. Yes, they can claim compliance with the IANA
registry - they can do that now, though.

Anyone checking that claim would find that they explicitly violated the
claim. We already have such notes, where some are labeled more blatantly
than others, e.g.:

########### PORT 90 also being used unofficially by Pointcast #########

##########      106     Unauthorized use by insecure poppassd protocol

########### Possible Conflict of Port 222 with "Masqdialer"#############
### Contact for Masqdialer is Charles Wright <cpwright&villagenet.com>##

#####  Microsoft (unoffically) using 1232     #####

#### Port 2370 Unofficially used by Compaq ####

########### 3300-3301  Unauthorized Use by SAP R/3   ######

We ought to be uniform in our treatment of these entries. Also note that
this isn't adding information; we already track and post that information.

Finally, I think we can be more explicit:

Unauthorized use by XXX in violation of RFC NNN.

Joe

---

From: Lars Eggert <[email-masked]>
Date: Thu, 20 May 2010 09:46:04 +0300

Hi,

>      required even for services with no port number.

applied.

> de-registration, owner/name changes, etc.

Also applied, for now, so we know what we are discussing.

Lars

PS: Diff to -04:

---

From: Lars Eggert <[email-masked]>
Date: Thu, 20 May 2010 14:31:08 +0300

Hi,

made some more updates from out to-do list. I believe we're getting close to having a submittable version.

Does anyone still have changes queued, or can I submit -05?

Lars

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 20 May 2010 13:13:20 +0100

I'd be VERY happy to see this submitted.

Gorry

Lars Eggert wrote:
> ------------------------------------------------------------------------
> 
> 	 draft-ietf-tsvwg-iana-ports-04.txt 		 draft-ietf-tsvwg-iana-ports.txt 	
> 				
> 	Transport Area Working Group M. Cotton		Transport Area Working Group S. 
> Cheshire	
> 	Internet-Draft ICANN		Internet-Draft Apple	
> 	Updates: 2780, 2782, 3828, 4340, L. Eggert		Updates: 2780, 2782, 3828, 
> 4340, M. Cotton	
> 	4960 (if approved) Nokia		4960 (if approved) ICANN	
> 	Intended status: BCP J. Touch		Intended status: BCP L. Eggert	
> 	Expires: July 15, 2010 USC/ISI		Expires: November 21, 2010 Nokia	
> 			J. Touch	
> 			USC/ISI	
> 	M. Westerlund		M. Westerlund	
> 	Ericsson		Ericsson	
> 	January 11, 2010		May 20, 2010	
> 				
> 	Internet Assigned Numbers Authority (IANA) Procedures for the 
> Management		Internet Assigned Numbers Authority (IANA) Procedures for 
> the Management	
> 	of the Transport Protocol Port Number and Service Name Registry		of the 
> Transport Protocol Port Number and Service Name Registry	
> 	draft-ietf-tsvwg-iana-ports-04		draft-ietf-tsvwg-iana-ports-05	
> 				
> 	Abstract		Abstract	
> 				
> 	This document defines the procedures that the Internet Assigned		This 
> document defines the procedures that the Internet Assigned	
> 	Numbers Authority (IANA) uses when handling registration and other	 
> Numbers Authority (IANA) uses when handling registration and other	
> 	requests related to the transport protocol port number and service	 
> requests related to the transport protocol port number and service	
> 	name registry. It also discusses the rationale and principles behind	 
> name registry. It also discusses the rationale and principles behind	
> 	these procedures and how they facilitate the long-term sustainability	 
> these procedures and how they facilitate the long-term sustainability	
> 	of the registry.		of the registry.	
> 				
> 	This document updates IANA's procedures by obsoleting Sections 8 and	 
> This document updates IANA's procedures by obsoleting Sections 8 and	
> 	9.1 of the IANA allocation guidelines [RFC2780], it updates the IANA	 
> 9.1 of the IANA allocation guidelines [RFC2780], it updates the IANA	
> 	allocation procedures for UDP-Lite [RFC3828], DCCP [RFC4340] and SCTP	 
> allocation procedures for UDP-Lite [RFC3828], DCCP [RFC4340] and SCTP	
> 	[RFC4960], it updates the DNS SRV specification [RFC2782] to clarify	 
> [RFC4960], it updates the DNS SRV specification [RFC2782] to clarify	
> 	what a service name is and how it is registered.		what a service name 
> is and how it is registered.	
> 				
> 	Status of this Memo		Status of this Memo	
> 				
> 	This Internet-Draft is submitted to IETF in full conformance with the	 
> This Internet-Draft is submitted in full conformance with the	
> 	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.	
> 				
> 	Internet-Drafts are working documents of the Internet Engineering	 
> Internet-Drafts are working documents of the Internet Engineering	
> 	Task Force (IETF), its areas, and its working groups. Note that		Task 
> Force (IETF). Note that other groups may also distribute	
> 	other groups may also distribute working documents as Internet-	 
> working documents as Internet-Drafts. The list of current Internet-	
> 	Drafts.		Drafts is at http://datatracker.ietf.org/drafts/current/.	
> 				
> 	Internet-Drafts are draft documents valid for a maximum of six months	 
> Internet-Drafts are draft documents valid for a maximum of six months	
> 	and may be updated, replaced, or obsoleted by other documents at any	 
> and may be updated, replaced, or obsoleted by other documents at any	
> 	time. It is inappropriate to use Internet-Drafts as reference		time. It 
> is inappropriate to use Internet-Drafts as reference	
> 	material or to cite them other than as "work in progress."		material or 
> to cite them other than as "work in progress."	
> 				
> 	The list of current Internet-Drafts can be accessed at		This 
> Internet-Draft will expire on November 21, 2010.	
> 	http://www.ietf.org/ietf/1id-abstracts.txt.			
> 				
> 	The list of Internet-Draft Shadow Directories can be accessed at			
> 	http://www.ietf.org/shadow.html.			
> 				
> 	This Internet-Draft will expire on July 15, 2010.			
> 				
> 	Copyright Notice		Copyright Notice	
> 				
> 	Copyright (c) 2010 IETF Trust and the persons identified as the	 
> Copyright (c) 2010 IETF Trust and the persons identified as the	
> 	document authors. All rights reserved.		document authors. All rights 
> reserved.	
> 				
> 	This document is subject to BCP 78 and the IETF Trust's Legal		This 
> document is subject to BCP 78 and the IETF Trust's Legal	
> 	Provisions Relating to IETF Documents		Provisions Relating to IETF 
> Documents	
> 	(http://trustee.ietf.org/license-info) in effect on the date of	 
> (http://trustee.ietf.org/license-info) in effect on the date of	
> 	publication of this document. Please review these documents	 
> publication of this document. Please review these documents	
> 	carefully, as they describe your rights and restrictions with respect	 
> carefully, as they describe your rights and restrictions with respect	
> 	to this document. Code Components extracted from this document must		to 
> this document. Code Components extracted from this document must	
> 	include Simplified BSD License text as described in Section 4.e of	 
> include Simplified BSD License text as described in Section 4.e of	
> 	the Trust Legal Provisions and are provided without warranty as		the 
> Trust Legal Provisions and are provided without warranty as	
> 	described in the BSD License.		described in the Simplified BSD License.	
> 				
> 	This document may contain material from IETF Documents or IETF		This 
> document may contain material from IETF Documents or IETF	
> 	Contributions published or made publicly available before November	 
> Contributions published or made publicly available before November	
> 	10, 2008. The person(s) controlling the copyright in some of this		10, 
> 2008. The person(s) controlling the copyright in some of this	
> 	material may not have granted the IETF Trust the right to allow	 
> material may not have granted the IETF Trust the right to allow	
> 	modifications of such material outside the IETF Standards Process.	 
> modifications of such material outside the IETF Standards Process.	
> 	Without obtaining an adequate license from the person(s) controlling	 
> Without obtaining an adequate license from the person(s) controlling	
> 	the copyright in such materials, this document may not be modified		the 
> copyright in such materials, this document may not be modified	
> 	outside the IETF Standards Process, and derivative works of it may	 
> outside the IETF Standards Process, and derivative works of it may	
> 	not be created outside the IETF Standards Process, except to format	 
> not be created outside the IETF Standards Process, except to format	
> 	it for publication as an RFC or to translate it into languages other	 
> it for publication as an RFC or to translate it into languages other	
> 	than English.		than English.	
> 				
> 	Table of Contents		Table of Contents	
> 				
> 	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. 
> Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4	
> 	2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. 
> Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5	
> 	3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6		3. 
> Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6	
> 	4. Conventions Used in this Document . . . . . . . . . . . . . . 7		4. 
> Conventions Used in this Document . . . . . . . . . . . . . . 7	
> 	5. Service Names . . . . . . . . . . . . . . . . . . . . . . . . 7		5. 
> Service Names . . . . . . . . . . . . . . . . . . . . . . . . 8	
> 	5.1. Service Name Syntax . . . . . . . . . . . . . . . . . . . 8		5.1. 
> Service Name Syntax . . . . . . . . . . . . . . . . . . . 9	
> 	5.2. Service Name Usage in DNS SRV Records . . . . . . . . . . 9		5.2. 
> Service Name Usage in DNS SRV Records . . . . . . . . . . 9	
> 	6. Port Number Ranges . . . . . . . . . . . . . . . . . . . . . . 10	 
> 6. Port Number Ranges . . . . . . . . . . . . . . . . . . . . . . 10	
> 	6.1. Port Numbers and Service Names for Experimentation . . . . 10	 
> 6.1. Port Numbers and Service Names for Experimentation . . . . 11	
> 	7. Principles for Port Number and Service Name Registry		7. Principles 
> for Port Number and Service Name Registry	
> 	Management . . . . . . . . . . . . . . . . . . . . . . . . . . 11	 
> Management . . . . . . . . . . . . . . . . . . . . . . . . . . 11	
> 	7.1. Past Principles . . . . . . . . . . . . . . . . . . . . . 11		7.1. 
> Past Principles . . . . . . . . . . . . . . . . . . . . . 12	
> 	7.2. Updated Principles . . . . . . . . . . . . . . . . . . . . 12	 
> 7.2. Updated Principles . . . . . . . . . . . . . . . . . . . . 12	
> 	7.3. Variances for Specific Port Number Ranges . . . . . . . . 14		7.3. 
> Variances for Specific Port Number Ranges . . . . . . . . 15	
> 	8. IANA Procedures for Managing the Port Number and Service		8. IANA 
> Procedures for Managing the Port Number and Service	
> 	Name Registry . . . . . . . . . . . . . . . . . . . . . . . . 15		Name 
> Registry . . . . . . . . . . . . . . . . . . . . . . . . 16	
> 	8.1. Port Number and Service Name Registration . . . . . . . . 15		8.1. 
> Port Number and Service Name Registration . . . . . . . . 16	
> 	8.2. Port Number and Service Name De-Registration . . . . . . . 18	 
> 8.2. Port Number and Service Name De-Registration . . . . . . . 19	
> 	8.3. Port Number and Service Name Re-Use . . . . . . . . . . . 19		8.3. 
> Port Number and Service Name Re-Use . . . . . . . . . . . 19	
> 	8.4. Port Number and Service Name Revocation . . . . . . . . . 19		8.4. 
> Port Number and Service Name Revocation . . . . . . . . . 20	
> 	8.5. Port Number and Service Name Transfers . . . . . . . . . . 20	 
> 8.5. Port Number and Service Name Transfers . . . . . . . . . . 21	
> 	8.6. Maintenance Issues . . . . . . . . . . . . . . . . . . . . 20	 
> 8.6. Maintenance Issues . . . . . . . . . . . . . . . . . . . . 21	
> 	9. Security Considerations . . . . . . . . . . . . . . . . . . . 20		9. 
> Security Considerations . . . . . . . . . . . . . . . . . . . 21	
> 	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21	 
> 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22	
> 	10.1. Service Name Consistency . . . . . . . . . . . . . . . . . 21	 
> 10.1. Service Name Consistency . . . . . . . . . . . . . . . . . 22	
> 	10.2. Port Numbers for SCTP and DCCP Experimentation . . . . . . 23	 
> 10.2. Port Numbers for SCTP and DCCP Experimentation . . . . . . 24	
> 	10.3. Updates to DCCP Registries . . . . . . . . . . . . . . . . 24	 
> 10.3. Updates to DCCP Registries . . . . . . . . . . . . . . . . 25	
> 	11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 25	 
> 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26	
> 	12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25	 
> 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26	
> 	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26	 
> 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27	
> 	13.1. Normative References . . . . . . . . . . . . . . . . . . . 26	 
> 13.1. Normative References . . . . . . . . . . . . . . . . . . . 27	
> 	13.2. Informative References . . . . . . . . . . . . . . . . . . 27	 
> 13.2. Informative References . . . . . . . . . . . . . . . . . . 28	
> 	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28	 
> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29	
> 				
> 	1. Introduction		1. Introduction	
> 				
> 	For many years, the allocation and registration of new port number		For 
> many years, the allocation and registration of new port number	
> 	values and service names for use with the Transmission Control		values 
> and service names for use with the Transmission Control	
> 	Protocol (TCP) [RFC0793] and the User Datagram Protocol (UDP)		Protocol 
> (TCP) [RFC0793] and the User Datagram Protocol (UDP)	
> 	[RFC0768] have had less than clear guidelines. New transport		[RFC0768] 
> have had less than clear guidelines. New transport	
> 	protocols have been added - the Stream Control Transmission Protocol	 
> protocols have been added - the Stream Control Transmission Protocol	
> 	(SCTP) [RFC4960] and the Datagram Congestion Control Protocol (DCCP)	 
> (SCTP) [RFC4960] and the Datagram Congestion Control Protocol (DCCP)	
> 	[RFC4342] - and new mechanisms like DNS SRV records [RFC2782] have	 
> [RFC4342] - and new mechanisms like DNS SRV records [RFC2782] have	
> 				
> 	skipping to change at/ page 5, line 22/		skipping to change at/ page 5, 
> line 22/	
> 	to which section of that 230-page document it refers. The DNS SRV		to 
> which section of that 230-page document it refers. The DNS SRV	
> 	specification may have been referring to the list of Port Assignments	 
> specification may have been referring to the list of Port Assignments	
> 	(known as /etc/services on Unix), or to the "Protocol And Service	 
> (known as /etc/services on Unix), or to the "Protocol And Service	
> 	Names" section, or to both, or to some other section. Furthermore,	 
> Names" section, or to both, or to some other section. Furthermore,	
> 	"Assigned Numbers" is now obsolete [RFC3232] and has now been	 
> "Assigned Numbers" is now obsolete [RFC3232] and has now been	
> 	replaced by on-line registries [PORTREG][PROTSERVREG]. There are	 
> replaced by on-line registries [PORTREG][PROTSERVREG]. There are	
> 	additional updates and clarifications on how DNS SRV utilize the	 
> additional updates and clarifications on how DNS SRV utilize the	
> 	Service name registry created in this document in "Clarification of	 
> Service name registry created in this document in "Clarification of	
> 	DNS SRV Owner Names" [I-D.gudmundsson-dnsext-srv-clarify].		DNS SRV 
> Owner Names" [I-D.gudmundsson-dnsext-srv-clarify].	
> 				
> 			The development of new transport protocols is a major effort that the	
> 			IETF does not undertake very often. If a new transport protocol is	
> 			standardized in the future, for the purpose of uniformity it is	
> 			expected to follow as much as possible the guidelines and practices	
> 			around using port numbers and service names.	
> 				
> 	2. Motivation		2. Motivation	
> 				
> 	Information about the registration procedures for the port registry	 
> Information about the registration procedures for the port registry	
> 	has existed in three locations: the forms for requesting port number	 
> has existed in three locations: the forms for requesting port number	
> 	registrations on the IANA web site [SYSFORM] [USRFORM], an	 
> registrations on the IANA web site [SYSFORM] [USRFORM], an	
> 	introductory text section in the file listing the port number	 
> introductory text section in the file listing the port number	
> 	registrations themselves [PORTREG], and two brief sections of the	 
> registrations themselves [PORTREG], and two brief sections of the	
> 	IANA Allocation Guidelines [RFC2780].		IANA Allocation Guidelines 
> [RFC2780].	
> 				
> 	Similarly, the procedures surrounding service names have been	 
> Similarly, the procedures surrounding service names have been	
> 				
> 	skipping to change at/ page 6, line 7/		skipping to change at/ page 6, 
> line 13/	
> 	for both port numbers and service names. It gives more detailed		for 
> both port numbers and service names. It gives more detailed	
> 	guidance to prospective requesters of ports and service names than	 
> guidance to prospective requesters of ports and service names than	
> 	the existing documentation, and it streamlines the IANA procedures		the 
> existing documentation, and it streamlines the IANA procedures	
> 	for the management of the registry, so that management requests can	 
> for the management of the registry, so that management requests can	
> 	complete in a timely manner.		complete in a timely manner.	
> 				
> 	This document defines rules for registration of service names without	 
> This document defines rules for registration of service names without	
> 	associated port numbers, for such usages as DNS SRV records		associated 
> port numbers, for such usages as DNS SRV records	
> 	[RFC2782], which was not possible under the previous IANA procedures.	 
> [RFC2782], which was not possible under the previous IANA procedures.	
> 	The document also merges service name registrations from the non-IANA	 
> The document also merges service name registrations from the non-IANA	
> 	ad hoc registry [SRVREG] and from the the IANA "Protocol and Service	 
> ad hoc registry [SRVREG] and from the IANA "Protocol and Service	
> 	Names" registry [PROTSERVREG] into the IANA "Port and Service Name"	 
> Names" registry [PROTSERVREG] into the IANA "Port and Service Name"	
> 	registry [PORTREG], which from here on is the single authoritative	 
> registry [PORTREG], which from here on is the single authoritative	
> 	registry for service names and port numbers.		registry for service 
> names and port numbers.	
> 				
> 	An additional purpose of this document is to describe the principles	 
> An additional purpose of this document is to describe the principles	
> 	that guide the IETF and IANA in their role as the long-term joint		that 
> guide the IETF and IANA in their role as the long-term joint	
> 	stewards of the port number registry. TCP and UDP have been a		stewards 
> of the port number registry. TCP and UDP have been a	
> 	remarkable success over the last decades. Thousands of applications	 
> remarkable success over the last decades. Thousands of applications	
> 	and application-level protocols have registered ports and service		and 
> application-level protocols have registered ports and service	
> 	names for their use, and there is every reason to believe that this	 
> names for their use, and there is every reason to believe that this	
> 				
> 	skipping to change at/ page 7, line 45/		skipping to change at/ page 8, 
> line 4/	
> 	also ask for only an assigned service name, if their application does	 
> also ask for only an assigned service name, if their application does	
> 	not require a fixed port number. The latter alternative is		not require 
> a fixed port number. The latter alternative is	
> 	encouraged when possible, in order to conserve the more limited port	 
> encouraged when possible, in order to conserve the more limited port	
> 	number space. This includes, for example, applications that use DNS	 
> number space. This includes, for example, applications that use DNS	
> 	SRV records to look up port numbers at runtime.		SRV records to look up 
> port numbers at runtime.	
> 				
> 	4. Conventions Used in this Document		4. Conventions Used in this Document	
> 				
> 	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	 
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	
> 	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this	 
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this	
> 	document are to be interpreted as described in RFC 2119 [RFC2119].	 
> document are to be interpreted as described in [RFC2119].	
> 				
> 	5. Service Names		5. Service Names	
> 				
> 	Service names are the unique key in the Port and Service Name		Service 
> names are the unique key in the Port and Service Name	
> 	registry. This unique symbolic name for a service may also be used	 
> registry. This unique symbolic name for a service may also be used	
> 	for other purposes, such as in DNS SRV records [RFC2782]. Within the	 
> for other purposes, such as in DNS SRV records [RFC2782]. Within the	
> 	registry, this unique key ensures that different services can be	 
> registry, this unique key ensures that different services can be	
> 	unambiguously distinguished, thus preventing name collisions and	 
> unambiguously distinguished, thus preventing name collisions and	
> 	avoiding confusion about who is the administrative contact for a	 
> avoiding confusion about who is the administrative contact for a	
> 	particular entry.		particular entry.	
> 				
> 	For each service name, there may exist zero or more associated port	 
> For each service name, there may exist zero or more associated port	
> 	number assignments. A port number assignment associated with a		number 
> assignments. A port number assignment associated with a	
> 	service name contains the transport protocol, port number and		service 
> name contains the transport protocol, port number and	
> 	possibly additional data, such as a DCCP service code.		possibly 
> additional data, such as a DCCP Service Code.	
> 				
> 	There may be more than one service name associated with a particular	 
> There may be more than one service name associated with a particular	
> 	transport protocol and port. This SHOULD only occur when all such	 
> transport protocol and port. There are two valid reasons for	
> 	service names are aliases for the same service, such as with "http"	 
> allowing service name aliases:	
> 	and "www". In such cases, one of the service names MUST be			
> 	designated primary, for use with mechanisms such as DNS SRV Records		o 
> Aliases are permissible when all such service names are for the	
> 	[RFC2782], and the others MUST be designated as aliases of the		same 
> service, such as with "http" and "www", which both name TCP	
> 	primary service name. This is necessary so that all clients and		port 
> 80. In such cases, one of the service names SHOULD be	
> 	servers using a service discovery mechanism use a consistent name by	 
> designated primary, for use with mechanisms such as DNS SRV	
> 	which to refer to a given service. Otherwise, if a server were to	 
> Records [RFC2782], and the others SHOULD be designated as aliases	
> 	advertise that it supports the "www" service, and a client were to		of 
> the primary service name. This is necessary so that clients	
> 	seek instances of the "http" service, that client would fail to		and 
> servers using a service discovery mechanism use a consistent	
> 	discover that server, defeating the purpose of having a service		name 
> by which to refer to a given service. Otherwise, if a server	
> 	discovery mechanism.		were to advertise that it supports the "www" 
> service, and a client	
> 			were to seek instances of the "http" service, that client would	
> 			fail to discover that server, defeating the purpose of having a	
> 			service discovery mechanism. For aliases that do not indicate a	
> 			primary alias, a server is expected to register itself under all	
> 			aliased service names.	
> 				
> 			o Aliases are also permissible when one service is an extension of	
> 			another service, and an in-band mechanisms exists for determining	
> 			if the extension is present or not. One example is port 3478,	
> 			which has the service name aliases "stun" and "turn". TURN	
> 			[RFC5766] is an extension to the STUN [RFC5389] service. TURN-	
> 			enabled clients wishing to locate TURN servers could attempt to	
> 			discover "stun" services and then checking in-band if the server	
> 			supports TURN, but this is inefficient. Enabling them to directly	
> 			query for "turn" servers by name is a better approach. (Note that	
> 			TURN servers in this case should also be locatable via a "stun"	
> 			discovery, because every TURN server is also a STUN server.)	
> 				
> 	Service names are assigned on a "first come, first served" basis, as	 
> Service names are assigned on a "first come, first served" basis, as	
> 	described in Section 8.1. Names should be brief and informative,	 
> described in Section 8.1. Names should be brief and informative,	
> 	avoiding words or abbreviations that are redundant in the context of	 
> avoiding words or abbreviations that are redundant in the context of	
> 	the registry (e.g., "port", "service", "protocol", etc.) Names		the 
> registry (e.g., "port", "service", "protocol", etc.) Names	
> 	referring to discovery services, e.g., using multicast or broadcast	 
> referring to discovery services, e.g., using multicast or broadcast	
> 	to identify endpoints capable of a given service, SHOULD use an		to 
> identify endpoints capable of a given service, SHOULD use an	
> 	easily identifiable suffix (e.g., "-disc").		easily identifiable suffix 
> (e.g., "-disc").	
> 				
> 	5.1. Service Name Syntax		5.1. Service Name Syntax	
> 				
> 	skipping to change at/ page 9, line 4/		skipping to change at/ page 9, 
> line 27/	
> 	hyphens ("-", ASCII 0x2D or decimal 45). They MUST be at least one	 
> hyphens ("-", ASCII 0x2D or decimal 45). They MUST be at least one	
> 	character and no more than fifteen characters long, MUST NOT begin or	 
> character and no more than fifteen characters long, MUST NOT begin or	
> 	end with a hyphen, and MUST NOT consist of only digits (in order to	 
> end with a hyphen, and MUST NOT consist of only digits (in order to	
> 	be distinguishable from port numbers, which are typically written as	 
> be distinguishable from port numbers, which are typically written as	
> 	all digits).		all digits).	
> 				
> 	The service name syntax MAY be used to validate a service name		The 
> service name syntax MAY be used to validate a service name	
> 	string, but MUST NOT be used for any other purpose (e.g.,		string, but 
> MUST NOT be used for any other purpose (e.g.,	
> 	delineation). Any system that includes a service name inside a	 
> delineation). Any system that includes a service name inside a	
> 	longer string is itself responsible for delineating the service name.	 
> longer string is itself responsible for delineating the service name.	
> 				
> 	Such systems MUST NOT rely on the syntax of a service name alone for	 
> Such systems MUST NOT rely on the syntax of a service name alone for	
> 	such delineation.		such delineation.	
> 				
> 	The syntax defined in ABNF [RFC5234]:		The syntax defined in ABNF 
> [RFC5234]:	
> 				
> 	SERVICE-NAME = ( ALPHA / *( [HYPHEN] ALPHANUM ) )		SRVNAME = (ALPHA / 
> *([HYPHEN] ALNUM)) /	
> 	/ (1*DIGIT ( (HYPHEN ALPHANUM) | ALPHA) *([HYPHEN] ALPHANUM) )	 
> (1*DIGIT ((HYPHEN ALNUM) / ALPHA) *([HYPHEN] ALNUM))	
> 			ALNUM = ALPHA / DIGIT ; A-Z, a-z, 0-9	
> 	ALPHANUM = ALPHA | DIGIT ; A-Z, a-z, 0-9		HYPHEN = %x2d ; "-"	
> 	HYPHEN = %x2d ; "-"		ALPHA = <See [RFC5234]>	
> 	ALPHA = <See RFC 5234>		DIGIT = <See [RFC5234]>	
> 	DIGIT = <See RFC 5234>			
> 				
> 	5.2. Service Name Usage in DNS SRV Records		5.2. Service Name Usage in 
> DNS SRV Records	
> 				
> 	The DNS SRV specification [RFC2782] requests that the Service Label	 
> The DNS SRV specification [RFC2782] requests that the Service Label	
> 	part of the owner name of DNS SRV records includes a "Service"		part of 
> the owner name of DNS SRV records includes a "Service"	
> 	element, defined to be "the symbolic name of the desired service",	 
> element, defined to be "the symbolic name of the desired service",	
> 	but did not state precisely which part of the IANA database (i.e.		but 
> did not state precisely which part of the IANA database (i.e.	
> 	STD 2 when RFC 2782 was written) serves as a registry for standard		STD 
> 2 when [RFC2782] was written) serves as a registry for standard	
> 	service names.		service names.	
> 				
> 	This document clarifies that the Service Label MUST be a service name	 
> This document clarifies that the Service Label MUST be a service name	
> 	as defined herein. The service name SHOULD be registered with IANA		as 
> defined herein. The service name SHOULD be registered with IANA	
> 	and recorded in the Service Names and Port Numbers registry		and 
> recorded in the Service Names and Port Numbers registry	
> 	[PORTREG]. This is needed to ensure that only a single registry of	 
> [PORTREG]. This is needed to ensure that only a single registry of	
> 	Service Names exists and name collisions can be avoided in the		Service 
> Names exists and name collisions can be avoided in the	
> 	future.		future.	
> 				
> 	The details of the use of Service Names from [PORTREG] in SRV Service	 
> The details of the use of Service Names from [PORTREG] in SRV Service	
> 	Labels are specified in [RFC2782] and the documents updating or		Labels 
> are specified in [RFC2782] and the documents updating or	
> 	replacing that specification (see the companion document		replacing 
> that specification (see the companion document	
> 	[I-D.gudmundsson-dnsext-srv-clarify] for more information).	 
> [I-D.gudmundsson-dnsext-srv-clarify] for more information).	
> 				
> 	The details of how applications make use of DNS SRV should be		The 
> details of how applications make use of DNS SRV should be	
> 	specified in the documentation set of the application/service. In	 
> specified in the documentation set of the application/service. In	
> 	the absense of such specification, prospective clients of a given		the 
> absence of such specification, prospective clients of a given	
> 	service should not assume the existence of SRV RRs for this service	 
> service should not assume the existence of SRV RRs for this service	
> 	or, if they have indications that this will be the case (e.g., by		or, 
> if they have indications that this will be the case (e.g., by	
> 	configuration), must assume the unextended naming scheme from	 
> configuration), must assume the unextended naming scheme from	
> 	[RFC2782] for service discovery with DNS SRV, i.e., the Service Label	 
> [RFC2782] for service discovery with DNS SRV, i.e., the Service Label	
> 	is constructed from the Service Name registered in [PORTREG] by		is 
> constructed from the Service Name registered in [PORTREG] by	
> 	prepending a single underscore character ("_").		prepending a single 
> underscore character ("_").	
> 				
> 	6. Port Number Ranges		6. Port Number Ranges	
> 				
> 	TCP, UDP, UDP-Lite, SCTP and DCCP use 16-bit namespaces for their		TCP, 
> UDP, UDP-Lite, SCTP and DCCP use 16-bit namespaces for their	
> 				
> 	skipping to change at/ page 13, line 20/		skipping to change at/ page 
> 13, line 40/	
> 	application		application	
> 				
> 	o IANA will allocate only one assigned port number for all versions		o 
> IANA will allocate only one assigned port number for all versions	
> 	of a service (e.g., running the service with or without a security		of 
> a service (e.g., running the service with or without a security	
> 	mechanism, or for updated variants of a service)		mechanism, or for 
> updated variants of a service)	
> 				
> 	o IANA will allocate only one assigned port number for all different		o 
> IANA will allocate only one assigned port number for all different	
> 	types of device using or participating in the same service		types of 
> device using or participating in the same service	
> 				
> 	o IANA will allocate port numbers only for the transport protocol(s)		o 
> IANA will allocate port numbers only for the transport protocol(s)	
> 	(if any) explicitly named in an registration request		(if any) 
> explicitly named in a registration request	
> 				
> 	o IANA may recover unused port numbers, via the new procedures of		o 
> IANA may recover unused port numbers, via the new procedures of	
> 	de-registration, revocation, and transfer		de-registration, revocation, 
> and transfer	
> 				
> 	A given service is expected to further demultiplex messages where		A 
> given service is expected to further demultiplex messages where	
> 	possible. For example, applications and protocols are expected to	 
> possible. For example, applications and protocols are expected to	
> 	include in-band version information, so that future versions of the	 
> include in-band version information, so that future versions of the	
> 	application or protocol can share the same allocated port.		application 
> or protocol can share the same allocated port.	
> 	Applications and protocols are also expected to be able to	 
> Applications and protocols are also expected to be able to	
> 	efficiently use a single allocated port for multiple sessions, either	 
> efficiently use a single allocated port for multiple sessions, either	
> 				
> 	skipping to change at/ page 14, line 4/		skipping to change at/ page 
> 14, line 24/	
> 				
> 	The process and protocol identifier use suggests that anything a		The 
> process and protocol identifier use suggests that anything a	
> 	single process can demultiplex, or that can be encoded into a single	 
> single process can demultiplex, or that can be encoded into a single	
> 	protocol, should be. The firewall filtering use suggests that some	 
> protocol, should be. The firewall filtering use suggests that some	
> 	uses that could be multiplexed or encoded must be separated to allow	 
> uses that could be multiplexed or encoded must be separated to allow	
> 	for firewall management. Note that this latter use is much less		for 
> firewall management. Note that this latter use is much less	
> 	sound, because port numbers have meaning only for the two endpoints	 
> sound, because port numbers have meaning only for the two endpoints	
> 	involved in a connection, and drawing conclusions about the service	 
> involved in a connection, and drawing conclusions about the service	
> 	that generated a given flow based on observed port numbers is not		that 
> generated a given flow based on observed port numbers is not	
> 	always reliable. Further, previous separation of protocol variants	 
> always reliable. Further, previous separation of protocol variants	
> 	based on security capabilities (e.g., HTTP on port 80 vs. HTTPS on	 
> based on security capabilities (e.g., HTTP on TCP port 80 vs. HTTPS	
> 	port 443) is not recommended for new protocols, because all should be	 
> on TCP port 443) is not recommended for new protocols, because all	
> 	security-capable and capable of negotiating the use of security in-	 
> should be security-capable and capable of negotiating the use of	
> 	band.		security in-band.	
> 				
> 	IANA will begin assigning protocol numbers for only those transport	 
> IANA will begin assigning port numbers for only those transport	
> 	protocols explicitly included in a registration request. This ends	 
> protocols explicitly included in a registration request. This ends	
> 	the long-standing practice of automatically assigning a port number	 
> the long-standing practice of automatically assigning a port number	
> 	to an application for both TCP and a UDP, even if the request is for	 
> to an application for both TCP and a UDP, even if the request is for	
> 	only one of these transport protocols. The new allocation procedure	 
> only one of these transport protocols. The new allocation procedure	
> 	conserves resources by allocating a port number to an application for	 
> conserves resources by allocating a port number to an application for	
> 	only those transport protocols (TCP, UDP, SCTP and/or DCCP) it		only 
> those transport protocols (TCP, UDP, SCTP and/or DCCP) it	
> 	actually uses. The port number will be marked as Reserved - instead	 
> actually uses. The port number will be marked as Reserved - instead	
> 	of Assigned - in the port number registries of the other transport		of 
> Assigned - in the port number registries of the other transport	
> 	protocols. When applications start supporting the use of some of	 
> protocols. When applications start supporting the use of some of	
> 	those additional transport protocols, their implementors MUST request	 
> those additional transport protocols, the administrative contact for	
> 	IANA to convert the reservation into an assignment. An application		the 
> registration MUST request IANA to convert the reservation into a	
> 	MUST NOT assume that it can use a port number assigned to it for use	 
> proper assignment. An application MUST NOT assume that it can use a	
> 	with one transport protocol with another transport protocol without	 
> port number assigned to it for use with one transport protocol with	
> 	asking IANA to convert the reservation into an assignment.		another 
> transport protocol without asking IANA to convert the	
> 			reservation into an assignment.	
> 				
> 	When the available pool of unassigned address has run out in a port	 
> When the available pool of unassigned numbers has run out in a ports	
> 	range, it will be necessary for IANA to consider the Reserved ports	 
> range, it will be necessary for IANA to consider the Reserved ports	
> 	for assignment. This is part of the motivation to not automatically	 
> for assignment. This is part of the motivation to not automatically	
> 	assigning ports for other transport protocols than the requested	 
> assigning ports for other transport protocols than the requested	
> 	ones. This will allow more ports to be available for assignment at	 
> ones. This will allow more ports to be available for assignment at	
> 	that point. It also shows the importance to register the transport	 
> that point. It also shows the importance to register the transport	
> 	protocols that are in fact used.		protocols that are in fact used.	
> 				
> 	Conservation of port numbers is improved by procedures that allow	 
> Conservation of port numbers is improved by procedures that allow	
> 	previously allocated port numbers to become Unassigned, either	 
> previously allocated port numbers to become Unassigned, either	
> 	through de-registration or through revocation, and by a procedure	 
> through de-registration or through revocation, and by a procedure	
> 				
> 	skipping to change at/ page 15, line 20/		skipping to change at/ page 
> 15, line 41/	
> 	registration through IANA, and MAY be used as service identifiers	 
> registration through IANA, and MAY be used as service identifiers	
> 	upon successful registration. Because registering a port number		upon 
> successful registration. Because registering a port number	
> 	for a specific application consumes a fraction of the shared		for a 
> specific application consumes a fraction of the shared	
> 	resource that is the port number registry, IANA will require the	 
> resource that is the port number registry, IANA will require the	
> 	requester to document the intended use of the port number. This	 
> requester to document the intended use of the port number. This	
> 	documentation will be input to the "Expert Review" allocation	 
> documentation will be input to the "Expert Review" allocation	
> 	procedure [RFC5226], by which IANA will have a technical expert	 
> procedure [RFC5226], by which IANA will have a technical expert	
> 	review the request to determine whether to grant the registration.	 
> review the request to determine whether to grant the registration.	
> 	The submitted documentation MUST explain why using a port number		The 
> submitted documentation MUST explain why using a port number	
> 	in the Dynamic Ports range is unsuitable for the given		in the Dynamic 
> Ports range is unsuitable for the given	
> 	application.		application. Ports in the Registered Ports range may also be	
> 			assigned under the "IETF Review" or "IESG Approval" allocation	
> 			procedures [RFC5226], which is how most assignments for IETF	
> 			protocols are handled.	
> 				
> 	o Ports in the Well Known Ports range (0-1023) are also available		o 
> Ports in the Well Known Ports range (0-1023) are also available	
> 	for registration through IANA. Because the Well Known Ports range		for 
> registration through IANA. Because the Well Known Ports range	
> 	is both the smallest and the most densely allocated, the		is both the 
> smallest and the most densely allocated, the	
> 	requirements for new allocations are more strict than those for	 
> requirements for new allocations are more strict than those for	
> 	the Registered Ports range, and will only be granted under the		the 
> Registered Ports range, and will only be granted under the	
> 	"IETF Review" allocation procedure [RFC5226]. A request for a		"IETF 
> Review" or "IESG Approval" allocation procedures [RFC5226].	
> 	Well Known port number MUST document why using a port number from			
> 	both the Registered Ports and Dynamic Ports ranges is unsuitable		A 
> request for a Well Known port number MUST document why using a	
> 	for the given application.		port number from both the Registered Ports 
> and Dynamic Ports	
> 			ranges is unsuitable for the given application.	
> 				
> 	8. IANA Procedures for Managing the Port Number and Service Name		8. 
> IANA Procedures for Managing the Port Number and Service Name	
> 	Registry		Registry	
> 				
> 	This section describes the process for requests associated with		This 
> section describes the process for requests associated with	
> 	IANA's management of the port number and service name registry. Such	 
> IANA's management of the port number and service name registry. Such	
> 	requests include initial registration, de-registration, re-use,	 
> requests include initial registration, de-registration, re-use,	
> 	changes to the service name, as well as updates to the contact		changes 
> to the service name, as well as updates to the contact	
> 	information or description associated with an assignment. Revocation	 
> information or description associated with an assignment. Revocation	
> 	is initiated by IANA.		is initiated by IANA.	
> 				
> 	skipping to change at/ page 16, line 20/		skipping to change at/ page 
> 17, line 6/	
> 	Unassigned in the requested range. The current administrative	 
> Unassigned in the requested range. The current administrative	
> 	contact for a port number MAY register these Reserved port numbers	 
> contact for a port number MAY register these Reserved port numbers	
> 	for other transport protocols when needed.		for other transport 
> protocols when needed.	
> 				
> 	Service names, on the other hand, are not tied to a specific		Service 
> names, on the other hand, are not tied to a specific	
> 	transport protocol, and registration requests for only a service name	 
> transport protocol, and registration requests for only a service name	
> 	(but not a port number) allocate that service name for use with all	 
> (but not a port number) allocate that service name for use with all	
> 	transport protocols.		transport protocols.	
> 				
> 	A port number or service name registration request contains some or		A 
> port number or service name registration request contains some or	
> 	all of the following information:		all of the following information. 
> The combination of service name	
> 			and transport protocol is the unique identifier of a given service:	
> 				
> 			Service Name (REQUIRED)	
> 	Registration Administrative Contact (REQUIRED)		Registration 
> Administrative Contact (REQUIRED)	
> 	Registration Technical Contact (REQUIRED)		Registration Technical 
> Contact (REQUIRED)	
> 	Service Name (REQUIRED)			
> 	Port Number (OPTIONAL)		Port Number (OPTIONAL)	
> 	Service Code (only REQUIRED for DCCP)		Service Code (only REQUIRED for 
> DCCP)	
> 	Description (REQUIRED)		Description (REQUIRED)	
> 	Reference (REQUIRED)		Reference (REQUIRED)	
> 			o Service Name: A desired unique service name for the service	
> 			associated with the registration request MUST be provided, for use	
> 			in various service selection and discovery mechanisms (including,	
> 			but not limited to, DNS SRV records [RFC2782]). The name MUST be	
> 			compliant with the syntax defined in Section 5.1. In order to be	
> 			unique, they MUST NOT be identical to any currently registered	
> 			service names in the IANA registry [PORTREG]. Service names are	
> 			case-insensitive; they may be provided and entered into the	
> 			registry with mixed case (e.g., for clarity), but for the purposes	
> 			of comparison, the case is ignored.	
> 				
> 	o Registration Administrative Contact: Name and email address of the		o 
> Registration Administrative Contact: Name and email address of the	
> 	administrative contact for the registration. This is REQUIRED.	 
> administrative contact for the registration. This is REQUIRED.	
> 	The name of the administrative contact identifies the		The name of the 
> administrative contact identifies the	
> 	organization, company, or individual who is responsible for the	 
> organization, company, or individual who is responsible for the	
> 	registration. Registrations done through IETF-published RFCs, the	 
> registration. For registrations done through IETF-published RFCs,	
> 	administrative contact will be the IETF and not the technical		the 
> administrative contact will be the IESG.	
> 	contact persons.			
> 				
> 	o Registration Technical Contact: Name and email address of the		o 
> Registration Technical Contact: Name and email address of the	
> 	technical contact person for the registration. This is REQUIRED.	 
> technical contact person for the registration. This is REQUIRED.	
> 				
> 	For individuals, this is the same as the Registration		For individuals, 
> this is the same as the Registration	
> 	Administrative Contact; for organizations, this is a point of	 
> Administrative Contact; for organizations, this is a point of	
> 	contact at that organization. Additional address information MAY	 
> contact at that organization. Additional address information MAY	
> 	be provided. For registrations done through IETF-published RFCs,		be 
> provided. For registrations done through IETF-published RFCs,	
> 	one or more technical contact persons SHALL be provided.		the technical 
> contact will be the IESG.	
> 				
> 	o Service Name: A desired unique service name for the service			
> 	associated with the registration request MUST be provided, for use			
> 	in various service selection and discovery mechanisms (including,			
> 	but not limited to, DNS SRV records [RFC2782]). The name MUST be			
> 	compliant with the syntax defined in Section 5.1. In order to be			
> 	unique, they MUST NOT be identical to any currently registered			
> 	service names in the IANA registry [PORTREG]. Service names are			
> 	case-insensitive; they may be provided and entered into the			
> 	registry with mixed case (e.g., for clarity), but for the purposes			
> 	of comparison, the case is ignored.			
> 				
> 	o Port Number: If assignment of a port number is desired, either the		o 
> Port Number: If assignment of a port number is desired, either the	
> 	currently Unassigned port number the requester suggests for		currently 
> Unassigned port number the requester suggests for	
> 	allocation, or the text "ANY", MUST be provided. If only a		allocation, 
> or the text "ANY", MUST be provided. If only a	
> 	service name is to be assigned, this field MUST be empty. If a		service 
> name is to be assigned, this field MUST be empty. If a	
> 	specific port number is requested, IANA is encouraged to allocate	 
> specific port number is requested, IANA is encouraged to allocate	
> 	the requested number. If the text "ANY" is specified, IANA will		the 
> requested number. If the text "ANY" is specified, IANA will	
> 	choose a suitable number from the Registered Ports range. Note		choose 
> a suitable number from the Registered Ports range. Note	
> 	that the applicant MUST NOT use the requested port prior to the		that 
> the applicant MUST NOT use the requested port prior to the	
> 	completion of the registration.		completion of the registration.	
> 				
> 	o Service Code: The request MUST include a desired unique DCCP		o 
> Service Code: The request MUST include a desired unique DCCP	
> 	service code [RFC5595] if the registration request includes DCCP	 
> service code [RFC5595], if the registration request includes DCCP	
> 	as a transport protocol, and MUST NOT include a requested DCCP		as a 
> transport protocol, and MUST NOT include a requested DCCP	
> 	service code otherwise.		service code otherwise. Section 19.8 of 
> [RFC4340] defines	
> 			requirements and rules for allocation, updated by this document.	
> 				
> 	o Description: A short description of the service associated with		o 
> Description: A short description of the service associated with	
> 	the registration request is REQUIRED. It should avoid all but the		the 
> registration request is REQUIRED. It should avoid all but the	
> 	most well known acronyms.		most well known acronyms.	
> 				
> 	o Reference: A description of (or a reference to a document		o 
> Reference: A description of (or a reference to a document	
> 	describing) the protocol or application using this port. The	 
> describing) the protocol or application using this port. The	
> 	description must include whether the protocol uses either		description 
> must include whether the protocol uses either	
> 	broadcast, multicast, or anycast communication.		broadcast, multicast, 
> or anycast communication.	
> 				
> 				
> 	skipping to change at/ page 18, line 20/		skipping to change at/ page 
> 18, line 45/	
> 	is unsuitable for the given application.		is unsuitable for the given 
> application.	
> 				
> 	For registration requests for a Well Known Port, the registration		For 
> registration requests for a Well Known Port, the registration	
> 	request MUST explain why a port number in the Registered Ports or	 
> request MUST explain why a port number in the Registered Ports or	
> 	Dynamic Ports ranges is unsuitable, and a reference to a stable	 
> Dynamic Ports ranges is unsuitable, and a reference to a stable	
> 	protocol specification document MUST be provided. For requests	 
> protocol specification document MUST be provided. For requests	
> 	from IETF Working Groups, IANA MAY accept "Early" registration		from 
> IETF Working Groups, IANA MAY accept "Early" registration	
> 	requests referencing a sufficiently stable Internet Draft instead	 
> requests referencing a sufficiently stable Internet Draft instead	
> 	of a published Standards-Track RFC [RFC4020].		of a published 
> Standards-Track RFC [RFC4020].	
> 				
> 	When IANA receives a registration request containing the above		o Known 
> Unauthorized Uses: A list of uses by applications or	
> 	information requesting a port number, IANA SHALL initiate an "Expert	 
> organizations who are not the assignee. This list may be	
> 	Review" [RFC5226] in order to determine whether an assignment should	 
> augmented by IANA after assignment when unauthorized uses are	
> 	be made. For requests that do not include a port number, IANA SHOULD	 
> reported.	
> 	assign the service name under a simple "First Come First Served"			
> 	policy [RFC5226].		o Assignment Notes: Indications of owner/name 
> change, or any other	
> 			assignment to help track changes to an assignment, e.g., de-	
> 			registration, owner/name changes, etc.	
> 				
> 			If the registration request is for the addition of a new transport	
> 			protocol to an already assigned service name, IANA needs to confirm	
> 			with the administrative contact for the existing assignment whether	
> 			this addition is appropriate.	
> 				
> 			If the registration request is for a service name alias (see	
> 			Section 5), IANA needs to confirm with the administrative contact for	
> 			the existing service name whether the registration of the alias is	
> 			appropriate.	
> 				
> 			When IANA receives a registration request - containing the above	
> 			information - that is requesting a port number, IANA SHALL initiate	
> 			an "Expert Review" [RFC5226] in order to determine whether an	
> 			assignment should be made. For requests that do not include a port	
> 			number, IANA SHOULD assign the service name under a simple "First	
> 			Come First Served" policy [RFC5226].	
> 				
> 	8.2. Port Number and Service Name De-Registration		8.2. Port Number and 
> Service Name De-Registration	
> 				
> 	The administrative contact of a granted port number assignment can		The 
> administrative contact of a granted port number assignment can	
> 	return the port number to IANA at any time if they no longer have a	 
> return the port number to IANA at any time if they no longer have a	
> 	need for it. The port number will be de-registered and will be		need 
> for it. The port number will be de-registered and will be	
> 	marked as Reserved. IANA should not re-assign port numbers that have	 
> marked as Reserved. IANA should not re-assign port numbers that have	
> 	been de-registered until all other available port numbers in the		been 
> de-registered until all other available port numbers in the	
> 	specific range have been assigned.		specific range have been assigned.	
> 				
> 				
> 	skipping to change at/ page 21, line 30/		skipping to change at/ page 
> 22, line 27/	
> 	maintainer of the [SRVREG] registry, in order to merge the contents	 
> maintainer of the [SRVREG] registry, in order to merge the contents	
> 	of that private registry into the official IANA registry. It is		of 
> that private registry into the official IANA registry. It is	
> 	expected that the contents of [SRVREG] will at that time be replaced	 
> expected that the contents of [SRVREG] will at that time be replaced	
> 	with pointers to the IANA registry and to this RFC.		with pointers to 
> the IANA registry and to this RFC.	
> 				
> 	IANA is instructed to create a new service name entry in the port		IANA 
> is instructed to create a new service name entry in the port	
> 	number registry [PORTREG] for any entry in the "Protocol and Service	 
> number registry [PORTREG] for any entry in the "Protocol and Service	
> 	Names" registry [PROTSERVREG] that does not already have one		Names" 
> registry [PROTSERVREG] that does not already have one	
> 	assigned.		assigned.	
> 				
> 			IANA is also instructed to indicate which service name aliases in the	
> 			existing registry are the primary aliases (see Section 5).	
> 				
> 	10.1. Service Name Consistency		10.1. Service Name Consistency	
> 				
> 	Section 8.1 defines which character strings are well-formed service	 
> Section 8.1 defines which character strings are well-formed service	
> 	names, which until now had not been clearly defined. The definition	 
> names, which until now had not been clearly defined. The definition	
> 	in Section 8.1 was chosen to allow maximum compatibility of service		in 
> Section 8.1 was chosen to allow maximum compatibility of service	
> 	names with current and future service discovery mechanisms.		names with 
> current and future service discovery mechanisms.	
> 				
> 	As of August 5, 2009 approximately 98% of the so-called "Short Names"	 
> As of August 5, 2009 approximately 98% of the so-called "Short Names"	
> 	from existing port number registrations [PORTREG] meet the rules for	 
> from existing port number registrations [PORTREG] meet the rules for	
> 	legal service names stated in Section 8.1, and hence will be used	 
> legal service names stated in Section 8.1, and hence will be used	
> 	unmodified.		unmodified.	
> 				
> 	The remaining approximately 2% of the exiting "Short Names" are not	 
> The remaining approximately 2% of the exiting "Short Names" are not	
> 	suitable to be used directly as well-formed service names because	 
> suitable to be used directly as well-formed service names because	
> 	they contain illegal characters such as asterisks, dots, plusses,		they 
> contain illegal characters such as asterisks, dots, pluses,	
> 	slashes, or underscores. All existing "Short Names" conform to the	 
> slashes, or underscores. All existing "Short Names" conform to the	
> 	length requirement of 15 characters or fewer. For these unsuitable	 
> length requirement of 15 characters or fewer. For these unsuitable	
> 	"Short Names", listed in the table below, the service name will be	 
> "Short Names", listed in the table below, the service name will be	
> 	the Short Name with any illegal characters replaced by hyphens. IANA	 
> the Short Name with any illegal characters replaced by hyphens. IANA	
> 	SHALL add an entry to the registry giving the new well-formed primary	 
> SHALL add an entry to the registry giving the new well-formed primary	
> 	service name for the existing service, that otherwise duplicates the	 
> service name for the existing service, that otherwise duplicates the	
> 	original assignment information. In the description field of this	 
> original assignment information. In the description field of this	
> 	new entry giving the primary service name, IANA SHALL record that it	 
> new entry giving the primary service name, IANA SHALL record that it	
> 	assigns a well-formed service name for the previous service and	 
> assigns a well-formed service name for the previous service and	
> 	reference the original assignment. In the description field of the	 
> reference the original assignment. In the description field of the	
> 				
> 	skipping to change at/ page 25, line 22/		skipping to change at/ page 
> 26, line 22/	
> 	specification [RFC4340]. Allocations in this registry require prior	 
> specification [RFC4340]. Allocations in this registry require prior	
> 	allocation of a Service Code. Not all Service Codes require IANA-	 
> allocation of a Service Code. Not all Service Codes require IANA-	
> 	registered ports. This document updates that section by extending	 
> registered ports. This document updates that section by extending	
> 	the guidelines given there in the following way:		the guidelines given 
> there in the following way:	
> 				
> 	o IANA should normally assign a value in the range 1024-49151 to a		o 
> IANA should normally assign a value in the range 1024-49151 to a	
> 	DCCP server port. IANA allocation requests to allocate port		DCCP 
> server port. IANA allocation requests to allocate port	
> 	numbers in the Well Known Ports range (0 through 1023), require an	 
> numbers in the Well Known Ports range (0 through 1023), require an	
> 	"IETF Review" [RFC5226] prior to allocation by IANA [RFC4340].		"IETF 
> Review" [RFC5226] prior to allocation by IANA [RFC4340].	
> 				
> 	o IANA MUST NOT allocate a single Service Code value to more than		o 
> IANA MUST NOT allocate more than one DCCP server port to a single	
> 	one DCCP server port.		service code value.	
> 				
> 			o The allocation of multiple service codes to the same DCCP port is	
> 			allowed, but subject to expert review.	
> 				
> 	o The set of Service Code values associated with a DCCP server port		o 
> The set of Service Code values associated with a DCCP server port	
> 	should be recorded in the ports registry.		should be recorded in the 
> ports registry.	
> 				
> 	o A request for additional Service Codes to be associated with an		o A 
> request for additional Service Codes to be associated with an	
> 	already allocated Port Number requires Expert Review. These		already 
> allocated Port Number requires Expert Review. These	
> 	requests will normally be accepted when they originate from the	 
> requests will normally be accepted when they originate from the	
> 	contact associated with the port registration. In other cases,		contact 
> associated with the port registration. In other cases,	
> 	these applications will be expected to use an unallocated port,		these 
> applications will be expected to use an unallocated port,	
> 	when this is available.		when this is available.	
> 				
> 	skipping to change at/ page 25, line 47/		skipping to change at/ page 
> 26, line 50/	
> 	document requires that this name MUST be unique.		document requires 
> that this name MUST be unique.	
> 				
> 	11. Contributors		11. Contributors	
> 				
> 	Stuart Cheshire ([email-masked]), Alfred Hoenes ([email-masked])	 
> Stuart Cheshire ([email-masked]), Alfred Hoenes ([email-masked])	
> 	and Allison Mankin ([email-masked]) have contributed text and ideas	 
> and Allison Mankin ([email-masked]) have contributed text and ideas	
> 	to this document.		to this document.	
> 				
> 	12. Acknowledgments		12. Acknowledgments	
> 				
> 	The text in Section 10.3 is based on a suggestion by Tom Phelan.		The 
> text in Section 10.3 is based on a suggestion originally proposed	
> 			as a part of [RFC5595] by Gorry Fairhurst.	
> 				
> 	Lars Eggert is partly funded by the Trilogy Project [TRILOGY], a		Lars 
> Eggert is partly funded by the Trilogy Project [TRILOGY], a	
> 	research project supported by the European Commission under its	 
> research project supported by the European Commission under its	
> 	Seventh Framework Program.		Seventh Framework Program.	
> 				
> 	13. References		13. References	
> 				
> 	13.1. Normative References		13.1. Normative References	
> 				
> 	[ANSI.X3-4.1986]		[ANSI.X3-4.1986]	
> 				
> 	skipping to change at/ page 27, line 9/		skipping to change at/ page 
> 28, line 10/	
> 	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA 
> Considerations Section in RFCs", BCP 26, RFC 5226,	
> 	May 2008.		May 2008.	
> 				
> 	[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax	 
> [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax	
> 	Specifications: ABNF", STD 68, RFC 5234, January 2008.		Specifications: 
> ABNF", STD 68, RFC 5234, January 2008.	
> 				
> 	13.2. Informative References		13.2. Informative References	
> 				
> 	[I-D.cheshire-dnsext-dns-sd]		[I-D.cheshire-dnsext-dns-sd]	
> 	Cheshire, S. and M. Krochmal, "DNS-Based Service		Cheshire, S. and M. 
> Krochmal, "DNS-Based Service	
> 	Discovery", draft-cheshire-dnsext-dns-sd-05 (work in		Discovery", 
> draft-cheshire-dnsext-dns-sd-06 (work in	
> 	progress), September 2008.		progress), March 2010.	
> 				
> 	[I-D.cheshire-nat-pmp]		[I-D.cheshire-nat-pmp]	
> 	Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)",		Cheshire, S., 
> "NAT Port Mapping Protocol (NAT-PMP)",	
> 	draft-cheshire-nat-pmp-03 (work in progress), April 2008.	 
> draft-cheshire-nat-pmp-03 (work in progress), April 2008.	
> 				
> 	[I-D.gudmundsson-dnsext-srv-clarify]		[I-D.gudmundsson-dnsext-srv-clarify]	
> 	Gudmundsson, O. and A. Hoenes, "Clarification of DNS SRV		Gudmundsson, 
> O. and A. Hoenes, "Clarification of DNS SRV	
> 	Owner Names", draft-gudmundsson-dnsext-srv-clarify-00		Owner Names", 
> draft-gudmundsson-dnsext-srv-clarify-00	
> 	(work in progress), December 2009.		(work in progress), December 2009.	
> 				
> 				
> 	skipping to change at/ page 28, line 16/		skipping to change at/ page 
> 29, line 19/	
> 	Datagram Congestion Control Protocol (DCCP) Congestion		Datagram 
> Congestion Control Protocol (DCCP) Congestion	
> 	Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342,		Control ID 
> 3: TCP-Friendly Rate Control (TFRC)", RFC 4342,	
> 	March 2006.		March 2006.	
> 				
> 	[RFC4960] Stewart, R., "Stream Control Transmission Protocol",	 
> [RFC4960] Stewart, R., "Stream Control Transmission Protocol",	
> 	RFC 4960, September 2007.		RFC 4960, September 2007.	
> 				
> 	[RFC5237] Arkko, J. and S. Bradner, "IANA Allocation Guidelines for	 
> [RFC5237] Arkko, J. and S. Bradner, "IANA Allocation Guidelines for	
> 	the Protocol Field", BCP 37, RFC 5237, February 2008.		the Protocol 
> Field", BCP 37, RFC 5237, February 2008.	
> 				
> 			[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,	
> 			"Session Traversal Utilities for NAT (STUN)", RFC 5389,	
> 			October 2008.	
> 				
> 	[RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol	 
> [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol	
> 	(DCCP) Service Codes", RFC 5595, September 2009.		(DCCP) Service 
> Codes", RFC 5595, September 2009.	
> 				
> 			[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using	
> 			Relays around NAT (TURN): Relay Extensions to Session	
> 			Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.	
> 				
> 	[SRVREG] "DNS SRV Service Types Registry",		[SRVREG] "DNS SRV Service 
> Types Registry",	
> 	http://www.dns-sd.org/ServiceTypes.html.	 
> http://www.dns-sd.org/ServiceTypes.html.	
> 				
> 	[SYSFORM] Internet Assigned Numbers Authority (IANA), "Application	 
> [SYSFORM] Internet Assigned Numbers Authority (IANA), "Application	
> 	for System (Well Known) Port Number",		for System (Well Known) Port 
> Number",	
> 	http://www.iana.org/cgi-bin/sys-port-number.pl.	 
> http://www.iana.org/cgi-bin/sys-port-number.pl.	
> 				
> 	[TRILOGY] "Trilogy Project", http://www.trilogy-project.org/.	 
> [TRILOGY] "Trilogy Project", http://www.trilogy-project.org/.	
> 				
> 	[USRFORM] Internet Assigned Numbers Authority (IANA), "Application	 
> [USRFORM] Internet Assigned Numbers Authority (IANA), "Application	
> 	for User (Registered) Port Number",		for User (Registered) Port Number",	
> 	http://www.iana.org/cgi-bin/usr-port-number.pl.	 
> http://www.iana.org/cgi-bin/usr-port-number.pl.	
> 				
> 	Authors' Addresses		Authors' Addresses	
> 				
> 			Stuart Cheshire	
> 			Apple Inc.	
> 			1 Infinite Loop	
> 			Cupertino, CA 95014	
> 			USA	
> 				
> 			Phone: +1 408 974 3207	
> 			Email: [email-masked]	
> 				
> 	Michelle Cotton		Michelle Cotton	
> 	Internet Corporation for Assigned Names and Numbers		Internet 
> Corporation for Assigned Names and Numbers	
> 	4676 Admiralty Way, Suite 330		4676 Admiralty Way, Suite 330	
> 	Marina del Rey, CA 90292		Marina del Rey, CA 90292	
> 	USA		USA	
> 				
> 	Phone: +1 310 823 9358		Phone: +1 310 823 9358	
> 	Email: [email-masked]		Email: [email-masked]	
> 	URI: http://www.iana.org/		URI: http://www.iana.org/	
> 				
> 	Lars Eggert		Lars Eggert	
> 	Nokia Research Center		Nokia Research Center	
> 	P.O. Box 407		P.O. Box 407	
> 	Nokia Group 00045		Nokia Group 00045	
> 	Finland		Finland	
> 				
> 	Phone: +358 50 48 24461		Phone: +358 50 48 24461	
> 	Email: [email-masked]		Email: [email-masked]	
> 	URI: http://research.nokia.com/people/lars_eggert/		URI: 
> http://research.nokia.com/people/lars_eggert/	
> 				
> 				
>  End of changes. 50 change blocks. 
> 	/122 lines changed or deleted/	/ /	/191 lines changed or added/	
> 
> This html diff was produced by rfcdiff 1.38. The latest version is 
> available from http://tools.ietf.org/tools/rfcdiff/ 
> <http://www.tools.ietf.org/tools/rfcdiff/>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Port-srv-reg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/port-srv-reg

---

From: Lars Eggert <[email-masked]>
Date: Thu, 20 May 2010 15:50:43 +0300

> I'd be VERY happy to see this submitted.

OK, unless someone yells, I'll submit this COB today.

Lars

---

From: Joe Touch <[email-masked]>
Date: Thu, 20 May 2010 09:48:49 -0700

Some bugs:

<old>
IANA will allocate port numbers only for the transport protocol(s)	
	(if any) explicitly named in an registration request
<new>
IANA will allocate port numbers only for the transport protocol(s)	
	explicitly named in an registration request

Joe

---

From: Lars Eggert <[email-masked]>
Date: Thu, 20 May 2010 20:54:23 +0300

Applied