Subject: [radext] RADEXT recharter

From: "Sanchez, Mauricio (HP Networking)" <[email-masked]>
Date: Mon, 23 Jan 2012 22:11:22 +0000

At IETF 82, the RADEXT WG discussed (see notes section 7
http://www.ietf.org/proceedings/82/minutes/radext.txt) updating the
charter to position the WG to be able to embrace several work items that
the WG believes relevant, as well as recalibrating dates on several
committed goals.  

Below is the new proposed WG charter that your chairs and AD agreed upon.
Attached are a PDF version of updated milestones and a marked version
detailing changes introduced from existing charter. At this time the
chairs would like to open up the list for discussion. Propose your changes
and justify why.  

Our aim is to have this re-chartering discussion completed by next IETF
meeting.  

- Mauricio and Jouni

---------

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 enable interoperation of heterogeneous RADIUS/Diameter
deployments, all RADEXT WG work items 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 and 5176. Transport profiles should, if possible, be compatible with
RFC 3539.

- All RADIUS work MUST be compatible with equivalent facilities in
Diameter. Where possible, new attributes should be defined so that the
same attribute can be used in both RADIUS and Diameter without
translation. In other cases a translation considerations section should be
included in the specification.

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

-RADIUS design guidelines. This document will provide guidelines for
design of RADIUS attributes. It will specifically consider how complex
data types may be introduced in a robust manner, maintaining backwards
compatibility with existing RADIUS RFCs, across all the classes of
attributes: Standard, Vendor-Specific and SDO-Specific. In addition, it
will review RADIUS data types and associated backwards compatibility
issues.

-RADIUS Management authorization. This document will define the use of
RADIUS for NAS management over IP.

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

-RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally relied
on MD5 for both per-packet integrity and authentication as well as
attribute confidentiality. Given the increasingly successful attacks being
mounted against MD5, the ability to support alternative algorithms is
required. This work item will include documentation of RADIUS
crypto-agility requirements, as well as development of one or more
Experimental RFCs providing support for negotiation of alternative
cryptographic algorithms to protect RADIUS.

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

- Documentation of Status-Server usage. A document describing usage of the
Status-Server facility will be developed.

- Update and clarification of Network Access Identifiers (RFC4282).This
work item will correct and clarify egregious 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.

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
Jan 2012	RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental
RFC
Feb 2012	IPv6 Access I-D submitted as a Proposed Standard RFC
Feb 2012	Extended Attributes I-D submitted as a Proposed Standard RFC
Feb 2012	Dynamic Discovery I-D submitted as a Proposed Standard RFC
Mar 2012	RFC 4282bis submitted as a Proposed Standard RFC
Mar 2012	RADIUS over DTLS I-D submitted as an Experimental RFC
Apr 2012	IEEE 802 Attributes I-D submitted as a Proposed Standard RFC
Oct 2012	RADIUS support for NAI Internationalization I-D submitted as a
Proposed Standard RFC 

_______________________________________________
radext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/radext

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 23 Jan 2012 14:26:43 -0800

Looks good to me.  Hasn't the RADIUS over TLS draft already been submitted? (it's in IETF LC)

From: [email-masked]
To: [email-masked]
Date: Mon, 23 Jan 2012 22:11:22 +0000
Subject: [radext] RADEXT recharter

 
 
- Mauricio and Jouni

---------

 

 
Work Items

 

 

 
Goals and Milestones

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 23 Jan 2012 14:26:43 -0800

- Mauricio and Jouni

---------

 

 
Work Items

 

 

 
Goals and Milestones

---

From: Dave Nelson <[email-masked]>
Date: Mon, 23 Jan 2012 17:28:41 -0500

Hi Mauricio,

I'm a bit confused about a couple of the RADEXT work items that remain in
the revised charter proposal, specifically"

> will review RADIUS data types and associated backwards compatibility

This has been published as RFC 6158 for "classic" RADIUS atributes, and
the corresponding guidance for "extended" atributes is included in the
extended attributes ID.

> RADIUS for NAS management over IP.

This has been published as RFC 5607.

> cryptographic algorithms to protect RADIUS.

This has been published as RFC 6421 .

This has been published as RFC 5997.

Unless there are new problem statements in any of these areas, I think that
these work items can be removed from teh revised charter.

Regards,

Dave

David B. Nelson
Sr. Software Architect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

---

From: Dave Nelson <[email-masked]>
Date: Mon, 23 Jan 2012 17:28:41 -0500

Hi Mauricio,

Regards,

Dave

David B. Nelson
Sr. Software Architect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

---

From: Stefan Winter <[email-masked]>
Date: Tue, 24 Jan 2012 08:00:53 +0100

Hi,

> submitted? (it's in IETF LC)

Related: RADIUS/TLS will be Experimental, while Dynamic Discovery is
sketched as Proposed Standard. The dynamic discovery draft has
RADIUS/TLS as a normative reference.
I'm not entirely sure about the process, but - is it okay for Standards
track to have a normative reference on Experimental?

Also, Feb 2012 for submission seems a bit too ambitious for me. I will
certainly issue a new rev before Paris, but it will need WGLC etc. so I
don't see how Feb 2012 could be achievable. I'm thinking April at the
earliest.

(If we aim to approve the new charter by Paris, it will already be
March; seems odd that we will have to discuss dates in the past then)

Greetings,

Stefan Winter

> _______________________________________________ radext mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/radext
> 
> 

-- 
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: Stefan Winter <[email-masked]>
Date: Tue, 24 Jan 2012 08:00:53 +0100

Hi,

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Tina TSOU <[email-masked]>
Date: Tue, 24 Jan 2012 07:11:07 +0000

Sent from my iPad

> track to have a normative reference on Experimental?
In theory, yes.

---

From: Tina TSOU <[email-masked]>
Date: Tue, 24 Jan 2012 07:11:07 +0000

Sent from my iPad

In theory, yes.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 24 Jan 2012 12:52:16 +0100

Hi,

A normative document referencing an Experimental RFC is a downref. Although it is recommended to avoid them to the possible extent, they can be approved if the community agrees, or in other terms of they are explicitly spelled out during the IETF Last Call. 

A list of downrefs and a few more details on the procedures can be found at http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Stefan Winter
> Sent: Tuesday, January 24, 2012 9:01 AM
> To: [email-masked]
> Subject: Re: [radext] RADEXT recharter
> 
> Hi,
> 
> > charter to position the WG to be able to embrace several work items
> > that the WG believes relevant, as well as recalibrating dates on
> > several committed goals.
> >
> > chairs would like to open up the list for discussion. Propose your
> > changes and justify why.
> >
> > Our aim is to have this re-chartering discussion completed by next
> > IETF meeting.
> >
> > - Mauricio and Jouni
> >
> >
> > ---------
> >
> > 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.
> >
> > 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 and 5176. Transport profiles should, if
> > possible, be compatible with RFC 3539.
> >
> > translation. In other cases a translation considerations section
> > should be included in the specification.
> >
> > Work Items
> > attributes: Standard, Vendor-Specific and SDO-Specific. In addition,
> > it will review RADIUS data types and associated backwards
> > compatibility 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.
> >
> > -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally
> > relied on MD5 for both per-packet integrity and authentication as
> well
> > as attribute confidentiality. Given the increasingly successful
> > attacks being mounted against MD5, the ability to support alternative
> > algorithms is required. This work item will include documentation of
> > RADIUS crypto-agility requirements, as well as development of one or
> > more Experimental RFCs providing support for negotiation of
> > alternative cryptographic algorithms to protect RADIUS.
> >
> > 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.
> >
> > - Documentation of Status-Server usage. A document describing usage
> of
> > the Status-Server facility will be developed.
> >
> > - Update and clarification of Network Access Identifiers
> > (RFC4282).This work item will correct and clarify egregious 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.
> >
> > Goals and Milestones
> de la Recherche 6, rue Richard Coudenhove-Kalergi
> L-1359 Luxembourg
> 
> Tel: +352 424409 1
> Fax: +352 422473

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 24 Jan 2012 12:52:16 +0100

Hi,

Dan

---

From: Sam Hartman <[email-masked]>
Date: Tue, 24 Jan 2012 06:58:39 -0500

>>>>> "Stefan" == Stefan Winter <[email-masked]> writes:

    Stefan> Hi,
    >> submitted? (it's in IETF LC)

    Stefan> Related: RADIUS/TLS will be Experimental, while Dynamic
    Stefan> Discovery is sketched as Proposed Standard. The dynamic
    Stefan> discovery draft has RADIUS/TLS as a normative reference.
    Stefan> I'm not entirely sure about the process, but - is it okay
    Stefan> for Standards track to have a normative reference on
    Stefan> Experimental?

There is a procedure for doing this, but I don't understand why it is
appropriate in this instance.
In my mind the dynamic discovery stuff is far more experimental than
RADIUS over TLS.
_______________________________________________
radext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/radext

---

From: Sam Hartman <[email-masked]>
Date: Tue, 24 Jan 2012 06:58:39 -0500

Stefan> Hi,

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 24 Jan 2012 13:21:08 +0100

Hi,

As Dave Nelson already pointed out, two of the documents in the charter
were already approved as RFCs. Also the milestones need to be revisited
in case the discussions of this new charter continue until IETF-83 (end
of March 2012) because most of them target January - March 2012. 

Regards,

Dan

> Behalf Of Sanchez, Mauricio (HP Networking)
> Sent: Tuesday, January 24, 2012 12:11 AM
> To: [email-masked]
IETF
> implementations, as well as compatibility between RADIUS and Diameter,
> the following restrictions are imposed on extensions considered by the
> RADEXT
> WG:
> 
> RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-
> 4673,4675, 5080, 5090 and 5176. Transport profiles should, if
possible,
> be compatible with RFC 3539.
> 
should
> be included in the specification.
> 
> Work Items
it
> -RADIUS attribute space extension. The standard RADIUS attribute space
with
> existing attributes.
> relied on MD5 for both per-packet integrity and authentication as well
attacks
> being mounted against MD5, the ability to support alternative
alternative
> authentication, authorization and accounting attributes needed by IEEE
> - Documentation of Status-Server usage. A document describing usage of
(RFC4282).This
> work item will correct and clarify egregious 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.
> 
> Goals and Milestones
> Done		RADIUS Implementation Issues and Fixes draft submitted
as
> an
> Informational RFC
> Done		RADIUS Filtering Attributes draft submitted as a
Proposed
> Standard
> Done		RADIUS Redirection Attributes draft submitted as a
Proposed
> Standard
> Done		RADIUS Management Authorization I-D submitted as a
Proposed
> Standard
> Oct 2012	RADIUS support for NAI Internationalization I-D
submitted
> as a

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 24 Jan 2012 13:21:08 +0100

Hi,

Regards,

Dan

IETF
possible,
should
it
with
attacks
alternative
(RFC4282).This
as
Proposed
Proposed
Proposed
submitted

---

From: Dave Nelson <[email-masked]>
Date: Tue, 24 Jan 2012 08:07:38 -0500

On Tue, Jan 24, 2012 at 7:21 AM, Romascanu, Dan (Dan) <[email-masked]>wrote:

> were already approved as RFCs.

By the time I finished composing my reply, I actually found four such RFCs:
5607, 5997, 6158, 6421.

Regards,

Dave

David B. Nelson
Sr. Software Architect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

---

From: Dave Nelson <[email-masked]>
Date: Tue, 24 Jan 2012 08:07:38 -0500

Regards,

Dave

David B. Nelson
Sr. Software Architect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

---

From: Alan DeKok <[email-masked]>
Date: Tue, 24 Jan 2012 16:51:37 +0100

> 5090 and 5176. Transport profiles should, if possible, be compatible with

  Add 6158.

> The immediate goals of the RADEXT working group are to address the

  I agree with Dave's comments here.

> in two phases.

  While I might like the word "egregious", it might be too strong for
charter text.

>  In first phase, RFC4282bis will be issued to eliminate

  I don't see how the two phases can be separated.  A solution to either
phase involves using much of the work from the other phase.

> Goals and Milestones
...
> Oct 2012	RADIUS support for NAI Internationalization I-D submitted as a

  I like that timeframe.  But I having a 2 year deadline is more
realistic.  The issues were first brought up as important 2-3 years ago,
and little has happened since.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 24 Jan 2012 16:51:37 +0100

Add 6158.

...

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 24 Jan 2012 17:44:08 -0800

Alan said:

"While I might like the word "egregious", it might be too strong for charter
text"

[BA] I would prefer not to use the word "egregious" as a bar for deciding
which mistakes in RFC 4282 will be fixed and which won't.   The main
constraint should be scope -- the problem with RFC 4282 was (incorrectly)
expanding the scope of what the document covered, beyond just fixing errors
in RFC 2486.  We should try to not make the same mistake with RFC 4282.  The
focus of RFC 4282bis should be on the NAI, not on internationalization in
AAA -- that is for a separate document.

Alain said:

"I don't see how the two phases can be separated.  A solution to either
phase involves using much of the work from the other phase."

[BA] The major error of RFC 4282 is its implicit assertion that
internationalization is somehow a function of the NAI itself, rather than
being dictated by the protocol within which the NAI is transmitted.   If we
correct this basic error in RFC 422, and fix the ABNF, then we will have
defused the ticking time bomb that is RFC 4282.   We can then move on to
another document describing internationalization issues in RADIUS.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 24 Jan 2012 17:44:08 -0800

Alan said:

Alain said:

---

From: Alan DeKok <[email-masked]>
Date: Wed, 25 Jan 2012 12:42:46 +0100

> another document describing internationalization issues in RADIUS.  

  I understand.

  OK, I'm in agreement.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 25 Jan 2012 12:42:46 +0100

I understand.

  OK, I'm in agreement.

  Alan DeKok.

---

From: "Sanchez, Mauricio (HP Networking)" <[email-masked]>
Date: Wed, 25 Jan 2012 17:28:34 +0000

Removed items noted below in forthcoming 2nd draft.

MS

From: Dave Nelson <[email-masked]<mailto:[email-masked]>>
Date: Mon, 23 Jan 2012 22:28:41 +0000
To: Mauricio Sanchez <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [radext] RADEXT recharter

Hi Mauricio,

I'm a bit confused about a couple of the RADEXT work items that remain in the revised charter proposal, specifically"

This has been published as RFC 6158 for "classic" RADIUS atributes, and the corresponding guidance for "extended" atributes is included in the extended attributes ID.

Unless there are new problem statements in any of these areas, I think that these work items can be removed from teh revised charter.

Regards,

Dave

David B. Nelson
Sr. Software Architect
Elbrys Networks, Inc.
www.elbrys.com<http://www.elbrys.com>
+1.603.570.2636

---

From: "Sanchez, Mauricio (HP Networking)" <[email-masked]>
Date: Wed, 25 Jan 2012 17:28:34 +0000

MS

Hi Mauricio,

Regards,

Dave

David B. Nelson
Sr. Software Architect
Elbrys Networks, Inc.

---

From: "Sanchez, Mauricio (HP Networking)" <[email-masked]>
Date: Wed, 25 Jan 2012 17:29:09 +0000

Updated delivery date of dynamic discovery to April 2012 in forthcoming
2nd draft.

MS

On 1/23/12 11:00 PM, "Stefan Winter" <[email-masked]> wrote:

>>changes
>>RADIUS
>>legacy
>>is
>>802

---

From: "Sanchez, Mauricio (HP Networking)" <[email-masked]>
Date: Wed, 25 Jan 2012 17:29:09 +0000

MS

---

From: "Sanchez, Mauricio (HP Networking)" <[email-masked]>
Date: Wed, 25 Jan 2012 17:46:44 +0000

>> 5090 and 5176. Transport profiles should, if possible, be compatible

Done in forthcoming 2nd draft.

>  While I might like the word "egregious", it might be too strong for

Removed 'egregious' so as not to ruffle more feathers than necessary in
forthcoming 2nd draft.

>phase involves using much of the work from the other phase.

At IETF 82 the following proposal was discussed (as noted by the minutes)
"-2 distinct questions - 1 to get rid of what should never have been there
in the future. 2 to deal with internationalization questions.in RADIUS.
Could get rid of 4282 as a first step, then address internationalization,
EAP."

Does the following text better capture the consensus form IETF 82?

"In first phase, RFC4282bis will be issued to deprecate RFC4282 and
eliminate the fundamental RADIUS incompatibilities it exhibits.In second
phase, a fresh review of NAI internationalization requirements and
behavior will be undertaken with a clear goal of maintaining compatibility
with RADIUS."

>and little has happened since.

Call it illusions of grandeur.

-MS

---

From: "Sanchez, Mauricio (HP Networking)" <[email-masked]>
Date: Wed, 25 Jan 2012 17:46:44 +0000

-MS

---

From: Stig Venaas <[email-masked]>
Date: Wed, 25 Jan 2012 13:48:24 -0800

On 1/24/2012 3:58 AM, Sam Hartman wrote:
>>>>>> "Stefan" == Stefan Winter<[email-masked]>  writes:
>
>      Stefan>  Hi,

I agree. It seems a bit odd the way it is now. I don't remember why
RADIUS over TLS was decided to be experimental. Dynamic discovery
certainly sounds experimental though.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Wed, 25 Jan 2012 13:48:24 -0800

Stig

---

From: Klaas Wierenga <[email-masked]>
Date: Wed, 25 Jan 2012 22:58:43 +0100

> certainly sounds experimental though.

I agree too. Is there any procedure for reclassifying the draft?

Klaas

---

From: Klaas Wierenga <[email-masked]>
Date: Wed, 25 Jan 2012 22:58:43 +0100

Klaas

---

From: "David B. Nelson" <[email-masked]>
Date: Wed, 25 Jan 2012 17:56:52 -0500

> I agree too. Is there any procedure for reclassifying the draft?

Perhaps because all RADIUS Crypto-Agility solutions are to be published as experimental until field experience sorts out which should become standards track?

---

From: "David B. Nelson" <[email-masked]>
Date: Wed, 25 Jan 2012 17:56:52 -0500

---

From: Stefan Winter <[email-masked]>
Date: Thu, 26 Jan 2012 07:55:14 +0100

Hi,

> Perhaps because all RADIUS Crypto-Agility solutions are to be published as experimental until field experience sorts out which should become standards track?

Right, that was the reason for making RADIUS/TLS Experimental in the
first place. It is also what the new paragraph "Document Status" in the
upcoming draft rev states (see my message yesterday).

I see Klaas' argument more the other way around: shouldn't we reclassify
dynamic discovery to also be Experimental?

As time passes by, maybe/hopefully RADIUS/TLS will be selected for
staandards track, and then dynamic discovery could follow some time later.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Thu, 26 Jan 2012 07:55:14 +0100

Hi,

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Alan DeKok <[email-masked]>
Date: Thu, 26 Jan 2012 08:45:55 +0100

> behavior will be undertaken with a clear goal of maintaining compatibility

  That is clearer to me.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 26 Jan 2012 08:45:55 +0100

That is clearer to me.

  Alan DeKok.