draft-ietf-radext-datatypes-03.txt		draft-ietf-radext-datatypes-04.txt
	Network Working Group DeKok, Alan		Network Working Group DeKok, Alan
	INTERNET-DRAFT FreeRADIUS		INTERNET-DRAFT FreeRADIUS
	Updates: 2865,3162,6158,6572		Updates: 2865,3162,6158,6572
	Category: Standards Track		Category: Standards Track
	<draft-ietf-radext-datatypes-03.txt>		<draft-ietf-radext-datatypes-04.txt>
	6 May 2016		22 June 2016
	Data Types in the Remote Authentication		Data Types in the Remote Authentication
	Dial-In User Service Protocol (RADIUS)		Dial-In User Service Protocol (RADIUS)
	draft-ietf-radext-datatypes-03.txt		draft-ietf-radext-datatypes-04.txt
	Abstract		Abstract
	RADIUS specifications have used data types for two decades without		RADIUS specifications have used data types for two decades without
	defining them as managed entities. During this time, RADIUS		defining them as managed entities. During this time, RADIUS
	implementations have named the data types, and have used them in		implementations have named the data types, and have used them in
	attribute definitions. This document updates the specifications to		attribute definitions. This document updates the specifications to
	better follow established practice. We do this by naming the data		better follow established practice. We do this by naming the data
	types defined in RFC 6158, which have been used since at least RFC		types defined in RFC 6158, which have been used since at least RFC
	2865. We provide an IANA registry for the data types, and update the		2865. We provide an IANA registry for the data types, and update the
	skipping to change at page 1, line 48 ¶		skipping to change at page 1, line 48 ¶
	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		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on November 6, 2016.		This Internet-Draft will expire on January 22, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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 3, line 31 ¶		skipping to change at page 3, line 31 ¶
	3.2. enum ................................................ 12		3.2. enum ................................................ 12
	3.3. time ................................................ 13		3.3. time ................................................ 13
	3.4. text ................................................ 13		3.4. text ................................................ 13
	3.5. string .............................................. 14		3.5. string .............................................. 14
	3.6. concat .............................................. 15		3.6. concat .............................................. 15
	3.7. ifid ................................................ 16		3.7. ifid ................................................ 16
	3.8. ipv4addr ............................................ 17		3.8. ipv4addr ............................................ 17
	3.9. ipv6addr ............................................ 17		3.9. ipv6addr ............................................ 17
	3.10. ipv6prefix ......................................... 18		3.10. ipv6prefix ......................................... 18
	3.11. ipv4prefix ......................................... 19		3.11. ipv4prefix ......................................... 19
	3.12. integer64 .......................................... 20		3.12. integer64 .......................................... 21
	3.13. tlv ................................................ 21		3.13. tlv ................................................ 21
	3.14. vsa ................................................ 23		3.14. vsa ................................................ 23
	3.15. extended ........................................... 24		3.15. extended ........................................... 24
	3.16. long-extended ...................................... 25		3.16. long-extended ...................................... 25
	3.17. evs ................................................ 27		3.17. evs ................................................ 28
	4. Updated Registries ....................................... 29		4. Updated Registries ....................................... 29
	4.1. Create a Data Type Registry ......................... 29		4.1. Create a Data Type Registry ......................... 29
	4.2. Updates to the Attribute Type Registry .............. 30		4.2. Updates to the Attribute Type Registry .............. 30
	5. Security Considerations .................................. 35		5. Security Considerations .................................. 35
	6. IANA Considerations ...................................... 35		6. IANA Considerations ...................................... 35
	7. References ............................................... 36		7. References ............................................... 36
	7.1. Normative References ................................ 36		7.1. Normative References ................................ 36
	7.2. Informative References .............................. 36		7.2. Informative References .............................. 37
	1. Introduction		1. Introduction
	RADIUS specifications have historically defined attributes in terms		RADIUS specifications have historically defined attributes in terms
	of name, type value, and data type. Of these three pieces of		of name, type value, and data type. Of these three pieces of
	information, only the type value is managed by IANA. There is no		information, only the type value is managed by IANA. There is no
	management of, or restriction on, the attribute name, as discussed in		management of, or restriction on, the attribute name, as discussed in
	[RFC6929] Section 2.7.1. There is no management of data type name or		[RFC6929] Section 2.7.1. There is no management of data type name or
	definition. Experience has shown that there is a need for well		definition. Experience has shown that there is a need for well
	defined data types.		defined data types.
	skipping to change at page 7, line 33 ¶		skipping to change at page 7, line 33 ¶
	Attributes can usually be completely described via the Attribute Type		Attributes can usually be completely described via the Attribute Type
	code, name, and data type. The use of "ASCII art" is then limited		code, name, and data type. The use of "ASCII art" is then limited
	only to the definition of new data types, and for complex data types.		only to the definition of new data types, and for complex data types.
	Use of the new extended attributes [RFC6929] makes ASCII art even		Use of the new extended attributes [RFC6929] makes ASCII art even
	more problematic. An attribute can be allocated from any of the		more problematic. An attribute can be allocated from any of the
	extended spaces, with more than one option for attribute header		extended spaces, with more than one option for attribute header
	format. This allocation decision is made after the specification has		format. This allocation decision is made after the specification has
	been accepted for publication. As the allocation affects the format		been accepted for publication. As the allocation affects the format
	of the attribute header, it is esstentially impossible to create the		of the attribute header, it is essentially impossible to create the
	correct ASCII art prior to final publication. Allocation from the		correct ASCII art prior to final publication. Allocation from the
	different spaces also changes the value of the Length field, also		different spaces also changes the value of the Length field, also
	making it difficult to define it correctly prior to final publication		making it difficult to define it correctly prior to final publication
	of the document.		of the document.
	It is therefore RECOMMENDED that "ASCII art" diagrams not be used for		It is therefore RECOMMENDED that "ASCII art" diagrams not be used for
	new RADIUS attribute specifications.		new RADIUS attribute specifications.
	2.1.3. Format of Attribute Definitions		2.1.3. Format of Attribute Definitions
	skipping to change at page 20, line 32 ¶		skipping to change at page 20, line 32 ¶
	| Reserved | Prefix-Length | Prefix ...		| Reserved | Prefix-Length | Prefix ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	... Prefix |		... Prefix |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Subfields		Subfields
	Reserved		Reserved
	This field, which is reserved and MUST be present, is always		This field, which is reserved and MUST be present, is always
	set to zero.		set to zero. This field is one octet in length.
			Note that this definition differs from that given in [RFC6572].
			See Prefix-Length, below, for an explanation.
			Prefix-Length
	Prefix-Length <
	The length of the prefix, in bits. The values MUST be no		The length of the prefix, in bits. The values MUST be no
	larger than 32.		larger than 32. This field is one octet in length.
			Note that this definition differs from that given in [RFC6572].
			As compared to [RFC6572], the Prefix-Length field has increased
			in size by two bits, both of which must be zero. The Reserved
			field has decreased in size by two bits. The result is that
			both fields are aligned on octet boundaries, which removes the
			need for bit masking of the fields.
			Since [RFC6572] required the Reserved field to be zero, the
			definition here is compatible with the definition in the
			original specification.
	Prefix		Prefix
	The Prefix field is 4 octets in length. Bits outside of the		The Prefix field is 4 octets in length. Bits outside of the
	Prefix-Length MUST be zero. Unlike the "ipv6prefix" data type,		Prefix-Length MUST be zero. Unlike the "ipv6prefix" data type,
	this field is fixed length. If the address is all zeros (i.e.		this field is fixed length. If the address is all zeros (i.e.
	"0.0.0.0", then the Prefix-Length MUST be set to 32.		"0.0.0.0", then the Prefix-Length MUST be set to 32.
	3.12. integer64		3.12. integer64
End of changes. 10 change blocks.
	11 lines changed or deleted		27 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/