< draft-ietf-precis-saslprepbis-11.txt		draft-ietf-precis-saslprepbis-12.txt >
	PRECIS P. Saint-Andre		PRECIS P. Saint-Andre
	Internet-Draft &yet		Internet-Draft &yet
	Obsoletes: 4013 (if approved) A. Melnikov		Obsoletes: 4013 (if approved) A. Melnikov
	Intended status: Standards Track Isode Ltd		Intended status: Standards Track Isode Ltd
	Expires: May 30, 2015 November 26, 2014		Expires: June 5, 2015 December 2, 2014
	Preparation, Enforcement, and Comparison of Internationalized Strings		Preparation, Enforcement, and Comparison of Internationalized Strings
	Representing Usernames and Passwords		Representing Usernames and Passwords
	draft-ietf-precis-saslprepbis-11		draft-ietf-precis-saslprepbis-12
	Abstract		Abstract
	This document describes methods for handling Unicode strings		This document describes methods for handling Unicode strings
	representing usernames and passwords. This document obsoletes RFC		representing usernames and passwords. This document obsoletes RFC
	4013.		4013.
	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
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 34 ¶
	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 May 30, 2015.		This Internet-Draft will expire on June 5, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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 16 ¶		skipping to change at page 2, line 16 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Usernames . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Usernames . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 4		3.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 4
	3.2. UsernameCaseMapped Profile . . . . . . . . . . . . . . . 5		3.2. UsernameCaseMapped Profile . . . . . . . . . . . . . . . 5
	3.2.1. Preparation . . . . . . . . . . . . . . . . . . . . . 5		3.2.1. Preparation . . . . . . . . . . . . . . . . . . . . . 5
	3.2.2. Enforcement . . . . . . . . . . . . . . . . . . . . . 6		3.2.2. Enforcement . . . . . . . . . . . . . . . . . . . . . 6
	3.2.3. Comparison . . . . . . . . . . . . . . . . . . . . . 6		3.2.3. Comparison . . . . . . . . . . . . . . . . . . . . . 6
	3.3. UsernameCasePreserved Profile . . . . . . . . . . . . . . 6		3.3. UsernameCasePreserved Profile . . . . . . . . . . . . . . 6
	3.3.1. Preparation . . . . . . . . . . . . . . . . . . . . . 6		3.3.1. Preparation . . . . . . . . . . . . . . . . . . . . . 7
	3.3.2. Enforcement . . . . . . . . . . . . . . . . . . . . . 7		3.3.2. Enforcement . . . . . . . . . . . . . . . . . . . . . 7
	3.3.3. Comparison . . . . . . . . . . . . . . . . . . . . . 7		3.3.3. Comparison . . . . . . . . . . . . . . . . . . . . . 7
	3.4. Case Mapping vs. Case Preservation . . . . . . . . . . . 7		3.4. Case Mapping vs. Case Preservation . . . . . . . . . . . 7
	3.5. Application-Layer Constructs . . . . . . . . . . . . . . 9		3.5. Application-Layer Constructs . . . . . . . . . . . . . . 9
	3.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . 9		3.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . 9
	4. Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . 10		4. Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	4.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 10		4.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 11
	4.2. Password Profile . . . . . . . . . . . . . . . . . . . . 11		4.2. OpaqueString Profile . . . . . . . . . . . . . . . . . . 11
	4.2.1. Preparation . . . . . . . . . . . . . . . . . . . . . 11		4.2.1. Preparation . . . . . . . . . . . . . . . . . . . . . 12
	4.2.2. Enforcement . . . . . . . . . . . . . . . . . . . . . 12		4.2.2. Enforcement . . . . . . . . . . . . . . . . . . . . . 12
	4.2.3. Comparison . . . . . . . . . . . . . . . . . . . . . 12		4.2.3. Comparison . . . . . . . . . . . . . . . . . . . . . 12
	4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 12		4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 13
	5. Migration . . . . . . . . . . . . . . . . . . . . . . . . . . 13		5. Migration . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	5.1. Usernames . . . . . . . . . . . . . . . . . . . . . . . . 13		5.1. Usernames . . . . . . . . . . . . . . . . . . . . . . . . 14
	5.2. Passwords . . . . . . . . . . . . . . . . . . . . . . . . 15		5.2. Passwords . . . . . . . . . . . . . . . . . . . . . . . . 15
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	6.1. UsernameCaseMapped Profile . . . . . . . . . . . . . . . 16		6.1. UsernameCaseMapped Profile . . . . . . . . . . . . . . . 16
	6.2. UsernameCasePreserved Profile . . . . . . . . . . . . . . 16		6.2. UsernameCasePreserved Profile . . . . . . . . . . . . . . 16
	6.3. Password Profile . . . . . . . . . . . . . . . . . . . . 17		6.3. OpaqueString Profile . . . . . . . . . . . . . . . . . . 17
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 17		7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	7.1. Password/Passphrase Strength . . . . . . . . . . . . . . 17		7.1. Password/Passphrase Strength . . . . . . . . . . . . . . 18
	7.2. Identifier Comparison . . . . . . . . . . . . . . . . . . 18		7.2. Identifier Comparison . . . . . . . . . . . . . . . . . . 18
	7.3. Reuse of PRECIS . . . . . . . . . . . . . . . . . . . . . 18		7.3. Reuse of PRECIS . . . . . . . . . . . . . . . . . . . . . 18
	7.4. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . 18		7.4. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . 18
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
	8.1. Normative References . . . . . . . . . . . . . . . . . . 18		8.1. Normative References . . . . . . . . . . . . . . . . . . 18
	8.2. Informative References . . . . . . . . . . . . . . . . . 18		8.2. Informative References . . . . . . . . . . . . . . . . . 19
	Appendix A. Differences from RFC 4013 . . . . . . . . . . . . . 20		Appendix A. Differences from RFC 4013 . . . . . . . . . . . . . 20
	Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 21		Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 21
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
	1. Introduction		1. Introduction
	Usernames and passwords are widely used for authentication and		Usernames and passwords are widely used for authentication and
	authorization on the Internet, either directly when provided in		authorization on the Internet, either directly when provided in
	plaintext (as in the SASL PLAIN mechanism [RFC4616] or the HTTP Basic		plaintext (as in the SASL PLAIN mechanism [RFC4616] or the HTTP Basic
	scheme [RFC2617] / [I-D.ietf-httpauth-basicauth-update]) or		scheme [RFC2617] / [I-D.ietf-httpauth-basicauth-update]) or
	skipping to change at page 6, line 29 ¶		skipping to change at page 6, line 29 ¶
	3. Case Mapping Rule: Uppercase and titlecase characters MUST be		3. Case Mapping Rule: Uppercase and titlecase characters MUST be
	mapped to their lowercase equivalents, preferably using Unicode		mapped to their lowercase equivalents, preferably using Unicode
	Default Case Folding as defined in Chapter 3 of the Unicode		Default Case Folding as defined in Chapter 3 of the Unicode
	Standard [UNICODE].		Standard [UNICODE].
	4. Normalization Rule: Unicode Normalization Form C (NFC) MUST be		4. Normalization Rule: Unicode Normalization Form C (NFC) MUST be
	applied to all characters.		applied to all characters.
	5. Directionality Rule: Applications MUST apply the "Bidi Rule"		5. Directionality Rule: Applications MUST apply the "Bidi Rule"
	defined in [RFC5893] (i.e., each of the six conditions of the		defined in [RFC5893] to strings that contain right-to-left
	Bidi Rule must be satisfied).		characters (i.e., each of the six conditions of the Bidi Rule
			must be satisfied).
	3.2.3. Comparison		3.2.3. Comparison
	An entity that performs comparison of two strings according to this		An entity that performs comparison of two strings according to this
	profile MUST prepare each string and enforce the rules specified in		profile MUST prepare each string and enforce the rules specified in
	the previous two sections. The two strings are to be considered		the previous two sections. The two strings are to be considered
	equivalent if they are an exact octet-for-octet match (sometimes		equivalent if they are an exact octet-for-octet match (sometimes
	called "bit-string identity").		called "bit-string identity").
	3.3. UsernameCasePreserved Profile		3.3. UsernameCasePreserved Profile
	skipping to change at page 7, line 27 ¶		skipping to change at page 7, line 32 ¶
	2. Additional Mapping Rule: There is no additional mapping rule.		2. Additional Mapping Rule: There is no additional mapping rule.
	3. Case Mapping Rule: Uppercase and titlecase characters MUST NOT be		3. Case Mapping Rule: Uppercase and titlecase characters MUST NOT be
	mapped to their lowercase equivalents.		mapped to their lowercase equivalents.
	4. Normalization Rule: Unicode Normalization Form C (NFC) MUST be		4. Normalization Rule: Unicode Normalization Form C (NFC) MUST be
	applied to all characters.		applied to all characters.
	5. Directionality Rule: Applications MUST apply the "Bidi Rule"		5. Directionality Rule: Applications MUST apply the "Bidi Rule"
	defined in [RFC5893] (i.e., each of the six conditions of the		defined in [RFC5893] to strings that contain right-to-left
	Bidi Rule must be satisfied).		characters (i.e., each of the six conditions of the Bidi Rule
			must be satisfied).
	3.3.3. Comparison		3.3.3. Comparison
	An entity that performs comparison of two strings according to this		An entity that performs comparison of two strings according to this
	profile MUST prepare each string and enforce the rules specified in		profile MUST prepare each string and enforce the rules specified in
	the previous two sections. The two strings are to be considered		the previous two sections. The two strings are to be considered
	equivalent if they are an exact octet-for-octet match (sometimes		equivalent if they are an exact octet-for-octet match (sometimes
	called "bit-string identity").		called "bit-string identity").
	3.4. Case Mapping vs. Case Preservation		3.4. Case Mapping vs. Case Preservation
	skipping to change at page 10, line 51 ¶		skipping to change at page 11, line 11 ¶
	IdentiferClass. Regarding example 11: symbol characters such as		IdentiferClass. Regarding example 11: symbol characters such as
	BLACK CHESS KING (U+265A) are not allowed in the PRECIS		BLACK CHESS KING (U+265A) are not allowed in the PRECIS
	IdentifierClass.		IdentifierClass.
	4. Passwords		4. Passwords
	4.1. Definition		4.1. Definition
	This document specifies that a password is a string of Unicode code		This document specifies that a password is a string of Unicode code
	points [UNICODE], encoded using UTF-8 [RFC3629], and conformant to		points [UNICODE], encoded using UTF-8 [RFC3629], and conformant to
	the PRECIS FreeformClass.		OpaqueString profile of the PRECIS FreeformClass specified below.
	The syntax for a password is defined as follows using the Augmented		The syntax for a password is defined as follows using the Augmented
	Backus-Naur Form (ABNF) [RFC5234].		Backus-Naur Form (ABNF) [RFC5234].
	password = 1*(freebyte)		password = 1*(freebyte)
	;		;
	; a "freebyte" is a byte used to represent a		; a "freebyte" is a byte used to represent a
	; UTF-8 encoded Unicode code point that can be		; UTF-8 encoded Unicode code point that can be
	; contained in a string that conforms to the		; contained in a string that conforms to the
	; PRECIS "FreefromClass"		; PRECIS "FreefromClass"
	skipping to change at page 11, line 34 ¶		skipping to change at page 11, line 42 ¶
	Note: The prohibition on zero-length passwords is not a		Note: The prohibition on zero-length passwords is not a
	recommendation regarding password strength (since a password of		recommendation regarding password strength (since a password of
	only one byte is highly insecure), but is meant to prevent		only one byte is highly insecure), but is meant to prevent
	applications from omitting a password entirely.		applications from omitting a password entirely.
	In protocols that provide passwords as input to a cryptographic		In protocols that provide passwords as input to a cryptographic
	algorithm such as a hash function, the client will need to perform		algorithm such as a hash function, the client will need to perform
	proper preparation of the password before applying the algorithm,		proper preparation of the password before applying the algorithm,
	since the password is not available to the server in plaintext form.		since the password is not available to the server in plaintext form.
	4.2. Password Profile		4.2. OpaqueString Profile
	The definition of the Password profile is provided in the following		The definition of the OpaqueString profile is provided in the
	sections, including detailed information about preparation,		following sections, including detailed information about preparation,
	enforcement, and comparison (on the distinction between these		enforcement, and comparison (on the distinction between these
	actions, refer to [I-D.ietf-precis-framework]).		actions, refer to [I-D.ietf-precis-framework]).
	4.2.1. Preparation		4.2.1. Preparation
	An entity that prepares a string according to this profile MUST		An entity that prepares a string according to this profile MUST
	ensure that the string consists only of Unicode code points that		ensure that the string consists only of Unicode code points that
	conform to the "FreeformClass" base string class defined in		conform to the "FreeformClass" base string class defined in
	[I-D.ietf-precis-framework]. In addition, the string MUST be encoded		[I-D.ietf-precis-framework]. In addition, the string MUST be encoded
	as UTF-8 [RFC3629].		as UTF-8 [RFC3629].
	4.2.2. Enforcement		4.2.2. Enforcement
	An entity that performs enforcement according to this profile MUST		An entity that performs enforcement according to this profile MUST
	prepare a string as described in the previous section and MUST also		prepare a string as described in the previous section and MUST also
	apply the rules specified below for the Password (these rules MUST be		apply the rules specified below (these rules MUST be applied in the
	applied in the order shown).		order shown).
	1. Width Mapping Rule: Fullwidth and halfwidth characters MUST NOT		1. Width Mapping Rule: Fullwidth and halfwidth characters MUST NOT
	be mapped to their decomposition mappings.		be mapped to their decomposition mappings.
	2. Additional Mapping Rule: Any instances of non-ASCII space MUST be		2. Additional Mapping Rule: Any instances of non-ASCII space MUST be
	mapped to ASCII space (U+0020); a non-ASCII space is any Unicode		mapped to ASCII space (U+0020); a non-ASCII space is any Unicode
	code point having a general category of "Zs", naturally with the		code point having a general category of "Zs", naturally with the
	exception of U+0020.		exception of U+0020.
	3. Case Mapping Rule: Uppercase and titlecase characters MUST NOT be		3. Case Mapping Rule: Uppercase and titlecase characters MUST NOT be
	mapped to their lowercase equivalents.		mapped to their lowercase equivalents.
	4. Normalization Rule: Unicode Normalization Form C (NFC) MUST be		4. Normalization Rule: Unicode Normalization Form C (NFC) MUST be
	applied to all characters.		applied to all characters.
	5. Directionality Rule: There is no directionality rule. The "Bidi		5. Directionality Rule: There is no directionality rule. The "Bidi
	Rule" (defined in [RFC5893]) and similar rules are unnecessary		Rule" (defined in [RFC5893]) and similar rules are unnecessary
	and inapplicable to passwords, since they can reduce the range of		and inapplicable to passwords and other opaque strings, since
	characters that are allowed in a string and therefore reduce the		they can reduce the range of characters that are allowed in a
	amount of entropy that is possible in a password. Furthermore,		string and therefore reduce the amount of entropy that is
	such rules are intended to minimize the possibility that the same		possible in a password. Furthermore, such rules are intended to
	string will be displayed differently on a system set for right-		minimize the possibility that the same string will be displayed
	to-left display and a system set for left-to-right display;		differently on a system set for right-to-left display and a
	however, passwords are typically not displayed at all and are		system set for left-to-right display; however, passwords and
			other opaque strings are typically not displayed at all and are
	rarely meant to be interoperable across different systems in the		rarely meant to be interoperable across different systems in the
	way that non-secret strings like domain names and usernames are.		way that non-secret strings like domain names and usernames are.
	4.2.3. Comparison		4.2.3. Comparison
	An entity that performs comparison of two strings according to this		An entity that performs comparison of two strings according to this
	profile MUST prepare each string and enforce the rules specified in		profile MUST prepare each string and enforce the rules specified in
	the previous two sections. The two strings are to be considered		the previous two sections. The two strings are to be considered
	equivalent if they are an exact octet-for-octet match (sometimes		equivalent if they are an exact octet-for-octet match (sometimes
	called "bit-string identity").		called "bit-string identity").
	skipping to change at page 15, line 14 ¶		skipping to change at page 15, line 23 ¶
	5.2. Passwords		5.2. Passwords
	Depending on local service policy, migration from RFC 4013 to this		Depending on local service policy, migration from RFC 4013 to this
	specification might not involve any scrubbing of data (since		specification might not involve any scrubbing of data (since
	passwords might not be stored in the clear anyway); however, service		passwords might not be stored in the clear anyway); however, service
	providers need to be aware of possible issues that might arise during		providers need to be aware of possible issues that might arise during
	migration. In particular:		migration. In particular:
	o SASLprep specified the use of Unicode Normalization Form KC		o SASLprep specified the use of Unicode Normalization Form KC
	(NFKC), whereas the Password profile employs Unicode Normalization		(NFKC), whereas the OpaqueString profile employs Unicode
	Form C (NFC). Because NFKC is more aggressive about finding		Normalization Form C (NFC). Because NFKC is more aggressive about
	matches than NFC, in practice this change is unlikely to cause		finding matches than NFC, in practice this change is unlikely to
	significant problems and indeed has the security benefit of		cause significant problems and indeed has the security benefit of
	probably resulting in fewer false positives when comparing		probably resulting in fewer false positives when comparing
	passwords. A few examples might suffice to indicate the nature of		passwords. A few examples might suffice to indicate the nature of
	the problem:		the problem:
	1. U+017F LATIN SMALL LETTER LONG S is compatibility equivalent		1. U+017F LATIN SMALL LETTER LONG S is compatibility equivalent
	to U+0073 LATIN SMALL LETTER S		to U+0073 LATIN SMALL LETTER S
	2. U+2163 ROMAN NUMERAL FOUR is compatibility equivalent to		2. U+2163 ROMAN NUMERAL FOUR is compatibility equivalent to
	U+0049 LATIN CAPITAL LETTER I and U+0056 LATIN CAPITAL LETTER		U+0049 LATIN CAPITAL LETTER I and U+0056 LATIN CAPITAL LETTER
	V		V
	skipping to change at page 17, line 17 ¶		skipping to change at page 17, line 22 ¶
	Normalization Rule: NFC.		Normalization Rule: NFC.
	Directionality Rule: The "Bidi Rule" defined in RFC 5893 applies.		Directionality Rule: The "Bidi Rule" defined in RFC 5893 applies.
	Enforcement: To be defined by security or application protocols that		Enforcement: To be defined by security or application protocols that
	use this profile.		use this profile.
	Specification: RFC XXXX. [Note to RFC Editor: please change XXXX to		Specification: RFC XXXX. [Note to RFC Editor: please change XXXX to
	the number issued for this specification.]		the number issued for this specification.]
	6.3. Password Profile		6.3. OpaqueString Profile
	Name: Password.		Name: OpaqueString.
	Base Class: FreeformClass		Base Class: FreeformClass.
	Applicability: Passwords in security and application protocols.		Applicability: Passwords and other opaque strings in security and
			application protocols.
	Replaces: The SASLprep profile of Stringprep.		Replaces: The SASLprep profile of Stringprep.
	Width Mapping Rule: None.		Width Mapping Rule: None.
	Additional Mapping Rule: Map non-ASCII space characters to ASCII		Additional Mapping Rule: Map non-ASCII space characters to ASCII
	space.		space.
	Case Mapping Rule: None.		Case Mapping Rule: None.
	skipping to change at page 19, line 7 ¶		skipping to change at page 19, line 13 ¶
	Specifications: ABNF", STD 68, RFC 5234, January 2008.		Specifications: ABNF", STD 68, RFC 5234, January 2008.
	[UNICODE] The Unicode Consortium, "The Unicode Standard, Version		[UNICODE] The Unicode Consortium, "The Unicode Standard, Version
	6.3", 2013,		6.3", 2013,
	<http://www.unicode.org/versions/Unicode6.3.0/>.		<http://www.unicode.org/versions/Unicode6.3.0/>.
	8.2. Informative References		8.2. Informative References
	[I-D.ietf-httpauth-basicauth-update]		[I-D.ietf-httpauth-basicauth-update]
	Reschke, J., "The 'Basic' HTTP Authentication Scheme",		Reschke, J., "The 'Basic' HTTP Authentication Scheme",
	draft-ietf-httpauth-basicauth-update-02 (work in		draft-ietf-httpauth-basicauth-update-03 (work in
	progress), October 2014.		progress), December 2014.
	[I-D.ietf-httpauth-digest]		[I-D.ietf-httpauth-digest]
	Shekh-Yusef, R., Ahrens, D., and S. Bremer, "HTTP Digest		Shekh-Yusef, R., Ahrens, D., and S. Bremer, "HTTP Digest
	Access Authentication", draft-ietf-httpauth-digest-08		Access Authentication", draft-ietf-httpauth-digest-08
	(work in progress), August 2014.		(work in progress), August 2014.
	[I-D.ietf-radext-nai]		[I-D.ietf-radext-nai]
	DeKok, A., "The Network Access Identifier", draft-ietf-		DeKok, A., "The Network Access Identifier", draft-ietf-
	radext-nai-11 (work in progress), November 2014.		radext-nai-11 (work in progress), November 2014.
End of changes. 22 change blocks.
	41 lines changed or deleted		45 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/