Subject: [Dime] [Fwd: Request for review of "AAA Framework for Multicasting"]

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 19 Aug 2007 22:21:22 +0200

During the IETF#69 meeting I have also asked for reviewers. Two persons 
offered help:
* Jouni Korhonen
* Tina Tsou

Their review is still pending!

-------- Original Message --------
Subject: 	Request for review of "AAA Framework for Multicasting"
Date: 	Sat, 18 Aug 2007 14:49:00 -0700
From: 	Bernard Aboba <[email-masked]>
To: 	[email-masked]

A request for review has been received relating to the document "AAA 
Framework for Multicasting" which is under development within the MBONED WG. 
 The document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-ietf-mboned-multiaaa-framework-04.txt

The Request for Review will last until September 5, 2007.  Please post your 
comments on this document to the RADEXT WG mailing list, CC:'ing the 
document authors.

Information on the review request was previously posted to the RADEXT WG 
mailing list:
http://ops.ietf.org/lists/radiusext/2007/msg00528.html

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: Tina TSOU <[email-masked]>
Date: Mon, 20 Aug 2007 16:49:28 +0800

Hi Hannes and all,
Sorry for late...^o*
Will provide it during this week.

B. R.
Tina
----------------------------------------------
All the other days should inherit from Monday.

----------------------------------------------

----- Original Message ----- 
From: "Hannes Tschofenig" <[email-masked]>
To: <[email-masked]>
Sent: Monday, August 20, 2007 4:21 AM
Subject: [Dime] [Fwd: Request for review of "AAA Framework for 
Multicasting"]

> Framework for Multicasting" which is under development within the MBONED 
> WG. The document is available for inspection here:
> The Request for Review will last until September 5, 2007.  Please post 
> your comments on this document to the RADEXT WG mailing list, CC:'ing the 
> document authors.
>

---

From: <[email-masked]>
Date: Wed, 22 Aug 2007 16:58:04 +0200

Hi All,

Here are my initial comments on this draft.

----

Firstly idnits gives rather many errors and warning. The authors
should check the draft against the idnits.

Some editorial comments:

Section 1.1

 o "...communication schemes of any kind, such as 1-to-n (case of 
   TV broadcasting services for example) or n-to-p (case of..."

   rather use  one-to-many and many-to-many

 o "...high-quality multicast transport using a Resource and 
   Admission Control System (RACS) with multicast..."

   I assume this refers to TiSPAN defined RACS functional entity.
   I would like to see a reference here.

 o "...presented in draft-ietf-mboned-maccnt-req-04.txt,..."

   Rather use the reference to [1]

 o "...MACCNT-REQ-draft describes the requirements in CDN services 
   using IP multicast[1]. The requirements are derived from:..."
 o "...Detailed requirements are presented in MACCNT-REQ-draft...."

   Again the reference..

Section 2.1

 o "   Note: The definition of a receiver (device) and a user 
   (human) should not be confused. "

   This note does not really fit into definitions as it is. Now it
   looks like yet another definition, which is not the intent I
   assume.
 
Section 2.2

 o AAA, mAAA, NSP-AAA, CP-AAA, ID, API, IF, NAS, QoS
   and RACS are missing

Section 3

 o "...are divided between separate entities.  The MACCNT-REQ-
   draft provides more detail of the multiple versus single..."
   
   Reference.

 o "...entity CDS network models. "

   Expand CDS on the first use

 o "As such it should not be assumed that the entity 
   responsible for the multicasting structure and the entity 
   responsible for content serving are the same.  Indeed 
   because the infrastructure for multicasting is expensive 
   and many content holders are not likely to be competent at 
   building and maintaining complicated infrastructures 
   necessary for multicasting, many content holders would 
   prefer to purchase transport and management services from a 
   network service provider and thus share the infrastructure 
   costs with other content holders."

   Consider revising.. to something like.. whatever..

   "It should not be assumed that the entity  responsible for
    the multicasting infrastructure is not the same as the entity 
    responsible for serving the content. Content holders are not
    likely to build and maintain their own multicast network
    infrastructure that is not part of their expertise area. Rather
    they are willing to purchase transport and management services
    from dedicated network service providers."

 o "...The use model of a single NSP providing multicasting 
   services to multiple CPs the following general requirements 
   from MACCNT-REQ-draft apply:..."

   References..

   Expand CP on the first usage.

   Reword to something like

   "In the usage model of where a single NSP provides multicast
    services to multiple Content Providers (CP), the following
    general requirements from [1] apply:.."

 o "When the NSP and CP are the same single entity the general 
   requirements are as follows."

   revise to 

   "When the NSP and the CP are the same entity then the general 
    requirements are as follows:"
    
Section 4.1

 o "A general high-level framework can be represented as 
   follows."  
  
   revise to.. something like

   "A general high-level framework is presented in the 
    Figure 1."  

 o For relationships use similar style as in previous sections.
   e.g. 1:1 -> one-to-one or 1-to-1 etc..

 o Expand STB on the first use.

 o What is STB? It is mentioned only once in this document in this
   section..

 o "The CP is responsible for Authentication and Authorization.."

   use "authentication and authorization"  
 
 o "...(authentication by proxy), and the NSP's relevant AAA.."

   Authentication via or through? 

 o NSP-AAA and CP-AAA?

 o "...without querying the CP-AAA.  When the NSP cannot or 
   decides not to multicast to users, the NSP may notify the..."

   I don't get what this is supposed to mean.

Section 4.2

 o Heading -> "Multiple User Identities"

 o Expand ID on the first use.

Section 4.2

 o References to [1].. and a consistent way of doing those would be
nice.

 o Reference to RFC3810 & RFC3376

 o Expand API on the first use

Section 4.5

 o References

Section 4.7

 o "reestablish" to "re-establish"?

Section 5

 o "Section 3.1 introduces the high-level AAA framework for..."

    introduced

 o "...access to the User.  First a user that requests content..."

   revise to.. something like

   "...access to a user. First the user.."
  
 o "...to the appropriate CP for Authentication and Authorization..."

   authorization and authorization

 o Notation of relations.. 1:1 etc to similar as previously used

Section 5.2

 o References..

 o Should these "well managed", "fully enabled AAA" etc be defined
   in section 2.1

 o "Section 3.1 intriduces" -> introduced

 o "of a AAA" -> "of an AAA"

 o In the figure 2 the caption is partial.. or parts of it is
   before the figure.. should be fixed

 o Use consistent way of expanding abbreviations.. both types e.g.
   Content Provider (CP) and CP (Content Provider) are used

 o Figure 3 has similar caption issues as figure 2

I got a bit stuck to general presentation of the draft. It needs
more work. For general readability of the draft I would suggest
paying attention to overall formatting. This may sound naive but
IMHO I would suggest using some tool that generates automatically
a proper layout, such as xml2rfc. 

And then some remotely technical comments, if any.

 o It is rather unclear to me how the actual AAA transactions are
   supposed to work (refer to fig. 1). CP auth/authz the user
   and the CP also auth/authz the NSP?  Are these separate?
   What about user to NSP auth/authz? (this is then later
   described better in section 5.1 but not where the fig.1 
   is described)

 o "The actual mapping rules for NSPs and CPs to map user IDs 
   with the IDs in other provider domains is a matter for the 
   providers.  A solution should provide an API between the 
   providers to flexibly support various mapping methods."

   The inter-working could be explained a bit more carefully.
   An example would be nice. Otherwise this is rather unambiguous.

 o Standardization of logs? Do you mean coming up with a file
   presentation format for user session tracking? Or rather
   just defining that billing record format? Could any of the
   existing ones be re-used or expanded?

 o "...This framework specifies an accounting API provided by the 
   NSP and accessed by the CP to allow for sharing user-..."

   I don't really find the API specification in this framework
   draft
  
 o Does API here actually mean AAA interface or something else?
   The use of API-term is somewhat confusing..

 o "content request" is AAA request?

 o It would be nice to have a separate sections (or something)
   going through each AAA interface (IFa, IFb, etc) 

Cheers,
	Jouni

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: Sunday, August 19, 2007 11:21 PM
> To: [email-masked]
> Subject: [Dime] [Fwd: Request for review of "AAA Framework 
> for Multicasting"]
> 
> 
> During the IETF#69 meeting I have also asked for reviewers. 
> Two persons offered help:
> * Jouni Korhonen
> * Tina Tsou
> 
> A request for review has been received relating to the 
> document "AAA Framework for Multicasting" which is under 
> development within the MBONED WG. 
> The Request for Review will last until September 5, 2007.  
> Please post your comments on this document to the RADEXT WG 
> mailing list, CC:'ing the document authors.
> 
> Information on the review request was previously posted to 
> the RADEXT WG mailing list:

---

From: Tina TSOU <[email-masked]>
Date: Thu, 23 Aug 2007 12:49:07 +0800

Hi all,
Here are my preliminary comments on this draft as promised.
1. ".. activated to make sure a given requesting customer is (1)
   what he claims to be (identification purposes)," in section 2.1
is authentication, not authorization

2. It is not clear why RACS is not needed when NSP and CP are the same 
single entity

3. Can mAAA push unsolicited access control information to NAS?

4. "Refer to section 3.3" in section 7. There is no section 3.3

B. R.
Tina
+86-755-28972912 (Office)    +86-13922884380 (Mobile)
Messengers:
MSN: [email-masked]   Yahoo: tina_tsou    Skype: tinaTSOU    Jabber: 
[email-masked]    Google talk: [email-masked]

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Wednesday, August 22, 2007 10:58 PM
Subject: RE: [Dime] [Fwd: Request for review of "AAA Framework for 
Multicasting"]

Hi All,

----

Some editorial comments:

Section 1.1

   Again the reference..

Section 2.1

Section 2.2

Section 3

   Reference.

   References..

   Reword to something like

   revise to

Section 4.1

 o NSP-AAA and CP-AAA?

Section 4.2

Section 4.2

Section 4.5

 o References

Section 4.7

Section 5

    introduced

Section 5.2

 o References..

Cheers,
Jouni