Subject: RFC 3580 Errata Submisssion

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 12 Sep 2008 13:01:14 -0700

Comments?

________________________________________

From: RFC Errata System [[email-masked]]

Sent: Friday, September 12, 2008 12:54 PM

To: [email-masked]; Bernard Aboba; [email-masked]; [email-masked];
[email-masked]; [email-masked]

Cc: [email-masked]

Subject: [Technical Errata Reported] RFC3580 (1503)

The following errata report has been submitted for RFC3580,

"IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage
Guidelines".

--------------------------------------

You may review the report below and at:

http://www.rfc-editor.org/errata_search.php?rfc=3580&eid=1503

--------------------------------------

Type: Technical

Reported by: Avi Lior <[email-masked]>

Section: 3.21

Original Text

-------------

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".

Corrected Text

--------------

For IEEE Std 802.1X-2001 authenticators, this attribute is used to store the
bridge or Access Point MAC

address, represented as an ASCII character string in Canonical format (see
IEEE Std 802). For example,

&#147;00-10-A4-23-19-C0.&#148;

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.

Instructions:

-------------

This errata is currently posted as "Reported". If necessary, please

use "Reply All" to discuss whether it should be verified or

rejected. When a decision is reached, the verifying party (RFC Editor &
Editorial Board)

can log in to change the status and edit the report, if necessary.

--------------------------------------

RFC3580 ( draft-congdon-radius-8021x-29)

--------------------------------------

Title               : IEEE 802.1X Remote Authentication Dial In User Service
(RADIUS) Usage Guidelines

Publication Date    : September 2003

Author(s)           : P. Congdon, B. Aboba, A. Smith, G. Zorn, J. Roese

Category            : INFORMATIONAL

Source              : INDEPENDENT

Area                : N/A

Stream              : INDEPENDENT

Verifying Party     : RFC Editor & Editorial Board

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 12 Sep 2008 17:49:05 -0400

> Comments?
>
> > Corrected Text
> > --------------
> > For IEEE Std 802.1X-2001 authenticators, this attribute is used
> > to store the bridge or Access Point 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.

>From IEEE Std 802-2001:

3.1.4 canonical format: The format of a MAC data frame in which the octets
of any MAC addresses conveyed in the MAC user data field have the same bit
ordering as in the Hexadecimal Representation.

3.1.8 hexadecimal representation: The representation of a sequence of octet
values in which the values of the individual octets are displayed in order
from left to right, with each octet value represented as a two-digit
hexadecimal numeral, and with the resulting pairs of hexadecimal digits
separated by hyphens. The order of the hexadecimal digits in each pair, and
the mapping between the hexadecimal digits and the bits of the octet
value, are derived by interpreting the bits of the octet value as a binary
numeral using the normal mathematical rules for digit significance.

If we substitute the IEEE 802 text as quoted above for "Canonical format" in
the suggested revised RFC 3580 text, as a sanity check, does it say what we
expect?

How does the suggested revised text change the normative definition of the
contents of this attribute?  Are we simply being more formal by using the
words "canonical format", or has some bit or byte ordering changed?

> > It would be okay if the authors wanted to use Supplicant MAC 
> > address instead of "bridge or Access Point" in the proposed 
> > corrected text.

Yeah, let's limit the errata to things that are actually wrong or missing,
as opposed to engaging in unnecessary re-wording. 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 12 Sep 2008 15:19:03 -0700

Comments?

A couple:

Why would the "bridge or Access Point MAC address" be conveyed in the
Calling-Station-Id Attribute?

The example in the corrected text is incorrect (the '.' should be outside
the quotes, not inside).

This Errata seems to be editorial rather than technical to me, since AFAICT
the change wouldn't modify the on-wire representation of the Attribute.

Type: Technical

Section: 3.21

Original Text

-------------

Corrected Text

--------------

Notes

-----

Instructions:

-------------

Category            : INFORMATIONAL

Source              : INDEPENDENT

Area                : N/A

Stream              : INDEPENDENT

---

From: "Congdon, Paul T (ProCurve)" <[email-masked]>
Date: Sat, 13 Sep 2008 06:09:19 +0000

802.1 is concerned with canonical format or non-canonical format because they have to 'sometimes' bridge between two LAN segments that have different representations.  As long as the NAS always uses the same format on every request it should give the desired behavior, though I agree it would eliminate more confusion if it were explicitly stated as needing to be one way or the other since the AAA server is presumably using this value as well.  I don't think collisions are likely.  Doesn't seem like a reason to fix the document.  Most people got this right, or at least checked the document before implementing something else.

Paul

From: [email-masked] [mailto:[email-masked]] On Behalf Of Glen Zorn
Sent: Friday, September 12, 2008 3:19 PM
To: 'Bernard Aboba'; [email-masked]
Subject: RE: RFC 3580 Errata Submisssion

Comments?
A couple:

Why would the "bridge or Access Point MAC address" be conveyed in the Calling-Station-Id Attribute?
The example in the corrected text is incorrect (the '.' should be outside the quotes, not inside).
This Errata seems to be editorial rather than technical to me, since AFAICT the change wouldn't modify the on-wire representation of the Attribute.

To: [email-masked]; Bernard Aboba; [email-masked]; [email-masked]; [email-masked]; [email-masked]

The following errata report has been submitted for RFC3580,
"IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines".

Section: 3.21

Original Text
-------------

Corrected Text
--------------
For IEEE Std 802.1X-2001 authenticators, this attribute is used to store the bridge or Access Point MAC
address, represented as an ASCII character string in Canonical format (see IEEE Std 802). For example,
&#147;00-10-A4-23-19-C0.&#148;

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.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (RFC Editor & Editorial Board)
can log in to change the status and edit the report, if necessary.

Title               : IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines

---

From: Stefan Winter <[email-masked]>
Date: Mon, 15 Sep 2008 08:14:55 +0200

Hi,

> the suggested revised RFC 3580 text, as a sanity check, does it say what we

The previous discussion also was about capital vs. non-capital being in 
mixed use right now. The text above leaves capitalisation undefined. 
Could we maybe add a sentence about hex digits being represented in 
capitals to make that clear?
Further to this, neither the erratum nor this text here has a normative 
wording as per 2119, which I think is what Avi was originally aiming 
for? In any case, IMHO, an erratum just to reshuffle the text is a bit 
overkill. If it were to introduce normative wording though, I'd feel 
better about issuing it.

> as opposed to engaging in unnecessary re-wording. 

Agree.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 15 Sep 2008 14:16:38 -0400

Stefan Winter writes...

> Further to this, neither the erratum nor this text here has a 
> normative wording as per 2119...

Well, first of all, the text I quoted from 802 is in the definitions
section.  I'm not sure that definitions call for the use of normative
keywords, and second, this is an IEEE 802 document and they don't use RFC
2119 keywords.  They tend to use "shall" where we would use "MUST", etc.

---

From: Stefan Winter <[email-masked]>
Date: Tue, 16 Sep 2008 08:20:35 +0200

Hi,

> 2119 keywords.  They tend to use "shall" where we would use "MUST", etc. 

Okay, thanks for the clarification. To bind the IETF normativeness to 
the IEEE normativeness, would it help to reformulate as

For IEEE Std 802.1X-2001 authenticators, this attribute is used
to store the bridge or Access Point MAC address. The attribute value MUST be represented as 
an ASCII character string in Canonical format (see IEEE Std 802)[, and the hexadecimal digits above 9 MUST be in capital letters].
For example, "00-10-A4-23-19-C0".

?

The text in [] hopefully solving the capitalisation question.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473