Errata
Verified (3)
RFC 3580 inline-errata
Source of RFC: INDEPENDENT
Updated by: RFC7268
Errata-ID: 1503
- Status:
- Verified
- Type:
- Technical
- Reported By:
- Avi Lior
- Date Reported:
- 2008-09-12
- Verified by:
- Nevil Brownlee
- Date Verified:
- 2010-04-03
Section 3.21 says:
For IEEE 802.1X Authenticators, this attribute is used to store the
Supplicant MAC address in ASCII format (upper case only), with octet
values separated by a "-". Example: "00-10-A4-23-19-C0".
It should say:
For IEEE Std 802.1X-2001 authenticators, this attribute is used to store
the Supplicant MAC address, represented as an ASCII character string in
Canonical format (see IEEE Std 802). For example, "00-10-A4-23-19-C0".
Notes:
The IETF Informational RFC needed to specify that the representation of the MAC address is in Canonical Format.
This is the case in the IEEE document 802_1x-2001 which is the corrected text provided.
I would be okay if the authors wanted to use Supplicant MAC address instead of "bridge or Access Point" in the proposed corrected text.
Errata-ID: 4484
- Status:
- Verified
- Type:
- Technical
- Reported By:
- Nick Lowe
- Date Reported:
- 2015-09-27
- Verified by:
- Nevil Brownlee
- Date Verified:
- 2016-03-17
Section 2.2 says:
The purpose of this attribute is to make it possible to link together
multiple related sessions. While [IEEE8021X] does not act on
aggregated ports, it is possible for a Supplicant roaming between
Access Points to cause multiple RADIUS accounting packets to be sent
by different Access Points.
It should say:
The purpose of this attribute is to make it possible to link together
multiple related sessions. While [IEEE8021X] does not act on
aggregated ports, it is possible for a Supplicant roaming between
Basic Service Sets to cause multiple RADIUS accounting packets to be
sent by the same or different Access Points.
Notes:
This was written in the context of an Access Point only offering a single Basic Service Set, predating Access Points containing multiple radios or supporting Virtual Access Points. It is not accurate today.
Errata-ID: 4491
- Status:
- Verified
- Type:
- Technical
- Reported By:
- Nick Lowe
- Date Reported:
- 2015-10-04
- Verified by:
- Nevil Brownlee
- Date Verified:
- 2016-03-17
Section 3.20 says:
Called-Station-Id
For IEEE 802.1X Authenticators, this attribute is used to store the
bridge or Access Point MAC address in ASCII format (upper case only),
with octet values separated by a "-". Example: "00-10-A4-23-19-C0".
In IEEE 802.11, where the SSID is known, it SHOULD be appended to the
Access Point MAC address, separated from the MAC address with a ":".
Example "00-10-A4-23-19-C0:AP1".
It should say:
Called-Station-Id
For IEEE 802.1X Authenticators, this attribute is used to store the
bridge MAC address or IEEE 802.11 BSSID (upper case only), with octet
values separated by a "-". Example: "00-10-A4-23-19-C0".
In IEEE 802.11, where the SSID is known, it SHOULD be appended to the
BSSID, separated from the BSSID with a ":".
Example "00-10-A4-23-19-C0:AP1".
The Called-Station-Id MUST be UTF-8 encoded.
Notes:
The RFC was written in the context of an Access Point only offering a
single Basic Service Set, predating and not anticipating Access Points
containing multiple radios or supporting Virtual Access Points. It is
not accurate today and the RFC should originally have stated a Basic
Service Set. It was an error to not state this.
This errata, however, emphatically does not change the original
meaning or intention of the RFC. Basic Service Set was always meant.
Since 802.11 SSIDs may be UTF-8 encoded, the Called-Station-Id MUST always be treated as being UTF-8 encoded in the context of 802.1X to accommodate 802.11 where the SSID has been appended. (This inherently encodes the bridge MAC address or IEEE 802.11 BSSID as ASCII would.)