errata logo graphic

RFC3575, "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", July 2003

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: ops

Errata ID: 3378

Status: Verified
Type: Technical

Reported By: Bernard Aboba
Date Reported: 2012-10-13
Verifier Name: Benoit Claise
Date Verified: 2012-12-13

Section Metadata says:

Updates: 2865


It should say:

Updates: 2865, 2868

Notes:


IANA needs to be updated as well.

http://www.iana.org/assignments/radius-types/radius-types.xml#radius-types-14

OLD
Registration Procedures
IETF Consensus
Reference
[RFC2868]

NEW
Registration Procedures
Designated Expert
Reference
[RFC3575]


http://www.iana.org/assignments/radius-types/radius-types.xml#radius-types-15

OLD
Registration Procedures
IETF Consensus
Reference
[RFC2868]

NEW
Registration Procedures
Designated Expert
Reference
[RFC3575]

=======================================================



Some background information:

RFC 3575 Section 2.1 states the following:

Certain attributes (for example, NAS-Port-Type) in RADIUS define a
list of values to correspond with various meanings. There can be 4
billion (2^32) values for each attribute. Additional values can be
allocated by the Designated Expert. The exception to this policy is
the Service-Type attribute (6), whose values define new modes of
operation for RADIUS. Values 1-16 of the Service-Type attribute have
been allocated. Allocation of new Service-Type values are by IETF
Consensus. The intention is that any allocation will be accompanied
by a published RFC.

Note that the Tunnel-Type and Tunnel-Medium-Type attributes are not called out as an exception, only Service-Type. If the intent was to exempt RFC 2868, those attributes would have been included as exceptions but they are not.

Therefore, it looks to me like the omission of RFC 2868 in the Updates: header is an errata.

In other words:

The discussion, as I understand it, is about "IETF consensus" versus "Designated Expert"

From RFC 2868

6.1. Tunnel-Type Attribute Values

Values 1-12 of the Tunnel-Type Attribute are defined in Section 5.1;
the remaining values are available for assignment by the IANA with
IETF Consensus [16].

6.2. Tunnel-Medium-Type Attribute Values

Values 1-15 of the Tunnel-Medium-Type Attribute are defined in
Section 5.2; the remaining values are available for assignment by the
IANA with IETF Consensus [16].

From RFC 3575

Certain attributes (for example, NAS-Port-Type) in RADIUS define a
list of values to correspond with various meanings. There can be 4
billion (2^32) values for each attribute. Additional values can be
allocated by the Designated Expert. The exception to this policy is
the Service-Type attribute (6), whose values define new modes of
operation for RADIUS.

So Tunnel-Type and Tunnel-Medium-Type are "IETF consensus" or "Designated Expert"?

From the IETF 80 meeting minutes, https://www.ietf.org/proceedings/80/minutes/radext.txt:

2. IANA issues
A. How to allocate tunnel params? In RFC 3575 (RFC2868 conflicts as 3575 assigns based on expert review but didn’t update 2868). Omission of RFC 2868 could be an errata; this is basically a request for metadata.
- Asks Dan for comment: was looking for input from the working group before proceeding.
- Alan thought it was an errata.
- Stefan states no opinion.
- Klaas also states no opinion.
- Nancy asks for further understanding. Bernard clarifies: RFC 2868 states “standards action” and 3575 is more lenient in saying just expert review.
- Now Dan remembers: when there’s conflicts such as this, 2 solutions: take the stricter or take the latest. But if it’s the latest, then it needs to be clearer. Believes in this case, explicit clarification is justified since 3575 is more recent and the request is justified. But need IESG perspective review by WG.
- Bernard suggests to get a sense of this group and then take it to the mailgroup.
Asks: proposal is to accept and verify the errata and update 3575 to include 2868.
In favor: 10, non oppose. Given consensus, will take to the mail list.


Report New Errata