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

[Gorry Fairhurst <[e-mail]>]

I'd be VERY happy to see this submitted.

Gorry

Lars Eggert wrote:
> 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
> 
> 
> 
> ------------------------------------------------------------------------
> 
> 	 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)	
> 			Transport Protocol(s) (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)	
> 	Transport Protocol(s) (REQUIRED if port number requested)			
> 	Service Code (only REQUIRED for DCCP)		Service Code (only REQUIRED for 
> DCCP)	
> 	Description (REQUIRED)		Description (REQUIRED)	
> 	Reference (REQUIRED)		Reference (REQUIRED)	
> 			Known Unauthorized Uses (OPTIONAL)	
> 			Assignment Notes (OPTIONAL)	
> 				
> 			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 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.	
> 				
> 	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 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.			
> 				
> 	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 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.	
> 				
> 			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 ([e-mail]), Alfred Hoenes ([e-mail])	 
> Stuart Cheshire ([e-mail]), Alfred Hoenes ([e-mail])	
> 	and Allison Mankin ([e-mail]) have contributed text and ideas	 
> and Allison Mankin ([e-mail]) 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: [phone]	
> 			Email: [e-mail]	
> 				
> 	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: [phone]		Phone: [phone]	
> 	Email: [e-mail]		Email: [e-mail]	
> 	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: [phone]		Phone: [phone]	
> 	Email: [e-mail]		Email: [e-mail]	
> 	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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/port-srv-reg