Re: [radext] the future of RADEXT

Alan DeKok <aland@deployingradius.com> Tue, 08 February 2022 19:26 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41FBF3A114A for <radext@ietfa.amsl.com>; Tue, 8 Feb 2022 11:26:01 -0800 (PST)
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 scLykPbF5QtF for <radext@ietfa.amsl.com>; Tue, 8 Feb 2022 11:25:56 -0800 (PST)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90E6B3A1086 for <radext@ietf.org>; Tue, 8 Feb 2022 11:25:55 -0800 (PST)
Received: from smtpclient.apple (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 216BB109; Tue, 8 Feb 2022 19:25:52 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <20220208185920.GK48552@kduck.mit.edu>
Date: Tue, 08 Feb 2022 14:25:51 -0500
Cc: radext@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <46636323-221D-4CBE-9E97-8425A82F2460@deployingradius.com>
References: <20220208185920.GK48552@kduck.mit.edu>
To: Benjamin Kaduk <kaduk@mit.edu>
X-Mailer: Apple Mail (2.3693.60.0.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/6CfnCQ-TmQ_VIei0Dw23z5rs1BM>
Subject: Re: [radext] the future of RADEXT
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 08 Feb 2022 19:26:01 -0000

On Feb 8, 2022, at 1:59 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
> As such, I believe that we should close the RADEXT WG and continue to
> redirect further RADIUS work to OPSAWG, including solutions for the
> Identifier problem if energy appears to work on them.

  I think that's reasonable.

> Please let me know (on list is fine) if you have concerns about this plan
> by 22 February 2022, along with any alternative proposals that might
> address those concerns.  However, in order to demonstrate that there is
> energy to keep the WG open and make progress on our remaining chartered
> item, I would need to see interest from multiple individuals in pursuing
> such a course of action, along with an estimate for when such work would
> ultimately be completed (that would function as a deadline for re-assessing
> the WG's progress and possibly closing the WG if insufficient progress is
> being made).

  I'm happy to work on RADIUS things.  It would be useful to standardize RFC 6613, 6614, and 7360.  Along with updating them for TLS 1.3, and adding things like Server Name Indicator.

  I suspect, however, that there is limited interest, even though such work would be useful.

> This is by no means a failure outcome; the WG has produced a lot of good
> work and we should be proud of what we have accomplished even as we look
> forward to what might be done in OPSAWG in the future.

  I agree.

  Alan DeKok.