RE: [IANA #278793] Registration of RADIUS Attribute Values and RFC 3575

[Bernard Aboba <bernard_aboba@hotmail.com>]

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.  

What do other WG participants think?



-----Original Message-----
From: Amanda Baber via RT [mailto:iana-questions@iana.org] 
Sent: Friday, March 18, 2011 2:59 PM
To: bernard_aboba@hotmail.com
Subject: [IANA #278793] Registration of RADIUS Attribute Values and RFC 3575 

Hi,

I'm afraid I lost track of this message about fixing IANA's descriptions of RADIUS registration procedures. 

Given RFC 3575, all of the RADIUS attribute values but 6 (Service-Type),
64 (Tunnel-Type), and 65 (Tunnel-Medium-Type) are now listed as Expert Review registries. Those remaining three are listed as IETF Consensus.
Please see

http://www.iana.org/assignments/radius-types

The issue with Tunnel-Type and Tunnel-Medium-Type, which has come up before, is that RFC2868 specifically calls them IETF Consensus registries, and RFC3575 doesn't update RFC2868. Is this reading correct, or does RFC3575 supersede 2868 anyway?

Since we're not sure what to do about Tunnel-Type and Tunnel-Medium-Type, the directory at http://www.iana.org/protocols/ currently says, "Registration procedure varies by attribute."

Do we need to make any changes?

thanks,
Amanda

On Tue Nov 10 01:45:42 2009, bernard_aboba@hotmail.com wrote:
> Recently on the RADEXT WG mailing list, an issue has been raised about 
> the IANA allocation procedures for RADIUS attribute values:
> 
> http://ops.ietf.org/lists/radiusext/2009/msg00625.html
> 
>  
> 
> As noted in RFC 3575, Section 2.1:
> 
>  
> 
>    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.
> 
>  
> 
> Given the above text, it is my understanding that according to RFC 
> 3575, additional values for RADIUS attributes (with the exception of 
> the Service-Type attribute (6)) are to be allocated by Designated Expert.
> 
>  
> 
> However, within the IANA RADIUS registry 
> (http://www.iana.org/protocols/) RADIUS attribute values are listed as requiring Standards Action.
> 
>  
> 
> We have already had one instance in which the insistence on Standards
Action
> has resulted in a large delay in value allocation with the resulting
use of
> Vendor-Specific Values as described in RFC 2822.  Given that RFC 3575 
> specifically indicates that standards action is not required for
allocation
> of values for any RADIUS attribute other than Service-Type, there is 
> not much room for interpretation here and I would like to make sure 
> that this problem is corrected as soon as possible.
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 





--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>