IETF Logo Mail Archive

Re: [radext] Consensus call for changing intended RFC status of draft-ietf-radext-tls-psk

Alan DeKok <aland@deployingradius.com> Sun, 04 February 2024 03:27 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 522F3C14F695 for <radext@ietfa.amsl.com>; Sat, 3 Feb 2024 19:27:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.906
X-Spam-Level:
X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mq9ohLwHP_54 for <radext@ietfa.amsl.com>; Sat, 3 Feb 2024 19:27:36 -0800 (PST)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBDB5C14F696 for <radext@ietf.org>; Sat, 3 Feb 2024 19:27:35 -0800 (PST)
Received: from smtpclient.apple (135-23-95-173.cpe.pppoe.ca [135.23.95.173]) by mail.networkradius.com (Postfix) with ESMTPSA id 49793211; Sun, 4 Feb 2024 03:27:31 +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 16.0 \(3696.120.41.1.1\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <d3abdba6-e70c-4bff-986a-bb956f7a829c@switch.ch>
Date: Sat, 03 Feb 2024 22:27:30 -0500
Cc: radext@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <373566FE-F492-41CF-A660-F11CF58857BB@deployingradius.com>
References: <003c01da4f63$0109b160$031d1420$@smyslov.net> <d3abdba6-e70c-4bff-986a-bb956f7a829c@switch.ch>
To: Fabian Mauchle <fabian.mauchle=40switch.ch@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/RTn1XjfIej7HEmle7-xmW578iPc>
Subject: Re: [radext] Consensus call for changing intended RFC status of draft-ietf-radext-tls-psk
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.39
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: Sun, 04 Feb 2024 03:27:41 -0000

On Feb 2, 2024, at 4:55 AM, Fabian Mauchle <fabian.mauchle=40switch.ch@dmarc.ietf.org> wrote:
> IIRC the RFC status is described in RFC2026.

  Yes.   Some informal discussion is at https://www.ietf.org/standards/process/informal/

> Whether BCP is the correct status, I do lack a bit of understanding what that actually implies.
> RFC2026 talks about technical statement (TS) and applicability statement (AS) - i guess tls-psk would fall into the latter category - but never mentions how TS and AS would influence the choice of status.

  It's largely up the the working group, subject to the approval of the IESG.

> On the other hand, BCPs (can) consist of multiple RFC, so BCP would not just be the RFC status, but also be assigned a BCP number?

  I presume so, yes.

> So I'm a bit lost whether applicability statements should just be standards-track or BCPs. Any educational material appreciated.

  The documents are public, and somewhat unclear.  Whether this is good or bad depends on how well the process is working.

  BCP or  proposed standard seems OK.

  "Informational" seems wrong, we do want it to be a standard.

  Full "standard" seems premature.

  "Experimental" might be OK, The RADIUS/TLS documents were experimental for a while.

  Overall, I think the uncertainty in the status of this document simply reflects the uncertainty in the standards process.  We should just pick one, and move on.

  Alan DeKok.

v2.23.0 | Report a Bug | By Email