RE: CDN-I (Acct-CPG) Requirements

[DonE@activate.net]

Jay,

I think the 01 (2/26/01) version is much improved over the 00 (1/26/01)
version.  I realize that my comments are likely too late for the draft
deadline for the 50th IETF.

Don

AAA Rqmts Comments

Section 2, Page 5

It seems strange to me to use the term "Percentile" in this way, and the
term "Usage-Based" would be more descriptive to me.  But I may be just
unaware that this is common terminology.

Section 3, Figure 1, Page 7

The model can be simplified, as done in the Distribution Requirements
(draft-amini-cdi-distribution-reqs-00.txt), by assuming the Origin is a
special case of a CDN, and I don't think any generality is lost.  Then you
don't need the term Injection, since this becomes a Distribution (likewise
Section 5.3.2 becomes the same as Section 5.3.3).

Also in this Figure, the case where the Client makes the Content Request to
the Origin should be allowed for.  But this case is taken care of by making
the Origin a special case of a CDN.

Section 4.1, Page 9

The assumption about firewalls can be made less strict by saying that no
special provision will be made for firewalls (allowing for the case that it
could work with some firewalls, with or without some adjustment to the
firewall).

Section 5.3.2, Page 13

As mention above with respect to Figure 1, by considering the Origin to be a
CDN, then ContentInjection becomes a type of ContentDistribution.  The
naming convention used for the CDNSrcID could distinguish whether the CDN
provides content, delivers content or does both.  

Section 5.3.3, Page 13

Content_ID should be ContentURI.

Under TimeStamp, instead of "(start/end)" add a note that this is at the
point in time specified by the State attribute.

Another worthwhile attribute would be the method of distribution (push,
pull).

Section 5.3.4, Page 14

Information related to the Requester will be of interest to people and in
some cases be allowed.  One way to do this would be to have a compound
RequesterID attribute containing such things as IP address, what OS,
browser, player, etc.

To analyze the performance of Request Routing, one would want to know
metrics used, etc.

Section 5.3.5, Page 14

I would think the work would be signaling rather than retrieval (which is
signaling followed by distribution).

Transactions for both ContentRequest and ContentSignaling should be optional
rather than required, since in some cases the overhead of gathering this
information may not warrant its value.  But I guess all types of
transactions should be optional.

Section 5.3.6, Page 15

Instead of DelivererID, shouldn't this be SurragateID?

Instead of ReceiverID, shouldn't this be RequesterID?

To do detailed analysis, one would want to link content delivered to the
request for that content; adding a RequestID attribute to both the
ContentRequest and the ContentServiceDelivery CDRs could do this.

What both content providers and distributors need is more detailed
information about the content delivered.  In particular, in the case of
streaming media, one would want:
	Content Bandwidth
	Content Format
	Etc
However, the best way to handle this type of information is to specify that
it be part of the ContentURI.