RFC Errata


Errata Search
 
Source of RFC  
Summary Table Full Records

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: Legacy
Area 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: Legacy
Area 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.

Report New Errata



Advanced Search