[radext] Re: [iesg] Re: Roman Danyliw's Block on charter-ietf-radext-07-03: (with BLOCK)
Valery Smyslov <valery@smyslov.net> Mon, 15 June 2026 15:48 UTC
Return-Path: <valery@smyslov.net>
X-Original-To: radext@mail2.ietf.org
Delivered-To: radext@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 5B36F101946BB; Mon, 15 Jun 2026 08:48:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1781538506; bh=+ddSd14WPLkKw6AIZWl4ENspfKNWo3KzSbH6ynC4+y4=; h=From:To:Cc:References:In-Reply-To:Subject:Date; b=OHG4rRr5xqCxOHPxJ3+CdfGlfZd9OwcRW0WtkSk793iuj57dEllBq2fmUK/lKiyCn ys1Z1AFQjHvlsIGyyVKHpMxBxa+iKzFHvL6KPTowlVuVhq0nqQFWgmsm4QM+uwpqOZ 03xMP3WMO9wNs18OJeG7FoQkM2+17tGcKGIqxAII=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=smyslov.net
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88h-rUNgsXsT; Mon, 15 Jun 2026 08:48:25 -0700 (PDT)
Received: from jet.bitexo.com (jet.bitexo.com [162.214.66.187]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id DF0AA101946B2; Mon, 15 Jun 2026 08:48:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smyslov.net ; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :Date:Subject:In-Reply-To:References:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=2L8Pgac4pVv1PldJFdsKe2FbCFDXftBU+Cjk38XbOA8=; b=fTNGz+4PNtU344frzf7wbdAM0p sazazlcz5K2ehZqo6BLAcBm32K9vmuxqxsW+Lt3QiSeFBt31TTGYj3qCjfMuP5AXLaKByFBu55oaq JYNFRz+9ronNgVFKV1Z7nN7m5Pm9wTapcWqErSyd4F9QoWFTBHfMBFSvnMlD0JIKdBSgJW1NpEr79 Z+ngAoKwygg05nXAL/YKpZFLVe4e9dKrjdk+ukPyNlINAab6dEYNwcMUF7ND2rqLQYwEH9QPE1USX AB10tPEyuDDq95xWQjTVlVkQJWwGJpKR4EF+DipIttHvuOtv6HlNuQhP8xhh+e9iyRQxiIUSfUQOj fMtmRk9Q==;
Received: from [93.188.44.204] (port=55184 helo=BuildPC) by jet.bitexo.com with essmtpa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.99.4) (envelope-from <valery@smyslov.net>) id 1wZ9Xt-00000008CzP-3rhZ; Mon, 15 Jun 2026 11:48:18 -0400
From: Valery Smyslov <valery@smyslov.net>
To: 'Alan DeKok' <alan.dekok@inkbridge.io>, 'Roman Danyliw' <rdd@cert.org>
References: <178129125347.128714.4341021419445719983@dt-datatracker-f9b87776f-8pmmg> <FE531461-7E4D-461D-8232-B9A9E21F12B4@inkbridge.io> <BN2P110MB1107F08A80BD687D0D5CF0EEDCE6A@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM> <F4D6C50E-B510-488A-971B-3FC5EC9CF865@inkbridge.io>
In-Reply-To: <F4D6C50E-B510-488A-971B-3FC5EC9CF865@inkbridge.io>
Date: Mon, 15 Jun 2026 18:48:13 +0300
Message-ID: <004301dcfcde$628fe910$27afbb30$@smyslov.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHKPk6iz/kGskk2bgOL5zURLxcMewIB6IfHAioSIisBv8s+WLY13idA
Content-Language: ru
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - jet.bitexo.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - smyslov.net
X-Get-Message-Sender-Via: jet.bitexo.com: authenticated_id: valery@smyslov.net
X-Authenticated-Sender: jet.bitexo.com: valery@smyslov.net
X-Source:
X-Source-Args:
X-Source-Dir:
Message-ID-Hash: YLQBE5NLGEJJXAEECHQFX4BXMAUM64NU
X-Message-ID-Hash: YLQBE5NLGEJJXAEECHQFX4BXMAUM64NU
X-MailFrom: valery@smyslov.net
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-radext.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: 'Alan DeKok' <alan.dekok=40inkbridge.io@dmarc.ietf.org>, 'The IESG' <iesg@ietf.org>, radext-chairs@ietf.org, radext@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [radext] Re: [iesg] Re: Roman Danyliw's Block on charter-ietf-radext-07-03: (with BLOCK)
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/-VFyzhpsesyZABYy0PavM4hWRL4>
List-Archive: <https://mailarchive.ietf.org/arch/browse/radext>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Owner: <mailto:radext-owner@ietf.org>
List-Post: <mailto:radext@ietf.org>
List-Subscribe: <mailto:radext-join@ietf.org>
List-Unsubscribe: <mailto:radext-leave@ietf.org>
Hi, > > [Roman] The WG has deep understanding into the ecosystem, but I don't understand the hole in the IETF > process that this text is targeting, especially if this is intended to provide notice of code point registrations coming > from outside of the IETF. > > As background, one of the reasons for a charter update is a number of RADIUS drafts which originate in other > standards bodies. Without a charter update, the WG is unable to move forward with these topics. > > The result is that there are standards in other SDOs which are blocked on RADEXT charter updates. > > So if any text in the charter is controversial or unexpected, it's likely best to just remove it. I think that's the last > "block", so hopefully the charter can be updated before Vienna. I strongly agree with Alan. Currently, a number of documents intended to be adopted by RADEXT WG are blocked waiting for the end of the re-chartering process. The sooner it is resolved, the sooner the WG can start working on them. Roman, by no means the new charter was targeting to create a hole in the IETF process. The only intention was to allow drafts created outside the IETF to be adopted, and thus, passed the control over these drafts to the IETF, with all due IETF process. If you can propose better wording, it would be great (and we have already incorporated your proposed changes to the charter from your previous Block). Or we can just remove the text as Alan proposed if it is a stumbling block here. Regards, Valery. [...] > Alan DeKok.
- [radext] Roman Danyliw's Block on charter-ietf-ra… Roman Danyliw via Datatracker
- [radext] Re: Roman Danyliw's Block on charter-iet… Alan DeKok
- [radext] Re: [iesg] Re: Roman Danyliw's Block on … Valery Smyslov
- [radext] Re: [iesg] Re: Roman Danyliw's Block on … Roman Danyliw
- [radext] Re: [iesg] Re: Roman Danyliw's Block on … Alan DeKok