RFC Errata
Found 2 records.
Status: Held for Document Update (1)
RFC 3162, "RADIUS and IPv6", August 2001
Note: This RFC has been updated by RFC 8044
Source of RFC: LegacyArea Assignment: ops
Errata ID: 3217
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Leaf Yeh
Date Reported: 2012-05-08
Held for Document Update by: RonBonica
Section 2 says:
3.2 Framed-Interface-Id
It should say:
2.2 Framed-Interface-Id
Notes:
Typo in the numbering of this section.
Status: Rejected (1)
RFC 3162, "RADIUS and IPv6", August 2001
Note: This RFC has been updated by RFC 8044
Source of RFC: LegacyArea Assignment: ops
Errata ID: 1923
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alan DeKok
Date Reported: 2009-10-22
Rejected by: Dan Romascanu
Date Rejected: 2010-11-02
Section 2.1 says:
Address The Address field is 16 octets.
It should say:
String The field is 16 octets
Notes:
As Glen notes in:
http://ops.ietf.org/lists/radiusext/2009/msg00540.html
Using "ipv6 address" for a data type in RADIUS is wrong.
RFC 3162 (among others Glen wrote) contradict his current position. Those documents use data types for the "value" field of RADIUS attributes that have not been defined in RFC 2865. As such, they should either:
a) make it clear that they define a new data type, and be marked as "Updates: 2865"
or
b) use the data types in RFC 2865.
Or even better, maintain an internally consistent set of beliefs, and leave RFC 3162 alone.
--VERIFIER NOTES--
The common terminology is known by RADIUS implementers. Every RADIUS implementor "knows what this means". i.e. "Address" in RFC 2865 means "ipaddr", and "Address" in RFC 3162 means "ipv6addr". A change now would create further confusion.