Subject: [radext] RADEXT recharter proposal

From: "Sanchez, Mauricio (HP Networking)" <[email-masked]>
Date: Wed, 7 Nov 2012 17:39:42 +0000

Pasted below is the current recharter proposal for radext.  The largest
change from the previous circulated proposal is the remove of the traffic
statistics work.  After consultation with our AD, we the chairs have decided
to postpone adding this work item until we have a clearer understanding for
scope of problem and solution .   Moreover, we already have a number of
items that are severely overdue and several more solid individual
submissions that are eminent work items (pending this recharter).    We
would like any feedback by EOB Friday as our AD is ready to run this
recharter text through the process.

-Jouni and Mauricio

--------------------------------------------------------
Description of Working Group

The RADIUS Extensions Working Group will focus on extensions to the RADIUS
protocol required to expand and enrich the standard attribute space, address
cryptographic algorithm agility, use of new secure transports and clarify
its usage and definition.

In order to maintain interoperation of heterogeneous RADIUS/Diameter
deployments, all RADEXT WG work items except those that just define new
attributes MUST contain a Diameter compatibility section, outlining how
interoperability with Diameter will be maintained.

Furthermore, to ensure backward compatibility with existing RADIUS
implementations, as well as compatibility between RADIUS and Diameter, the
following restrictions are imposed on extensions considered by the RADEXT
WG:

- All documents produced MUST specify means of interoperation with legacy
RADIUS  and, if possible, be backward compatible with existing RADIUS RFCs,
including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, 5080,
5090, 5176 and 6158. Transport profiles should, if possible, be compatible
with RFC 3539.

Work Items
The immediate goals of the RADEXT working group are to address the following
issues:

- RADIUS attribute space extension. The standard RADIUS attribute space is
currently being depleted. This document will provide additional standard
attribute space, while maintaining backward compatibility with existing
attributes.

- IEEE 802 attributes. New attributes have been proposed to support IEEE 802
standards for wired and wireless LANs. This work item will support
authentication, authorization and accounting attributes needed by IEEE 802
groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16.

- New RADIUS transports. A reliable transport profile for RADIUS will be
developed, as well as specifications for Secure transports, including
TCP/TLS (RADSEC) and UDP/DTLS.

- Update and clarification of Network Access Identifiers (RFC4282).This work
item will correct and clarify issues present with RFC4282 in two phases.  In
first phase, RFC4282bis will be issued to eliminate fundamental
incompatibilities with RADIUS around character encoding and NAI
modifications by proxies.  In second phase, a fresh review of NAI
internationalization requirements and behavior will be undertaken with a
clear goal of maintaining compatibility with RADIUS.

- Fragmentation of RADIUS packets to support exchanges exceeding the
existing 4KB limit imposed by RFC2865.

Goals and Milestones
Done Updates to RFC 2618-2621 RADIUS MIBs submitted for publication
Done SIP RADIUS authentication draft submitted as a Proposed Standard RFC
Done RFC 2486bis submitted as a Proposed Standard RFC
Done RFC 3576 MIBs submitted as an Informational RFC
Done RADIUS VLAN and Priority Attributes draft submitted as a Proposed
Standard RFC (reduced in scope)
Done RADIUS Implementation Issues and Fixes draft submitted as an
Informational RFC
Done RADIUS Filtering Attributes draft submitted as a Proposed Standard RFC
(split out from VLAN & Priority draft)
Done RFC 3576bis submitted as an Informational RFC (split out from Issues &
Fixes draft)
Done RADIUS Redirection Attributes draft submitted as a Proposed Standard
RFC (split out from VLAN & Priority draft)
Done RADIUS Design Guidelines submitted as a Best Current Practice RFC
Done RADIUS Management Authorization I-D submitted as a Proposed Standard
RFC
Done Reliable Transport Profile for RADIUS I-D submitted as a Proposed
Standard RFC
Done Status-Server I-D submitted as a Proposed Standard RFC
Done RADIUS Crypto-agility Requirements submitted as an Informational RFC
Done RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RFC
Nov 2012 IPv6 Access I-D submitted as a Proposed Standard RFC
Nov 2012 RFC 4282bis submitted as a Proposed Standard RFC
Dec 2012 Extended Attributes I-D submitted as a Proposed Standard RFC
Dec 2012 Dynamic Discovery I-D submitted as a Proposed Standard RFC
Dec 2012 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC
Jan 2012 RADIUS over DTLS I-D submitted as an Experimental RFC
Feb 2012 RADIUS packet fragmentation submitted as an Experimental RFC
May 2013 RADIUS support for NAI Internationalization I-D submitted as a
Proposed Standard RFC

---

From: "Diego R. Lopez" <[email-masked]>
Date: Thu, 08 Nov 2012 14:34:59 +0000

Hi Mauricio,

Just a minor nuance on target dates, to avoid adding overdue items :)

On 7 Nov 2012, at 12:39 , Sanchez, Mauricio (HP Networking) wrote:

> May 2013 RADIUS support for NAI Internationalization I-D submitted as a Proposed Standard RFC

All the "2012" above should be "2013", right?

Be goode

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Benoit Claise <[email-masked]>
Date: Sun, 11 Nov 2012 15:13:50 -0500

Dear all,

The deadline is passed.
Let me submit the new charter to the IESG.
I changed the following dates to Dec 2012
     Nov 2012 IPv6 Access I-D submitted as a Proposed Standard RFC
     Nov 2012 RFC 4282bis submitted as a Proposed Standard RFC
Not that I want to delay the work, but if, for whatever reason, the 
charter approval is delayed, it would not make sense to have a draft 
deadline in the past. Regardless, progress the drafts ASAP

Regards, Benoit
> Pasted below is the current recharter proposal for radext.  The 
> largest change from the previous circulated proposal is the remove of 
> the traffic statistics work.  After consultation with our AD, we the 
> chairs have decided to postpone adding this work item until we have a 
> clearer understanding for scope of problem and solution .   Moreover, 
> we already have a number of items that are severely overdue and 
> several more solid individual submissions that are eminent work items 
> (pending this recharter).    We would like any feedback by EOB Friday 
> as our AD is ready to run this recharter text through the process.
>
> -Jouni and Mauricio
>
> The RADIUS Extensions Working Group will focus on extensions to the 
> RADIUS  protocol required to expand and enrich the standard attribute 
> space, address  cryptographic algorithm agility, use of new secure 
> transports and clarify its usage and definition.
>
> deployments, all RADEXT WG work items except those that just define 
> new attributes MUST contain a Diameter compatibility section, 
> outlining how interoperability with Diameter will be maintained.
>
>  implementations, as well as compatibility between RADIUS and 
> Diameter, the following restrictions are imposed on extensions 
> considered by the RADEXT WG:
>
> - All documents produced MUST specify means of interoperation with 
> legacy RADIUS  and, if possible, be backward compatible with existing 
> RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 
> 4668-4673,4675, 5080, 5090, 5176 and 6158. Transport profiles should, 
> if possible, be compatible with RFC 3539.
>
> Work Items
> The immediate goals of the RADEXT working group are to address the 
> following issues:
>
> - RADIUS attribute space extension. The standard RADIUS attribute 
> space is currently being depleted. This document will provide 
> additional standard attribute space, while maintaining backward 
> compatibility with existing attributes.
>
> - IEEE 802 attributes. New attributes have been proposed to support 
> IEEE 802 standards for wired and wireless LANs. This work item will 
> support authentication, authorization and accounting attributes needed 
> by IEEE 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16.
>
> - New RADIUS transports. A reliable transport profile for RADIUS will 
> be developed, as well as specifications for Secure transports, 
> including TCP/TLS (RADSEC) and UDP/DTLS.
>
> - Update and clarification of Network Access Identifiers 
> (RFC4282).This work item will correct and clarify issues present with 
> RFC4282 in two phases.  In first phase, RFC4282bis will be issued to 
> eliminate fundamental incompatibilities with RADIUS around character 
> encoding and NAI modifications by proxies.  In second phase, a fresh 
> review of NAI internationalization requirements and behavior will be 
> undertaken with a clear goal of maintaining compatibility with RADIUS.
>
> Done RADIUS Filtering Attributes draft submitted as a Proposed 
> Standard RFC (split out from VLAN & Priority draft)
> Done RFC 3576bis submitted as an Informational RFC (split out from 
> Issues & Fixes draft)
> Done RADIUS Redirection Attributes draft submitted as a Proposed 
> Standard RFC (split out from VLAN & Priority draft)
> Done RADIUS Management Authorization I-D submitted as a Proposed 
> Standard RFC
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

---

From: Benoit Claise <[email-masked]>
Date: Wed, 14 Nov 2012 18:16:16 +0100

FYI, this is now on the IESG telechat for Nov 29th.
It was too late for the IESG telechat tomorrow.

Regards, Benoit
>> support authentication, authorization and accounting attributes 
>> needed by IEEE 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 
>> 802.16.
>>
>> Done RADIUS VLAN and Priority Attributes draft submitted as a 
>> Proposed Standard RFC (reduced in scope)
>> Done Reliable Transport Profile for RADIUS I-D submitted as a 
>> Proposed Standard RFC

---

From: Leaf yeh <[email-masked]>
Date: Mon, 26 Nov 2012 11:26:21 +0000

Jouni and Mauricio - Pasted below is the current recharter proposal for radext.  The largest change from the previous circulated proposal is the remove of the traffic statistics work.  After consultation with our AD, we the chairs have decided to postpone adding this work item until we have a clearer understanding for scope of problem and solution .

After reading this, my curious question turns to be how long  we will need to figure out the 'scope of problem and solution' for the potential work item of 'traffic statistics'?

Best Regards,
Leaf

------------------------------------------------------
From: [email-masked] [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Monday, November 12, 2012 4:14 AM
To: Sanchez, Mauricio (HP Networking)
Cc: [email-masked]
Subject: Re: [radext] RADEXT recharter proposal

Dear all,

The deadline is passed.
Not that I want to delay the work, but if, for whatever reason, the charter approval is delayed, it would not make sense to have a draft deadline in the past. Regardless, progress the drafts ASAP

Regards, Benoit
Pasted below is the current recharter proposal for radext.  The largest change from the previous circulated proposal is the remove of the traffic statistics work.  After consultation with our AD, we the chairs have decided to postpone adding this work item until we have a clearer understanding for scope of problem and solution .   Moreover, we already have a number of items that are severely overdue and several more solid individual submissions that are eminent work items (pending this recharter).    We would like any feedback by EOB Friday as our AD is ready to run this recharter text through the process.   

-Jouni and Mauricio 

The RADIUS Extensions Working Group will focus on extensions to the RADIUS  protocol required to expand and enrich the standard attribute space, address  cryptographic algorithm agility, use of new secure transports and clarify its usage and definition.

In order to maintain interoperation of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items except those that just define new attributes MUST contain a Diameter compatibility section, outlining how interoperability with Diameter will be maintained.

Furthermore, to ensure backward compatibility with existing RADIUS  implementations, as well as compatibility between RADIUS and Diameter, the following restrictions are imposed on extensions considered by the RADEXT WG:

- All documents produced MUST specify means of interoperation with legacy RADIUS  and, if possible, be backward compatible with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, 5080, 5090, 5176 and 6158. Transport profiles should, if possible, be compatible with RFC 3539.

Work Items
The immediate goals of the RADEXT working group are to address the following issues:

- RADIUS attribute space extension. The standard RADIUS attribute space is currently being depleted. This document will provide additional standard attribute space, while maintaining backward compatibility with existing attributes.

- IEEE 802 attributes. New attributes have been proposed to support IEEE 802 standards for wired and wireless LANs. This work item will support authentication, authorization and accounting attributes needed by IEEE 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16.

- New RADIUS transports. A reliable transport profile for RADIUS will be developed, as well as specifications for Secure transports, including TCP/TLS (RADSEC) and UDP/DTLS.

- Update and clarification of Network Access Identifiers (RFC4282).This work item will correct and clarify issues present with RFC4282 in two phases.  In first phase, RFC4282bis will be issued to eliminate fundamental incompatibilities with RADIUS around character encoding and NAI modifications by proxies.  In second phase, a fresh review of NAI internationalization requirements and behavior will be undertaken with a clear goal of maintaining compatibility with RADIUS.

- Fragmentation of RADIUS packets to support exchanges exceeding the existing 4KB limit imposed by RFC2865.

Goals and Milestones
Done Updates to RFC 2618-2621 RADIUS MIBs submitted for publication
Done SIP RADIUS authentication draft submitted as a Proposed Standard RFC
Done RFC 2486bis submitted as a Proposed Standard RFC
Done RFC 3576 MIBs submitted as an Informational RFC
Done RADIUS VLAN and Priority Attributes draft submitted as a Proposed Standard RFC (reduced in scope)
Done RADIUS Implementation Issues and Fixes draft submitted as an Informational RFC
Done RADIUS Filtering Attributes draft submitted as a Proposed Standard RFC (split out from VLAN & Priority draft)
Done RFC 3576bis submitted as an Informational RFC (split out from Issues & Fixes draft)
Done RADIUS Redirection Attributes draft submitted as a Proposed Standard RFC (split out from VLAN & Priority draft)
Done RADIUS Design Guidelines submitted as a Best Current Practice RFC
Done RADIUS Management Authorization I-D submitted as a Proposed Standard RFC
Done Reliable Transport Profile for RADIUS I-D submitted as a Proposed Standard RFC
Done Status-Server I-D submitted as a Proposed Standard RFC
Done RADIUS Crypto-agility Requirements submitted as an Informational RFC
Done RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RFC
Nov 2012 IPv6 Access I-D submitted as a Proposed Standard RFC
Nov 2012 RFC 4282bis submitted as a Proposed Standard RFC
Dec 2012 Extended Attributes I-D submitted as a Proposed Standard RFC
Dec 2012 Dynamic Discovery I-D submitted as a Proposed Standard RFC
Dec 2012 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC
Jan 2012 RADIUS over DTLS I-D submitted as an Experimental RFC
Feb 2012 RADIUS packet fragmentation submitted as an Experimental RFC
May 2013 RADIUS support for NAI Internationalization I-D submitted as a Proposed Standard RFC

---

From: Alan DeKok <[email-masked]>
Date: Mon, 26 Nov 2012 10:19:40 -0500

> After reading this, my curious question turns to be how long  we will need to figure out the 'scope of problem and solution' for the potential work item of 'traffic statistics'?

  That depends on the cooperation of the people involved.

  As an example, I've reviewed your proposal, and Stefan's.  Perhaps you
could review my IPFIX proposal.

  Alan DeKok.