Re: [radext] Control of RFC 3580. Transfer to RADIUS WG possible?

Alan DeKok <aland@deployingradius.com> Wed, 07 October 2015 14:50 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755321A90DA for <radext@ietfa.amsl.com>; Wed, 7 Oct 2015 07:50:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgunou1rJ7QW for <radext@ietfa.amsl.com>; Wed, 7 Oct 2015 07:50:57 -0700 (PDT)
Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 53C911A9150 for <radext@ietf.org>; Wed, 7 Oct 2015 07:50:57 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 4249022406F2; Wed, 7 Oct 2015 16:50:26 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at power.freeradius.org
Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sntBIAtXDXNK; Wed, 7 Oct 2015 16:50:25 +0200 (CEST)
Received: from [192.168.20.14] (65-110-217-180.cpe.pppoe.ca [65.110.217.180]) by power.freeradius.org (Postfix) with ESMTPSA id 64D392240451; Wed, 7 Oct 2015 16:50:25 +0200 (CEST)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <11393_1444227411_56152953_11393_5293_1_6B7134B31289DC4FAF731D844122B36E01D3D6BC@OPEXCLILM43.corporate.adroot.infra.ftgroup>
Date: Wed, 07 Oct 2015 10:50:23 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <050EA58C-6BF9-4DC0-AFFC-FAC9285B039A@deployingradius.com>
References: <CAGnO3dp-=6cODkAgV7R6vjTYWz0BXoODY3kPO37-iJ9ve-407g@mail.gmail.com> <5310AA34-D3C1-4B12-A691-1DF427904DF1@deployingradius.com> <CAHbuEH47h2yk19BR11TaOnnZGR_8FnLgnCf7zJUukRP7GJq4sg@mail.gmail.com> <451E43F5-44DF-4651-8372-49BC90DFEC5A@deployingradius.com> <11393_1444227411_56152953_11393_5293_1_6B7134B31289DC4FAF731D844122B36E01D3D6BC@OPEXCLILM43.corporate.adroot.infra.ftgroup>
To: "lionel.morand@orange.com" <lionel.morand@orange.com>
X-Mailer: Apple Mail (2.3094)
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/_vtB2WubvYe7BKkTLLRd5X_tTNY>
Cc: Nick Lowe <nick.lowe@lugatech.com>, "radext@ietf.org" <radext@ietf.org>, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Subject: Re: [radext] Control of RFC 3580. Transfer to RADIUS WG possible?
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Oct 2015 14:50:59 -0000

On Oct 7, 2015, at 10:16 AM, <lionel.morand@orange.com> <lionel.morand@orange.com> wrote:
> Obviously, it does not prevent RADEXT to work on a new version of this document. However, before rushing for publishing a bis-version of this document, it would be good to know what would be the purpose of this new document.

  To bring the standards up to date with current requirements, and with current use-cases.  To address ambiguities in the current specifications.  To clarify best practices.
 
> The initial aim was to have non-normative text describing how to use RADIUS with 802.1X, and this material was put in an information RFC as well as in a non-normative appendix in IEEE specification. 
> 
> I know that some cleanup/updates/clarifications are required for this document. But to be really useful,  it could be interesting to know whether IEEE would be happy to endorse/reference the new version of the RFC, especially if some proposed changes have impacts on existing RADIUS implementation. Just to ensure that the proposed modifications/clarifications put in a bis-version will be followed by IEEE community.

  I agree.

> And also, what should be the status of this document: Standard track/Informational?

  Probably the same as RFC 3580, informational.

> Now, if the work is agreed, the proposed changes straightforward and there is no contentious discussions, I don't see why a 3-year period would be required to publish a new version. It will depend on the amount and type of change.

  I agree.  I'll work with Nick to come up with an I-D.  I won't be in Yokohama, but I can do a remote presentation.

  Alan DeKok.