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

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 10 Sep 2008 13:19:53 +0300

Work todo for us!

Anyone who volunteers to review the document?
If not, then I have to assign someone.

Ciao
Hannes

-------- Original Message --------
Subject: 	[MBONED] WGLC for
Date: 	Wed, 10 Sep 2008 16:56:39 +0900
From: 	Hiroshi Ohta <[email-masked]>
Organisation: 	NTT
To: 	[email-masked]

Working group,

This note starts the WG Last Call for comments on
<draft-ietf-mboned-multiaaa-framework-07.txt>, "AAA and Admission
Control Framework for Multicasting".

It can be found at
	
http://www.ietf.org/internet-drafts/draft-ietf-mboned-multiaaa-framework-07.txt

The document's proposed status is Informational.

Please review the document carefully, and send your feedback to the
list.  Please also indicate whether or not you believe that this
document is ready to go to the IESG.

This Last Call will end on Oct. 1, 2008 at 1400 EDT (UTC/GMT-4).

Thank you.
Hiroshi and Marshall

_______________________________________________
MBONED mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mboned

_______________________________________________
AAA-DOCTORS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/aaa-doctors

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 10 Sep 2008 14:02:19 +0200

Hannes,

Was there a request from MBONED or is there another reason to review
this document at WGLC? 

I am asking the question because as discussed in Dublin our typical
point of intersection for reviews is at IETF LC. 

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
> Sent: Wednesday, September 10, 2008 1:20 PM
> To: [email-masked] 
> Subject: [AAA-DOCTORS] [Fwd: [MBONED] WGLC 
> for<draft-ietf-mboned-multiaaa-framework-07.txt>]
> 
> Work todo for us!
> 
> <draft-ietf-mboned-multiaaa-framework-07.txt>, "AAA and 
> Admission Control Framework for Multicasting".
> 
> It can be found at
> 	

Thank you.
Hiroshi and Marshall

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 10 Sep 2008 06:01:48 -0700

Alan DeKok reviewed the document for RADEXT in August 2007. 

Here is a summary of the initial reviews:
http://ops.ietf.org/lists/radiusext/2008/msg00153.html

Here is the response to Alan's review:
http://www.ietf.org/mail-archive/web/mboned/current/msg00375.html

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Romascanu, Dan (Dan)
Sent: Wednesday, September 10, 2008 5:02 AM
To: Hannes Tschofenig; [email-masked]
Subject: Re: [AAA-DOCTORS] [Fwd: [MBONED] WGLC
for<draft-ietf-mboned-multiaaa-framework-07.txt>]

Hannes,

Dan

Thank you.
Hiroshi and Marshall

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 10 Sep 2008 20:05:16 +0300

Hi Dan,

there was no request from the MBONED group this time but we received a 
request some time ago from Scott Bradner (Technical Advisor of the 
MBONED group) regarding the review of their AAA documents. Both RADEXT 
and DIME members responded to the request. The reviewers got the 
impression that these document need a lot more work.

As such, it would be a good time to check how our comments got 
reflected. Other review comments would not hurt either, I believe.
I just want to avoid providing them substantial comments at a very late 
stage since this tends to be very frustrating for the draft authors...

Ciao
Hannes

Romascanu, Dan (Dan) wrote:
>> http://www.ietf.org/internet-drafts/draft-ietf-mboned-multiaaa
>>     
> -framework-07.txt
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 10 Sep 2008 19:09:16 +0200

This is fine. Please go ahead. 

Dan

> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: Wednesday, September 10, 2008 8:05 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]
> there was no request from the MBONED group this time but we 
> received a request some time ago from Scott Bradner 
> (Technical Advisor of the MBONED group) regarding the review 
> of their AAA documents. Both RADEXT and DIME members 
> responded to the request. The reviewers got the impression 
> that these document need a lot more work.
> 
> As such, it would be a good time to check how our comments 
> got reflected. Other review comments would not hurt either, I believe.
> I just want to avoid providing them substantial comments at a 
> very late stage since this tends to be very frustrating for 
> the draft authors...
> 
> Ciao
> Hannes
> 
> 
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 14 Sep 2008 22:13:20 +0300

Bernard,

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.

Ciao
Hannes

---

From: Alan DeKok <[email-masked]>
Date: Mon, 15 Sep 2008 07:55:22 +0200

> 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,