IETF Logo Mail Archive

Re: [radext] Extended IDs

Alan DeKok <aland@deployingradius.com> Sun, 10 December 2017 18:23 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 2A7D8126DD9 for <radext@ietfa.amsl.com>; Sun, 10 Dec 2017 10:23:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vuDVX-ZYfvqD for <radext@ietfa.amsl.com>; Sun, 10 Dec 2017 10:22:58 -0800 (PST)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 24B0B126BFD for <radext@ietf.org>; Sun, 10 Dec 2017 10:22:58 -0800 (PST)
Received: from [192.168.2.25] (198-84-205-59.cpe.teksavvy.com [198.84.205.59]) by mail.networkradius.com (Postfix) with ESMTPSA id BAF1E16B; Sun, 10 Dec 2017 18:22:56 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <9B25ADF9-CBAF-4A1D-937E-13532C2D7B06@gmail.com>
Date: Sun, 10 Dec 2017 13:22:54 -0500
Cc: Winter Stefan <stefan.winter@restena.lu>, radext@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <447FB656-5BF9-4A58-A801-1BE1943A854A@deployingradius.com>
References: <fef698a5-9802-c9be-04d7-1e869651c988@restena.lu> <dfd0ff02-c9e8-7253-4fb4-1e6def3e93b2@restena.lu> <A4B9DD54-859E-4EDC-9596-6D2274E9F367@deployingradius.com> <9B25ADF9-CBAF-4A1D-937E-13532C2D7B06@gmail.com>
To: Bernard Aboba <bernard.aboba@gmail.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/SVyYqrZTMB2eNHjdRIagUJCKyCk>
Subject: Re: [radext] Extended IDs
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.22
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, 10 Dec 2017 18:23:00 -0000

On Dec 10, 2017, at 11:31 AM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
> 
> I strongly prefer draft-dekok.
> 
> draft-chen takes approaches outside the mainstream of RADIUS implementations and previous standards, and is very under-specified. 
> As a result its implementation will be much more difficult than is necessary. 
> 
> It extends the Status-Server message for the purpose of capability discovery which is inappropriate and utilizes an adhoc complex data type which violates RFC 6929. 

  My draft has that too.  Though looking at it some more, it's not strictly necessary.

  I would prefer explicit negotiation, even if overloading Status-Server is ugly.

  Alan DeKok.

v2.23.0 | Report a Bug | By Email