Re: [AAA-DOCTORS] [Fwd: [MBONED] WGLC for<draft-ietf-mboned-multiaaa-framework-07.txt>]

Alan DeKok <aland@deployingradius.com> Mon, 15 September 2008 09:31 UTC

Return-Path: <aaa-doctors-bounces@ietf.org>
X-Original-To: aaa-doctors-archive@optimus.ietf.org
Delivered-To: ietfarch-aaa-doctors-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CB063A6859; Mon, 15 Sep 2008 02:31:42 -0700 (PDT)
X-Original-To: aaa-doctors@core3.amsl.com
Delivered-To: aaa-doctors@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1182628C0F2 for <aaa-doctors@core3.amsl.com>; Sun, 14 Sep 2008 22:56:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.222
X-Spam-Level:
X-Spam-Status: No, score=-1.222 tagged_above=-999 required=5 tests=[AWL=1.377, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bsyIhIimQ1Y for <aaa-doctors@core3.amsl.com>; Sun, 14 Sep 2008 22:56:28 -0700 (PDT)
Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id E2C8B3A6A1A for <aaa-doctors@ietf.org>; Sun, 14 Sep 2008 22:56:27 -0700 (PDT)
Received: from [192.168.0.14] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 972151234221; Mon, 15 Sep 2008 07:56:36 +0200 (CEST)
Message-ID: <48CDF8CA.2000809@deployingradius.com>
Date: Mon, 15 Sep 2008 07:55:22 +0200
From: Alan DeKok <aland@deployingradius.com>
User-Agent: Thunderbird 2.0.0.16 (X11/20080724)
MIME-Version: 1.0
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
References: <48C79F49.1050901@gmx.net> <EDC652A26FB23C4EB6384A4584434A04F6D0E2@307622ANEX5.global.avaya.com> <BLU137-DAV1D5880016137EB5396E2E93570@phx.gbl> <48CD6250.4040900@gmx.net>
In-Reply-To: <48CD6250.4040900@gmx.net>
X-Enigmail-Version: 0.95.0
X-Mailman-Approved-At: Mon, 15 Sep 2008 02:31:41 -0700
Cc: aaa-doctors@ietf.org
Subject: Re: [AAA-DOCTORS] [Fwd: [MBONED] WGLC for<draft-ietf-mboned-multiaaa-framework-07.txt>]
X-BeenThere: aaa-doctors@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: AAA Doctors E-mail List <aaa-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/aaa-doctors>
List-Post: <mailto:aaa-doctors@ietf.org>
List-Help: <mailto:aaa-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: aaa-doctors-bounces@ietf.org
Errors-To: aaa-doctors-bounces@ietf.org

Hannes Tschofenig wrote:
> could you check on behalf of RADEXT whether the Alan's review comments 
> have been incorporated (or ask Alan todo so)?
> I will do the same for the reviews we did in DIME.

  Many of my review comments have been incorporated.  The document is
appreciably better.

  However, many of the changes are also problematic.  As I said in my
earlier review, the document still combines concepts in an inconsistent
and confusing way:

   The level of account report messaging between the NSP and
   CP may be either configured statically or can be
   dynamically requested by the CP in its response to the
   Access-Request relayed by the NSP to the CP.  The
   determination of the actual level of report messaging is
   configured by the NSP at the NAS.

  Paraphrased: "stuff can be sent putting things in an Access-Request".

  I don't see how this can be helpful.  That being said, this paragraph
is still clearer than the previous versions.

  The document needs to figure out it's purpose.  It claims to be a
model, but it also defines requirements.

  As it stands, I don't think the document accurately describes
*existing* AAA systems.  I don't think the system described can be
implemented using existing AAA systems.  e.g. it describes user Id's
being assigned at multiple points in the network.  What does that mean?
 Is it a provisioning system?  AAA systems don't normally assign
user-Id's (except for opaque id's such as Class or CUI)

  It's references to accounting still talk about "logging" accounting
data.  Is that a reference to a specific implementation method, a
requirement, or ... ?

  4.1 says:

   A CP may delegate AAA responsibility to a NSP. 'AAA proxy
   in NSP' is described in 4.7 for this case.

  How is delegation performed in a AAA framework?  Diameter supports
redirection, but I don't recall delegation being part of it.  "Hi,
please authenticate all of my users, and no, I don't want to see billing
information."  Weird.

  Alan DeKok,
_______________________________________________
AAA-DOCTORS mailing list
AAA-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/aaa-doctors