< draft-ietf-tls-iana-registry-updates-01.txt		draft-ietf-tls-iana-registry-updates-02.txt >
	TLS WG J. Salowey		TLS WG J. Salowey
	Internet-Draft Tableau Software		Internet-Draft Tableau Software
	Updates: 3749, 5077, 4680, 5246, 5878, S. Turner		Updates: 3749, 5077, 4680, 5246, 5705, S. Turner
	6520, 7301 (if approved) sn3rd		5878, 6520, 7301 (if approved) sn3rd
	Intended status: Standards Track April 28, 2017		Intended status: Standards Track October 30, 2017
	Expires: October 30, 2017		Expires: May 3, 2018
	D/TLS IANA Registry Updates		IANA Registry Updates for TLS and DTLS
	draft-ietf-tls-iana-registry-updates-01		draft-ietf-tls-iana-registry-updates-02
	Abstract		Abstract
	This document changes the IANA registry policy for a number of		This document describes a number of changes to (D)TLS IANA registries
	registries related to DTLS and TLS, renames some of the registries		that range from adding notes to the registry all the way to changing
	for consistency, and adds notes to many of the registries. As a		the registration policy. These changes were mostly motivated by WG
	result, this document updates many RFCs (see updates header).		review of the (D)TLS-related registries undertaken as part of the
			TLS1.3 development process. This document updates many (D)TLS RFCs
			(see updates header).
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted 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). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		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."
	This Internet-Draft will expire on October 30, 2017.		This Internet-Draft will expire on May 3, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	skipping to change at page 2, line 12 ¶		skipping to change at page 2, line 13 ¶
	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 Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Process Note . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Process Note . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	3. Add "TLS" to Registry Names . . . . . . . . . . . . . . . . . 3		3. Add "TLS" to Registry Names . . . . . . . . . . . . . . . . . 3
	4. Aligning with RFC 5226 . . . . . . . . . . . . . . . . . . . 4		4. Aligning with RFC 8126 . . . . . . . . . . . . . . . . . . . 3
	5. Session Ticket TLS Extension . . . . . . . . . . . . . . . . 4		5. Adding recommended Column . . . . . . . . . . . . . . . . . . 4
	6. TLS ExtensionType Values . . . . . . . . . . . . . . . . . . 4		6. Session Ticket TLS Extension . . . . . . . . . . . . . . . . 4
	7. TLS Cipher Suite Registry . . . . . . . . . . . . . . . . . . 6		7. TLS ExtensionType Values . . . . . . . . . . . . . . . . . . 4
	8. TLS Supported Groups . . . . . . . . . . . . . . . . . . . . 8		8. TLS Cipher Suite Registry . . . . . . . . . . . . . . . . . . 6
	9. TLS ClientCertificateType Identifiers . . . . . . . . . . . . 8		9. TLS Supported Groups . . . . . . . . . . . . . . . . . . . . 8
	10. New Session Ticket TLS Handshake Message Type . . . . . . . . 8		10. TLS ClientCertificateType Identifiers . . . . . . . . . . . . 9
	11. TLS Exporter Label Registry . . . . . . . . . . . . . . . . . 9		11. New Session Ticket TLS Handshake Message Type . . . . . . . . 10
	12. Add Missing Item to TLS Alert Registry . . . . . . . . . . . 9		12. TLS Exporter Label Registry . . . . . . . . . . . . . . . . . 10
	13. TLS Certificate Types . . . . . . . . . . . . . . . . . . . . 9		13. Add Missing Item to TLS Alert Registry . . . . . . . . . . . 11
	14. Orphaned Extensions . . . . . . . . . . . . . . . . . . . . . 10		14. TLS Certificate Types . . . . . . . . . . . . . . . . . . . . 11
	15. Orphaned Registries . . . . . . . . . . . . . . . . . . . . . 10		15. Orphaned Extensions . . . . . . . . . . . . . . . . . . . . . 12
	16. Designated Expert Pool . . . . . . . . . . . . . . . . . . . 10		16. Orphaned Registries . . . . . . . . . . . . . . . . . . . . . 12
	17. Security Considerations . . . . . . . . . . . . . . . . . . . 11		17. Designated Expert Pool . . . . . . . . . . . . . . . . . . . 13
	18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		18. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	19. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	19.1. Normative References . . . . . . . . . . . . . . . . . . 11		20. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	19.2. Informative References . . . . . . . . . . . . . . . . . 12		20.1. Normative References . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		20.2. Informative References . . . . . . . . . . . . . . . . . 15
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Process Note		1. Process Note
	As the authors of this draft are also the WG chairs, the responsible		As the authors of this draft are also the WG chairs, the responsible
	Area Director has agreed to judge consensus.		Area Director has agreed to judge consensus.
	RFC EDITOR: Please delete section prior to publication.		RFC EDITOR: Please delete section prior to publication.
	2. Introduction		2. Introduction
	This document requests that IANA make changes to a number of DTLS-		This document instructs IANA to make changes to a number of (D)TLS-
	and TLS-related IANA registries.		related IANA registries. These changes were almost entirely
			motiviated by the development of TLS1.3 [I-D.ietf-tls-tls13].
	In this document, we use the term "(D)TLS" to refer to registries
	that apply to both TLS and DTLS.
	o Add "TLS" to registries' names for consistency amongst TLS-related
	registries.
	o Change the IANA registry policy [RFC5226] for the TLS
	ExtensionType Values, TLS Cipher Suite, and TLS
	ClientCertificateType Identifiers registries. These changes
	register a small part of these code spaces for experimentation and
	private use.
	o Add designated expert instructions as notes in the TLS
	ExtensionType Values, TLS Cipher Suite, TLS ClientCertificateType
	Identifiers, and TLS Exporter Label registries to inform users
	about what to expect from the designated expert.
	o Add notes to indicate whether an extension, certain values of an
	extension, or an entire registry is only applicable pre-(D)TLS
	1.3.
	o Rename the NewSessionTicket TLS HandshakeType message registry
	entry [RFC5077] to new_session_ticket to match the naming
	nomenclature for the other Handshake type names and to match with
	existing implementations.
	o Rename the SessionTicket TLS extension to session_ticket to match
	the nomenclature for the other extensions' names.
	o Add missing entry to the TLS Alert Registry for the
	no_application_protocol alert defined in [RFC7301].
	o Added "Recommended" column to TLS ExtensionType Values, TLS Cipher
	Suite, TLS Certificate Types, TLS Supported Groups, and TLS
	Exporters Label registries. Initial values marked "Yes" are
	specified in IETF Standards Track documents; all others are marked
	"No". This new column is intended to alter the incorrect
	perception that getting a code point somehow legitimizes the
	extension, cipher suite/algorithm, or exporter.
	o Establish Designated Expert pool rules for Specification Required		The changes introduced by this document range from simple, e.g.,
	registries.		adding notes, to commplex, e.g., changing a registry's registration
			policy. Intsead of listing the changes and their rationale in this,
			the introducotry, section each section provides rationale for the
			proposed change(s).
	This document proposes no changes to the registration policies for		This document proposes no changes to the registration policies for
	TLS Alert [I-D.ietf-tls-tls13], TLS ContentType [I-D.ietf-tls-tls13],		TLS Alert [I-D.ietf-tls-tls13], TLS ContentType [I-D.ietf-tls-tls13],
	TLS HandshakeType, [I-D.ietf-tls-tls13] and TLS Certificate Status		TLS HandshakeType [I-D.ietf-tls-tls13], and TLS Certificate Status
	Types [RFC6961]; the existing policies (Standards Action for the		Types [RFC6961] registries; the existing policies (Standards Action
	first three; IETF Review for the last), are appropriate for these		for the first three; IETF Review for the last), are appropriate for
	one-byte code points because of their scarcity.		these one-byte code points because of their scarcity.
	3. Add "TLS" to Registry Names		3. Add "TLS" to Registry Names
	IANA is to update the names of the following registries to add "TLS"		For consistency amongst TLS reqgistries, IANA [SHALL prepend/has
	to for consistency with the other TLS-related extensions:		prepended] "TLS" to the following registries:
	o Application-Layer Protocol Negotiation (ALPN) Protocol IDs,		o Application-Layer Protocol Negotiation (ALPN) Protocol IDs
	o ExtensionType Values,		[RFC7301],
	o Heartbeat Message Types,		o ExtensionType Values,
	o Heartbeat Modes, and		o Heartbeat Message Types [RFC6520], and
	o Supported Groups.		o Heartbeat Modes [RFC6520].
	IANA is also to add a reference to this document for the registry		IANA [SHALL update/has updated] the reference for these four
	whose names have been updated as a result of the above change. The		registires to also refer to this document. The remainder of this
	remainder of this document will use the registry names with the "TLS"		document will use the registry names with the "TLS" prefix.
	prefix.
	4. Aligning with RFC 5226		4. Aligning with RFC 8126
	Many of the TLS-related IANA registries were defined prior to		Many of the TLS-related IANA registries were defined prior to
	[RFC5226] where "IETF Consensus" was used instead of the		[RFC8126] where "IETF Consensus" was used instead of the
	RFC5226-defined "IETF Review". To align with the new terminology,		RFC8126-defined "IETF Review". To align with the new terminology,
	IANA is to update to use "IETF Review" in place of "IETF Consensus"		IANA [SHALL update/has updated] the following registries to use "IETF
	in the following registries:		Review" in place of "IETF Consensus":
	o TLS Authorization Data Formats		o TLS Authorization Data Formats [RFC4680]
	o TLS Supplemental Data Formats (SupplementalDataType)		o TLS Supplemental Data Formats (SupplementalDataType) [RFC5878]
	This is not a universal change as some registries originally defined		This is not a universal change as some registries originally defined
	with "IETF Consensus" are undergoing other changes either as a result		with "IETF Consensus" are undergoing other changes either as a result
	of this document or [I-D.ietf-tls-rfc4492bis].		of this document or [I-D.ietf-tls-rfc4492bis].
	5. Session Ticket TLS Extension		IANA [SHALL update/has updated] the reference for these two
			registries to also refer to this document.
			5. Adding recommended Column
			The instructions in this document add a recommended column to many of
			the TLS registries to indicate parameters that are generally
			recommended for implementations to support. Adding a recommended
			parameter to a registry or updating a parameter to recommended status
			requires standards action. Not all parameters defined in standards
			track documents need to be marked as recommended.
			If an item is marked as not recommended it does not necessarily mean
			that it is flawed, rather, it indicates that either the item has not
			been through the IETF consensus process, has limited applicability,
			or is intended only for specific use cases.
			6. Session Ticket TLS Extension
	The nomenclature for the registry entries in the TLS ExtensionType		The nomenclature for the registry entries in the TLS ExtensionType
	Values registry correspond to the presentation language field name		Values registry correspond to the presentation language field name
	except for entry 35. To ensure that the values in the registry are		except for entry 35. To ensure that the values in the registry are
	consistently identified in the registry, IANA is to rename entry 35		consistently identified in the registry, IANA:
	to "session_ticket (renamed from "SessionTicket TLS")".
	6. TLS ExtensionType Values		o [SHALL rename/has renamed] entry 35 to "session_ticket (renamed
			from "SessionTicket TLS")" [RFC5077].
	IANA is to update the TLS ExtensionType Values registry as follows:		o [SHALL add/has added] a reference to this document in the
			Reference column for entry 35.
			7. TLS ExtensionType Values
			Experience has shown that the IETF Review registry policy for TLS
			Extensions was too strict. Based on WG consensus, the decision was
			taken to change the registration policy to Specification Required
			[RFC8126] while reserving a small part of the code space for
			experimental and prviate use. Therefore, IANA [SHALL update/has
			updated] the TLS ExtensionType Values registry to:
	o Change the registry policy to:		o Change the registry policy to:
	Values with the first byte in the range 0-254 (decimal) are		Values with the first byte in the range 0-254 (decimal) are
	assigned via Specification Required [RFC5226]. Values with the		assigned via Specification Required [RFC8126]. Values with the
	first byte 255 (decimal) are reserved for Private Use [RFC5226].		first byte 255 (decimal) are reserved for Private Use [RFC8126].
	o Update the "References" to also refer to this document.		o Update the "Reference" to also refer to this document.
	o Add the following note:		o Add the following note:
	Note: Experts are to verify that there is in fact a publicly		Note: Experts are to verify that there is in fact a publicly
	available standard.		available standard.
			See Section 17 for additional information about the designated expert
			pool.
			Despite wanting to "loosen" the registration policies for TLS
			Extensions, it is still useful to indicate in the IANA registry which
			extensions the WG recommends be supported. Therefore, IANA [SHALL
			update/has updated] the TLS ExtensionType Values registry to:
	o Add a "Recommended" column with the contents as listed below.		o Add a "Recommended" column with the contents as listed below.
	This table has been generated by marking Standards Track RFCs as		This table has been generated by marking Standards Track RFCs as
	"Yes" and all others as "No". Future extensions MUST define the		"Yes" and all others as "No". Future extensions MUST define the
	value of this column. A Standards Track document [RFC5226] is		value of the Recommended column. A Standards Track document
	required to register an extension with the value "Yes".		[RFC8126] is required to register an extension with the value
			"Yes".
	+----------------------------------------+-------------+		+----------------------------------------+-------------+
	| Extension | Recommended |		| Extension | Recommended |
	+----------------------------------------+-------------+		+----------------------------------------+-------------+
	| server_name | Yes |		| server_name | Yes |
	| | |		| | |
	| max_fragment_length | Yes |		| max_fragment_length | Yes |
	| | |		| | |
	| client_certificate_url | Yes |		| client_certificate_url | Yes |
	| | |		| | |
	skipping to change at page 6, line 23 ¶		skipping to change at page 6, line 27 ¶
	| | |		| | |
	| encrypt_then_mac | Yes |		| encrypt_then_mac | Yes |
	| | |		| | |
	| extended_master_secret | Yes |		| extended_master_secret | Yes |
	| | |		| | |
	| session_ticket | Yes |		| session_ticket | Yes |
	| | |		| | |
	| renegotiation_info | Yes |		| renegotiation_info | Yes |
	+----------------------------------------+-------------+		+----------------------------------------+-------------+
	7. TLS Cipher Suite Registry		8. TLS Cipher Suite Registry
	IANA is to update the TLS Cipher Suite registry as follows:		Experience has shown that the IETF Consensus registry policy for TLS
			Cipher Suites was too strict. Based on WG consensus, the decision
			was taken to change the TLS Cipher Suite registry's registration
			policy to Specification Required [RFC8126] while reserving a small
			part of the code space for experimental and prviate use. Therefore,
			IANA [SHALL update/has updated] the TLS Cipher Suite registry's
			policy as follows:
	o Change the registry policy to:		Values with the first byte in the range 0-254 (decimal) are assigned
			via Specification Required {{RFC8126}}. Values with the first byte
			255 (decimal) are reserved for Private Use {{RFC8126}}.
	Values with the first byte in the range 0-254 (decimal) are		See Section 17 for additional information about the designated expert
	assigned via Specification Required [RFC5226]. Values with the		pool.
	first byte 255 (decimal) are reserved for Private Use [RFC2434].
	o Add a "Recommended" column to the cipher suite registry. The		The cipher suite registry has grown significantly and will continue
			to do so. To better guide those not intimately involved in TLS, IANA
			[shall update/has updated] the TLS Cipher Suite registry as follows:
			o Add a "Recommended" column to the TLS Cipher Suite registry. The
	cipher suites that follow in the two tables are marked as "Yes".		cipher suites that follow in the two tables are marked as "Yes".
	All other cipher suites are marked as "No". Future cipher suites		All other cipher suites are marked as "No". Future cipher suites
	MUST define the value of the Recommended column. A Standards		MUST define the value of the Recommended column. A Standards
	Track document [RFC5226] is required to register a cipher suite		Track document [RFC8126] is required to register a cipher suite
	with the value "Yes".		with the value "Yes".
	o Update the reference for this registry to also point to this		The cipher suites that follow are standards track server-
	document.		authenticated (and optionally client-authenticated) cipher suites
			which are currently available in TLS 1.2.
	The cipher suites that follow are standards track server-
	authenticated (and optionally client-authenticated) cipher suites
	which are currently available in TLS 1.2. The notable exception are
	the ECDHE AES GCM cipher suites which are not yet standards track
	prior to the publication of this specification, but this document
	promotes those 4 cipher suites to standards track (see TO-DO insert
	reference).
	RFC EDITOR: Please delete the sentence beginning with "The notable		RFC EDITOR: The previous paragraph is for document reviewers and is
	exception ..." after RFC 5289 has been promoted to Proposed Standard.		not meant for the registry.
	Cipher Suite Name | Value		Cipher Suite Name | Value
	----------------------------------------------+------------		----------------------------------------------+------------
	TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | {0x00,0x9E}		TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | {0x00,0x9E}
	TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | {0x00,0x9F}		TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | {0x00,0x9F}
	TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | {0xC0,0x2B}		TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | {0xC0,0x2B}
	TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | {0xC0,0x2C}		TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | {0xC0,0x2C}
	TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | {0xC0,0x2F}		TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | {0xC0,0x2F}
	TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | {0xC0,0x30}		TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | {0xC0,0x30}
	TLS_DHE_RSA_WITH_AES_128_CCM | {0xC0,0x9E}		TLS_DHE_RSA_WITH_AES_128_CCM | {0xC0,0x9E}
	TLS_DHE_RSA_WITH_AES_256_CCM | {0xC0,0x9F}		TLS_DHE_RSA_WITH_AES_256_CCM | {0xC0,0x9F}
	TLS_DHE_RSA_WITH_AES_128_CCM_8 | {0xC0,0xA2}
	TLS_DHE_RSA_WITH_AES_256_CCM_8 | {0xC0,0xA3}
	TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xA8}		TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xA8}
	TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xA9}		TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xA9}
	TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xAA}		TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xAA}
	The cipher suites that follow are standards track ephemeral pre-		The cipher suites that follow are standards track ephemeral pre-
	shared key cipher suites which are available in TLS 1.2. [RFC6655]		shared key cipher suites which are available in TLS 1.2. [RFC6655]
	is inconsistent with respect to the ordering of components within PSK		is inconsistent with respect to the ordering of components within PSK
	AES CCM cipher suite names; those names are used here without		AES CCM cipher suite names; those names are used here without
	modification.		modification.
			RFC EDITOR: The previous paragraph is for document reviewers and is
			not meant for the registry.
	Cipher Suite Name | Value		Cipher Suite Name | Value
	----------------------------------------------+------------		----------------------------------------------+------------
	TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | {0x00,0xAA}		TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | {0x00,0xAA}
	TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | {0x00,0xAB}		TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | {0x00,0xAB}
	TLS_DHE_PSK_WITH_AES_128_CCM | {0xC0,0xA6}		TLS_DHE_PSK_WITH_AES_128_CCM | {0xC0,0xA6}
	TLS_DHE_PSK_WITH_AES_256_CCM | {0xC0,0xA7}		TLS_DHE_PSK_WITH_AES_256_CCM | {0xC0,0xA7}
	TLS_PSK_DHE_WITH_AES_128_CCM_8 | {0xC0,0xAA}
	TLS_PSK_DHE_WITH_AES_256_CCM_8 | {0xC0,0xAB}
	TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 | {TBD}		TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 | {TBD}
	TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 | {TBD}		TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 | {TBD}
	TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 | {TBD}
	TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 | {TBD}		TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 | {TBD}
	TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 | {TBD}		TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 | {TBD}
	TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xAC}		TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xAC}
	TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xAD}		TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xAD}
	o Add the following:		Despite the following behavior being crazy, experience has shown that
			some customers use the IANA registry as checklist against which to
			measure an implemention's completeness and some implementers blindly
			implement cipher suites. Therefore, IANA [SHALL add/has added] the
			following warning to the registry:
	WARNING: Cryptographic algorithms will be broken or weakened over		WARNING: Cryptographic algorithms and parameters will be broken or
	time. Blindly implementing cipher suites listed here is not		weakened over time. Blindly implementing cipher suites listed
	advised. Implementers and users need to check that the		here is not advised. Implementers and users need to check that
	cryptographic algorithms listed continue to provide the expected		the cryptographic algorithms listed continue to provide the
	level of security.		expected level of security.
	Note(1): Although TLS 1.3 uses the same cipher suite space as		IANA [SHALL add/has added] the following note to ensure that those
	previous versions of TLS, TLS 1.3 cipher suites are defined		that focus on IANA registries are aware that TLS 1.3
	differently, only specifying the symmetric ciphers, and cannot be		[I-D.ietf-tls-tls13] uses the same registry but defines ciphers
	used for TLS 1.2. Similarly, TLS 1.2 and lower cipher suites		differently:
	cannot be used with TLS 1.3.
	Note(2): Cipher suites marked as "Yes" are those allocated via		Note: Although TLS 1.3 uses the same cipher suite space as previous
			versions of TLS, TLS 1.3 cipher suites are defined differently,
			only specifying the symmetric ciphers, and cannot be used for TLS
			1.2. Similarly, TLS 1.2 and lower cipher suite values cannot be
			used with TLS 1.3.
			IANA [SHALL add/has added] the following notes to document the rules
			for populating the Recommended column:
			Note: Cipher suites marked as "Yes" are those allocated via
	Standards Track RFCs. Cipher suites marked as "No" are not;		Standards Track RFCs. Cipher suites marked as "No" are not;
	cipher suites marked "No" range from "good" to "bad" from a		cipher suites marked "No" range from "good" to "bad" from a
	cryptographic standpoint.		cryptographic standpoint.
	Note(3): The designated expert [RFC5226] only ensures that the		Note: CCM_8 cipher suites are not marked as Recommended. These
			cipher suites have a significantly truncated authentication tag
			that represents a security trade-off that may not be appropriate
			for general environments.
			Note: The designated expert [RFC8126] only ensures that the
	specification is publicly available.		specification is publicly available.
	8. TLS Supported Groups		IANA [SHALL uppdate/has updated] the reference for this registry to
			also refer to this document.
	Add a "Recommended" column with a "Yes" for secp256r1, secp384r1,		9. TLS Supported Groups
	x25519, and x448 while all others are "No". These "Yes" groups are
	taken from Standards Track RFCs. Not all groups from		Similar to cipher suites, supported groups have proliferated over
	[I-D.ietf-tls-rfc4492bis], which is standards track, are not marked		time and some use the registry to measure implementations.
	as "Yes"; these groups apply to TLS 1.3 [I-D.ietf-tls-tls13] and		Therefore, IANA [SHALL add/has added] a "Recommended" column with a
	previous versions of TLS [I-D.ietf-tls-tls13]. A Standards Track		"Yes" for secp256r1, secp384r1, x25519, and x448 while all others are
	document [RFC5226] is required to register an entry with the value		"No". These "Yes" groups are taken from Standards Track RFCs. Not
			all groups from [I-D.ietf-tls-rfc4492bis], which is standards track,
			are marked as "Yes"; these groups apply to TLS 1.3
			[I-D.ietf-tls-tls13] and previous versions of TLS. Future supported
			groups MUST define the value of this column. A Standards Track
			document [RFC8126] is required to register an entry with the value
	"Yes".		"Yes".
	9. TLS ClientCertificateType Identifiers		IANA [SHALL add/has added] the following note:
	IANA is to update the TLS ClientCertificateType Identifiers registry		Note: Supported Groups marked as "Yes" are those allocated via
	as follows:		Standards Track RFCs. Supported Groups marked as "No" are not;
			supported groups marked "No" range from "good" to "bad" from a
			cryptographic standpoint.
	o Change the registry policy to:		Note: The designated expert [RFC8126] only ensures that the
			specification is publicly available.
	Values in the range 0-223 are assigned via Specification Required		Despite the following behavior being crazy, experience has shown that
	[RFC5226]. Values 224-255 are reserved for Private Use.		some customers use the IANA registry as checklist against which to
			measure an implemention's completeness and some implementers blindly
			implement cipher supported. Therefore, IANA [SHALL add/has added]
			the following warning to the registry:
	o Add the following:		WARNING: Cryptographic algorithms and parameters will be broken or
			weakened over time. Blindly implementing cipher suites listed
			here is not advised. Implementers and users need to check that
			the cryptographic algorithms listed continue to provide the
			expected level of security.
	Note: The designated expert [RFC5226] only ensures that the		IANA [SHALL update/has updated] the reference for this registry to
			also refer to this document.
			The value 0 (0x0000) is to be marked as reserved.
			10. TLS ClientCertificateType Identifiers
			Experience has shown that the IETF Consensus registry policy for TLS
			ClientCertificateType Identifers is too strict. Based on WG
			consensus, the decision was taken to change registration policy to
			Specification Required [RFC8126] while reserving a small part of the
			code space for experimental and prviate use. Therefore, IANA [SHALL
			update/has updated] the TLS Cipher Suite registry's policy as
			follows:
			Values in the range 0-223 are assigned via Specification Required
			{{RFC8126}}. Values 224-255 are reserved for Private Use.
			See Section 17 for additional information about the designated expert
			pool.
			IANA [SHALL add/has added] the following notes:
			Note: The designated expert [RFC8126] only ensures that the
	specification is publicly available.		specification is publicly available.
	10. New Session Ticket TLS Handshake Message Type		Note: ClientCertificateType Identifers marked as "Yes" are those
			allocated via Standards Track RFCs. ClientCertificateTypes marked
			as "No" are not.
			11. New Session Ticket TLS Handshake Message Type
	To align with TLS implementations and to align the naming		To align with TLS implementations and to align the naming
	nomenclature for other Handshake message types, IANA is to rename		nomenclature with other Handshake message types, IANA:
	entry 4 in the TLS HandshakeType registry to "new_session_ticket
	(renamed from NewSessionTicket)". IANA is to also add a reference to
	this document in the Reference column for entry 4 in the TLS
	HandshakeType registry.
	11. TLS Exporter Label Registry		o [SHALL rename/has renamed] entry 4 in the TLS HandshakeType
			registry to "new_session_ticket (renamed from NewSessionTicket)"
			[RFC5077].
	IANA is to add the following note to the TLS Exporter Label Registry:		o [SHALL add/has added] a reference to this document in the
			Reference column for entry 4 in the TLS HandshakeType registry.
	Note: {{RFC5705}} defines keying material exporters for TLS in terms of the TLS PRF. {{I-D.ietf-tls-tls13}} replaced the PRF with HKDF, thus requiring a new construction. The exporter interface remains the same, however the value is computed different.		12. TLS Exporter Label Registry
	IANA is to also to add a "Recommended" column to the TLS Exporter		To aid those reviewers who start with the IANA registry, IANA [SHALL
	Label registry. The table that follows has been generated by marking		add/has added]:
	Standards Track RFCs as "Yes" and all others as "No". Future
	exporters MUST define the value of this column. A Standards Track
	document [RFC5226] is required to register an extension with the
	value "Yes".
	IANA is also to add the following note:		o The following note to the TLS Exporter Label Registry:
	Note: The designated expert {{RFC5226}} ensures that the specification is publicly available. The expert also verifies that the label is a string consisting of printable ASCII characters beginning with "EXPORTER". IANA MUST also verify that one label is not a prefix of any other label. For example, labels "key" or "master secretary" are forbidden.		Note: [RFC5705] defines keying material exporters for TLS in terms
			of the TLS PRF. [I-D.ietf-tls-tls13] replaced the PRF with HKDF,
			thus requiring a new construction. The exporter interface remains
			the same, however the value is computed different.
			o A "Recommended" column to the TLS Exporter Label registry. The
			table that follows has been generated by marking Standards Track
			RFCs as "Yes" and all others as "No". Future exporters MUST
			define the value of this column. A Standards Track document
			[RFC8126] is required to register an extension with the value
			"Yes".
	Exporter Value		Exporter Value
	-------------------------------		-------------------------------
	client finished		client finished
	server finished		server finished
	master secret		master secret
	key expansion		key expansion
	client EAP encryption		client EAP encryption
	ttls keying material		ttls keying material
	ttls challenge		ttls challenge
	EXTRACTOR-dtls_srtp		EXTRACTOR-dtls_srtp
	EXPORTER_DTLS_OVER_SCTP		EXPORTER_DTLS_OVER_SCTP
	EXPORTER: teap session key seed		EXPORTER: teap session key seed
	12. Add Missing Item to TLS Alert Registry		To provide additional information for the designated experts, IANA
			[SHALL add/has added] the following note:
	IANA is to add the following entry to the TLS Alert Registry (the		Note: The designated expert [RFC8126] ensures that the specification
	entry was omitted from the IANA instructions in [RFC7301]):		is publicly available. The expert also verifies that the label is
			a string consisting of printable ASCII characters beginning with
			"EXPORTER". IANA MUST also verify that one label is not a prefix
			of any other label. For example, labels "key" or "master
			secretary" are forbidden.
			Note: Exporters Labels marked as "Yes" are those allocated via
			Standards Track RFCs. Exporter Labels marked as "No" are not.
			IANA [SHALL update/has updated] the reference for this registry to
			also refer to this document.
			13. Add Missing Item to TLS Alert Registry
			IANA [SHALL add/has added] the following entry to the TLS Alert
			Registry; the entry was omitted from the IANA instructions in
			[RFC7301]):
	120 no_application_protocol Y [RFC7301]		120 no_application_protocol Y [RFC7301]
	13. TLS Certificate Types		14. TLS Certificate Types
	Add a "Recommended" column to the registry. X.509 and Raw Public Key		Experience has shown that the IETF Consensus registry policy for TLS
	are "Yes". All others are "No". A Standards Track document		Certificate Types is too strict. Based on WG consensus, the decision
	[RFC5226] is required to register a certificate type with the value		was taken to change registration policy to Specification Required
	"Yes".		[RFC8126] while reserving a small part of the code space for
			experimental and prviate use. Therefore, IANA [SHALL add/has added]
			a "Recommended" column to the registry. X.509 and Raw Public Key are
			"Yes". All others are "No". A Standards Track document [RFC8126] is
			required to register a certificate type with the value "Yes". Future
			Certificate Types MUST define the value of this column. A Standards
			Track document [RFC8126] is required to register an entry with the
			value "Yes".
	14. Orphaned Extensions		See Section 17 for additional information about the designated expert
			pool.
			IANA [SHALL add/has added] the following note:
			Note: Certificate Types marked as "Yes" are those allocated via
			Standards Track RFCs. Certificate Types marked as "No" are not.
			IANA [SHALL update/has updated] the reference for this registry to
			also refer this document.
			15. Orphaned Extensions
	To make it clear that (D)TLS 1.3 has orphaned certain extensions		To make it clear that (D)TLS 1.3 has orphaned certain extensions
	(i.e., they are only applicable to version of (D)TLS prior to 1.3),		(i.e., some extensions are only applicable to version of (D)TLS prior
	IANA is to add the following to the TLS ExtensionType Values		to 1.3), IANA [SHALL add/has added] the following note to the TLS
	registry:		ExtensionType Values registry:
	Note: The following extensions are only applicable to (D)TLS protocol vesions prior to 1.3: trusted_ca_keys, truncated_hmac, ec_point_formats, srp, status_request_v2, encrypt_then_mac, extended_master_secret, session_ticket, and renegotiation_info. These are not applicable to DTLS 1.3.		Note: The following extensions are only applicable to (D)TLS
			protocol vesions prior to 1.3: trusted_ca_keys, truncated_hmac,
			ec_point_formats, srp, status_request_v2, encrypt_then_mac,
			extended_master_secret, session_ticket, and renegotiation_info.
			These extensions are not applicable to (D)TLS 1.3.
	15. Orphaned Registries		16. Orphaned Registries
	To make it clear that (D)TLS 1.3 has orphaned certain registries		To make it clear that (D)TLS 1.3 has orphaned certain registries
	(i.e., they are only applicable to version of (D)TLS protocol		(i.e., they are only applicable to version of (D)TLS protocol
	versions prior to 1.3), IANA is to:		versions prior to 1.3), IANA:
	o Add the following to the TLS Compression Method Identifiers		o [SHALL add/has added] the following to the TLS Compression Method
	registry [RFC3749]:		Identifiers registry [RFC3749]:
	Note: Value 0 (NULL) is the only value in this registry applicable		Note: Value 0 (NULL) is the only value in this registry applicable
	to (D)TLS protocol version 1.3 or later.		to (D)TLS protocol version 1.3 or later.
	o Add the following to the TLS HashAlgorithm [RFC5246] and TLS		o [SHALL add/has added] the following to the TLS HashAlgorithm
	SignatureAlgorithm registries [RFC5246]:		[RFC5246] and TLS SignatureAlgorithm registries [RFC5246]:
	Note: The values in this registry are only applicable to (D)TLS		Note: The values in this registry are only applicable to (D)TLS
	protocol versions prior to 1.3.		protocol versions prior to 1.3.
	o Update the "References" in the TLS Compression Method Identifiers,		o [SHALL update/has updated] the "Reference" field in the TLS
	TLS HashAlgorithm [RFC5246] and TLS SignatureAlgorithm registries		Compression Method Identifiers, TLS HashAlgorithm and TLS
	to also refer to this document.		SignatureAlgorithm registries to also refer to this document.
	IANA [SHALL update/has updated] the TLS HashAlgorithm Registry to		o [SHALL update/has updated] the TLS HashAlgorithm Registry to list
	list values 7-223 as "Reserved" and the TLS SignatureAlgorithm		values 7-223 as "Reserved" and the TLS SignatureAlgorithm registry
	registry to list values 4-223 as "Reserved".		to list values 4-223 as "Reserved".
	16. Designated Expert Pool		Despite the fact that the HashAlgorithm and SignarureAlgorithm
			registries are orphaned, it is still import to warn implementers of
			pre-TLS1.3 implmentations about the dangers of blinding implementing
			cryptographic algorithms. Therefore, IANA [SHALL add/has added] the
			following warning to the HashAlgorithm and SignatureAlgorithm:
	Specification Required [RFC5226] registry requests are registered		WARNING: Cryptographic algorithms and parameters will be broken or
			weakened over time. Blindly implementing cipher suites listed
			here is not advised. Implementers and users need to check that
			the cryptographic algorithms listed continue to provide the
			expected level of security.
			17. Designated Expert Pool
			Specification Required [RFC8126] registry requests are registered
	after a three-week review period on the (tbd but maybe tls-reg-		after a three-week review period on the (tbd but maybe tls-reg-
	review@ietf.org) mailing list, on the advice of one or more		review@ietf.org) mailing list, on the advice of one or more
	Designated Experts. However, to allow for the allocation of values		Designated Experts. However, to allow for the allocation of values
	prior to publication, the Designated Experts may approve registration		prior to publication, the Designated Experts may approve registration
	once they are satisfied that such a specification will be published.		once they are satisfied that such a specification will be published.
	Registration requests sent to the mailing list for review SHOULD use		Registration requests sent to the mailing list for review SHOULD use
	an appropriate subject (e.g., "Request to register value in TLS bar		an appropriate subject (e.g., "Request to register value in TLS bar
	registry").		registry").
	skipping to change at page 11, line 31 ¶		skipping to change at page 14, line 13 ¶
	list.		list.
	It is suggested that multiple Designated Experts be appointed who are		It is suggested that multiple Designated Experts be appointed who are
	able to represent the perspectives of different applications using		able to represent the perspectives of different applications using
	this specification, in order to enable broadly informed review of		this specification, in order to enable broadly informed review of
	registration decisions. In cases where a registration decision could		registration decisions. In cases where a registration decision could
	be perceived as creating a conflict of interest for a particular		be perceived as creating a conflict of interest for a particular
	Expert, that Expert SHOULD defer to the judgment of the other		Expert, that Expert SHOULD defer to the judgment of the other
	Experts.		Experts.
	17. Security Considerations		18. Security Considerations
	The authors are fairly certain that there are no security		The change to Specification Required from IETF Review lowers the
	considerations for this document.		amount of review provided by the WG for cipher suites and supported
			groups. This change reflects reality in that the WG essentially
			provided no cryptographic review of the cipher suites or supported
			groups. This was especially true of national cipher suites.
	18. IANA Considerations		Recommended algorithms regarded as secure for general use at the time
			of registration, however, cryptographic algorithms and parameters
			will be broken or weakened over time. It is possible that the
			recommended status in the registry lags behind the most recent
			advances in cryptanalysis. Implementers and users need to check that
			the cryptographic algorithms listed continue to provide the expected
			level of security.
			Designated experts ensure the specification is publicly available.
			They may provide more in depth reviews. Their review should not be
			taken as an endorsement of the cipher suite, extension, supported
			group, etc.
			19. IANA Considerations
	This document is entirely about changes to TLS-related IANA		This document is entirely about changes to TLS-related IANA
	registries.		registries.
	19. References		20. References
	19.1. Normative References		20.1. Normative References
	[I-D.ietf-tls-tls13]		[I-D.ietf-tls-tls13]
	Rescorla, E., "The Transport Layer Security (TLS) Protocol		Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", draft-ietf-tls-tls13-19 (work in progress),		Version 1.3", draft-ietf-tls-tls13-21 (work in progress),
	March 2017.		July 2017.
	[RFC3749] Hollenbeck, S., "Transport Layer Security Protocol		[RFC3749] Hollenbeck, S., "Transport Layer Security Protocol
	Compression Methods", RFC 3749, DOI 10.17487/RFC3749, May		Compression Methods", RFC 3749, DOI 10.17487/RFC3749, May
	2004, <http://www.rfc-editor.org/info/rfc3749>.		2004, <https://www.rfc-editor.org/info/rfc3749>.
	[RFC4680] Santesson, S., "TLS Handshake Message for Supplemental		[RFC4680] Santesson, S., "TLS Handshake Message for Supplemental
	Data", RFC 4680, DOI 10.17487/RFC4680, October 2006,		Data", RFC 4680, DOI 10.17487/RFC4680, October 2006,
	<http://www.rfc-editor.org/info/rfc4680>.		<https://www.rfc-editor.org/info/rfc4680>.
	[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,		[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
	"Transport Layer Security (TLS) Session Resumption without		"Transport Layer Security (TLS) Session Resumption without
	Server-Side State", RFC 5077, DOI 10.17487/RFC5077,		Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
	January 2008, <http://www.rfc-editor.org/info/rfc5077>.		January 2008, <https://www.rfc-editor.org/info/rfc5077>.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	DOI 10.17487/RFC5226, May 2008,
	<http://www.rfc-editor.org/info/rfc5226>.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246,		(TLS) Protocol Version 1.2", RFC 5246,
	DOI 10.17487/RFC5246, August 2008,		DOI 10.17487/RFC5246, August 2008, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc5246>.		editor.org/info/rfc5246>.
	[RFC5705] Rescorla, E., "Keying Material Exporters for Transport		[RFC5705] Rescorla, E., "Keying Material Exporters for Transport
	Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,		Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
	March 2010, <http://www.rfc-editor.org/info/rfc5705>.		March 2010, <https://www.rfc-editor.org/info/rfc5705>.
	[RFC5878] Brown, M. and R. Housley, "Transport Layer Security (TLS)		[RFC5878] Brown, M. and R. Housley, "Transport Layer Security (TLS)
	Authorization Extensions", RFC 5878, DOI 10.17487/RFC5878,		Authorization Extensions", RFC 5878, DOI 10.17487/RFC5878,
	May 2010, <http://www.rfc-editor.org/info/rfc5878>.		May 2010, <https://www.rfc-editor.org/info/rfc5878>.
	[RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport		[RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport
	Layer Security (TLS) and Datagram Transport Layer Security		Layer Security (TLS) and Datagram Transport Layer Security
	(DTLS) Heartbeat Extension", RFC 6520,		(DTLS) Heartbeat Extension", RFC 6520,
	DOI 10.17487/RFC6520, February 2012,		DOI 10.17487/RFC6520, February 2012, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc6520>.		editor.org/info/rfc6520>.
	[RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for		[RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for
	Transport Layer Security (TLS)", RFC 6655,		Transport Layer Security (TLS)", RFC 6655,
	DOI 10.17487/RFC6655, July 2012,		DOI 10.17487/RFC6655, July 2012, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc6655>.		editor.org/info/rfc6655>.
	[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,		[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
	"Transport Layer Security (TLS) Application-Layer Protocol		"Transport Layer Security (TLS) Application-Layer Protocol
	Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,		Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
	July 2014, <http://www.rfc-editor.org/info/rfc7301>.		July 2014, <https://www.rfc-editor.org/info/rfc7301>.
	19.2. Informative References		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
			Writing an IANA Considerations Section in RFCs", BCP 26,
			RFC 8126, DOI 10.17487/RFC8126, June 2017,
			<https://www.rfc-editor.org/info/rfc8126>.
			20.2. Informative References
	[I-D.ietf-tls-rfc4492bis]		[I-D.ietf-tls-rfc4492bis]
	Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic		Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic
	Curve Cryptography (ECC) Cipher Suites for Transport Layer		Curve Cryptography (ECC) Cipher Suites for Transport Layer
	Security (TLS) Versions 1.2 and Earlier", draft-ietf-tls-		Security (TLS) Versions 1.2 and Earlier", draft-ietf-tls-
	rfc4492bis-16 (work in progress), March 2017.		rfc4492bis-17 (work in progress), May 2017.
	[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", RFC 2434,
	DOI 10.17487/RFC2434, October 1998,
	<http://www.rfc-editor.org/info/rfc2434>.
	[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)		[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
	Multiple Certificate Status Request Extension", RFC 6961,		Multiple Certificate Status Request Extension", RFC 6961,
	DOI 10.17487/RFC6961, June 2013,		DOI 10.17487/RFC6961, June 2013, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc6961>.		editor.org/info/rfc6961>.
	Authors' Addresses		Authors' Addresses
	Joe Salowey		Joe Salowey
	Tableau Software		Tableau Software
	Email: joe@salowey.net		Email: joe@salowey.net
	Sean Turner		Sean Turner
	sn3rd		sn3rd
End of changes. 95 change blocks.
	241 lines changed or deleted		372 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/