Re: [radext] AD review: draft-ietf-radext-radius-extensions

"David B. Nelson" <d.b.nelson@comcast.net> Fri, 04 January 2013 14:27 UTC

Return-Path: <d.b.nelson@comcast.net>
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 8626E21F88C8 for <radext@ietfa.amsl.com>; Fri, 4 Jan 2013 06:27:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.437
X-Spam-Level:
X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ERqK4SPgNi4 for <radext@ietfa.amsl.com>; Fri, 4 Jan 2013 06:27:44 -0800 (PST)
Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id E957B21F88B9 for <radext@ietf.org>; Fri, 4 Jan 2013 06:27:43 -0800 (PST)
Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA11.westchester.pa.mail.comcast.net with comcast id jp3R1k00316LCl05BqTj0s; Fri, 04 Jan 2013 14:27:43 +0000
Received: from newton ([24.61.179.177]) by omta06.westchester.pa.mail.comcast.net with comcast id jqTc1k00p3q2Njc3SqTiCu; Fri, 04 Jan 2013 14:27:43 +0000
From: "David B. Nelson" <d.b.nelson@comcast.net>
To: 'Benoit Claise' <bclaise@cisco.com>, 'Alan DeKok' <aland@deployingradius.com>
References: <50C1CA9F.40100@cisco.com> <50C210F8.5060107@cisco.com><50DB4F89.5090909@deployingradius.com> <50E6B41D.5020201@cisco.com> <50E6E32D.7000001@cisco.com>
Date: Fri, 04 Jan 2013 09:27:39 -0500
Message-ID: <1AD287816CAE4B46A588B1D8AA690CBC@newton>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <50E6E32D.7000001@cisco.com>
Thread-Index: Ac3qhZ2lg6inl0WnSeecYzqiwseetgAARmkg
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357309663; bh=SIpKiNZ852Zus2fmhCq/Qx1Jc9owhGMiotczDUPQ2yg=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=SKx1tJgbCSZ1/RTm6+QU3aX5C2LwG9O6s3jb3wCgVB229T6x7w7tiOYHEB3WIdgFw 8rp+bePEoN0/byA3Q8NETuN9tWzm/WhrZFIVE+Ph+qnjJoaYMh2YK58SuGl24pSjJB 69xU9sV4CIBLutHnFc/OKeDaZge1jKK3s/g5nmYJkN+MH4jmHQXM6Na8qTTHKSbFFk EBpqKxTUGZFFMsPm9lIUtkDmVuQA+XT92wiMAkOyi+TQ1vTVBQIddBuBI+HKwfroqj MF0xwzwVM5hklV9z66DS1WVsb3mN2phkNinmYQkSRi5nkA+cPaorYY4Azsn+D7LcTX R6G/WU8trdwfA==
Cc: radext@ietf.org, draft-ietf-radext-radius-extensions@tools.ietf.org
Subject: Re: [radext] AD review: draft-ietf-radext-radius-extensions
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Fri, 04 Jan 2013 14:27:44 -0000

Benoit Claise writes...

> I'm wondering why RFC 2866 and RFC 5176 were informational
> in the first place. Maybe someone with a long history in
> the WG could shed some light?

I've been involved since the second RADIUS BOF (for the RADIUS WG), so I
remember some of this history.

RADIUS Accounting was not considered as robust as RADIUS, for a number of
reasons.  I think one reasons was the lack of positive application layer
acknowledgement that the data had been received and logged.  Anyway, the
IESG politics at the time dictated that Standards Track status would require
enhancements to RADIUS Accounting beyond what the RADIUS user community
would actively support.

I think there were similar "maturity" arguments around Dynamic RADIUS.

With the passage of time, and additional field experience, perhaps we would
look at it differently today.

Regards,

Dave