Re: [radext] draft-cullen-radextra-status-realm-00

Alan DeKok <aland@deployingradius.com> Tue, 08 August 2023 12:52 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 86B5CC151717; Tue, 8 Aug 2023 05:52:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 LWfPHQfK5r1L; Tue, 8 Aug 2023 05:52:35 -0700 (PDT)
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 7DAEEC151711; Tue, 8 Aug 2023 05:52:32 -0700 (PDT)
Received: from smtpclient.apple (135-23-95-173.cpe.pppoe.ca [135.23.95.173]) by mail.networkradius.com (Postfix) with ESMTPSA id 6DF77708; Tue, 8 Aug 2023 12:52:30 +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: <PH0PR11MB5928CB4C125CD3E8891073B6D20CA@PH0PR11MB5928.namprd11.prod.outlook.com>
Date: Tue, 08 Aug 2023 08:52:28 -0400
Cc: "draft-cullen-radextra-status-realm@ietf.org" <draft-cullen-radextra-status-realm@ietf.org>, "radext@ietf.org" <radext@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B0E4CC12-60EC-4443-AB8E-61FE1CCC493C@deployingradius.com>
References: <BB2CA78D-4C7B-4A5D-A1D5-F09993636373@gmail.com> <PH0PR11MB5928CB4C125CD3E8891073B6D20CA@PH0PR11MB5928.namprd11.prod.outlook.com>
To: "Mark Grayson (mgrayson)" <mgrayson=40cisco.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/uyRGnR53z0AihGN5BGh7K0gdLu0>
Subject: Re: [radext] draft-cullen-radextra-status-realm-00
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: Tue, 08 Aug 2023 12:52:39 -0000

On Aug 7, 2023, at 4:00 AM, Mark Grayson (mgrayson) <mgrayson=40cisco.com@dmarc.ietf.org> wrote:
> 
> Is status-realm a better approach compared with status-server for signalling end-to-end capabilities for reverse CoA support across a particular multi-hop route?

  I'm unsure.  I think it will work, but it's not clear if it's the best approach.

  The initial proposal for reverse CoA is to say "Do it when administratively configured".  That's at least not wrong, and workable.

  There is the temptation to put some signalling into Access-Request packets, but that would have to go into *every* packet, which is bad.

  Status-Realm seems better, but it's really intended for administrative debugging, and not for anything past that.

  What would be best is some kind of RADIUS routing protocol which let you configure routes, realms, capabilities, etc.  I've been looking into that for a long time, and there's been insufficient interest for people to demand it.  Maybe now is the time?

  Alan DeKok.