[radext] the future of RADEXT

Benjamin Kaduk <kaduk@mit.edu> Tue, 08 February 2022 18:59 UTC

Return-Path: <kaduk@mit.edu>
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 974AC3A10B2 for <radext@ietfa.amsl.com>; Tue, 8 Feb 2022 10:59:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level:
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no 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 oOsdB9N2VCdp for <radext@ietfa.amsl.com>; Tue, 8 Feb 2022 10:59:28 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD50D3A1083 for <radext@ietf.org>; Tue, 8 Feb 2022 10:59:27 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 218IxLeu018225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <radext@ietf.org>; Tue, 8 Feb 2022 13:59:25 -0500
Date: Tue, 08 Feb 2022 10:59:20 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: radext@ietf.org
Message-ID: <20220208185920.GK48552@kduck.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/_FtimLquGVY8e_EL6qSvCm15PFw>
Subject: [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 18:59:32 -0000

Dear all,

The RADEXT list has seen only minimal activity since the publication of RFC
8559 in 2019, with those few topics that do come in mostly getting
redirected to OPSAWG as a more useful venue for making progress.

I confess I have been a bit negligent in letting the group linger in this
state for so long and not putting more energy into it.  That said, the
facts on the ground remain that we don't have any active drafts and there
does not seem to be much energy remaining to discuss the proposals for how
to resolve the limited 8-bit size of the RADIUS datagram's Identifier
field.

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.

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

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.

Thanks,

Ben