Response to RADEXT WG review of <draft-ietf-mboned-multiaaa-framework-07.txt> (fwd)

"Bernard Aboba" <Bernard_Aboba@hotmail.com> Mon, 15 September 2008 17:21 UTC

Message-ID: <BLU137-DAV101C869FA6F2E5412C5D7993520@phx.gbl>
From: Bernard Aboba <Bernard_Aboba@hotmail.com>
To: 'radext mailing list' <radiusext@ops.ietf.org>
Subject: Response to RADEXT WG review of <draft-ietf-mboned-multiaaa-framework-07.txt> (fwd)
Date: Mon, 15 Sep 2008 10:17:36 -0700
Message-ID: <000f01c91756$f2be16a0$d83a43e0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AckW99E9fTJ4e7fZSWOo7lS6R4K87wAXwujQ
Content-Language: en-us
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk

-----Original Message-----
From: Alan DeKok [mailto:aland@deployingradius.com] 
Sent: Sunday, September 14, 2008 10:55 PM
To: Hannes Tschofenig
Cc: Bernard Aboba; aaa-doctors@ietf.org
Subject: Re: [AAA-DOCTORS] [Fwd: [MBONED] WGLC
for<draft-ietf-mboned-multiaaa-framework-07.txt>]

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,

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Response to RADEXT WG review of <draft-ietf-mbone… Bernard Aboba