RE: New draft: draft-day-cdnp-scenarios-03.txt

[DonE@activate.net]

> -----Original Message-----
> From: Phil Rzewski [mailto:philr@inktomi.com]
> Sent: Monday, March 05, 2001 3:34 PM
> To: DonE@activate.net
> Cc: cdn@ops.ietf.org
> Subject: RE: New draft: draft-day-cdnp-scenarios-03.txt
> 
> 
> At 04:33 PM 3/3/01 -0800, DonE@activate.net wrote:
> >Phil,
> >
> >Section 1, Page 3, "3.  CLIENTS Have Value"
> >
> >No don't remove this, but explain how CDNs relate to the advertising
> >business model.  Those who want to advertise are willing to 
> pay publishers
> >to create ad content (and are willing to pay for programming 
> content and
> >distribution) such that CLIENTS see the ad content.
> 
> I can see a home for explicit mention of the ad-revenue 
> business model. I 
> think in the current draft, the explanation for "Clients Have 
> Value" is 
> kinda rolled up unintentionally with "Distribution Has Value". Notice 
> Section 4.1.3:
> 
> "An example of this case is where a service provider has an 
> aggregated 
> CLIENT population which is of sufficient interest to one or more 
> PUBLISHERs. In this case the PUBLISHERs are willing to pay to 
> access the 
> CLIENTs of the service provider and revenue flows from the 
> PUBLISHER to the 
> service provider."
> 
> This basically sounds like an explanation of the ad-revenue 
> model (though 
> it could certainly be clearer): The reason WHY distribution 
> has value is 
> because the ads give value to just getting it distributed 
> "out there" as 
> much as possible.
> 
> Lemme take a stab at separating it off. Basically, saying 
> "Distribution Has 
> Value" is a lot like saying "Distribution is a service you 
> need to pay for 
> no matter what". It's kind of like bandwidth in that sense: 
> It doesn't 
> matter whether I'm doing e-commerce or running a university, 
> I need to pay 
> for my dial tone. So whether I'm selling paid-use movies 
> ("Content Has 
> Value") or ad-revenue web pages ("Clients Have Value"), I'm 
> going to need 
> to pay SOMEONE for getting it in front of those eyeballs. It just so 
> happens that, in the paid-use model, the publisher hopes to 
> get back all 
> they'd be paying for distribution (& then some) in the form 
> of content use 
> fees, potentially from the same Content Networks they paid 
> for distribution 
> in the first place. This may result in business models where 
> the Access 
> Content Networks actually offer "free distribution" for 
> paid-use content, 
> as long as they get a cut of the use fees. This is probably 
> out of scope 
> for us, but I like to kick it around.

Yes, potential CNs have offered us (a content distributor) "free
distribution" for a cut in our ad revenues.
I like your rationale for "Clients Have Value".  But Distribution adds
value also by increasing the quality of the CLIENT experience (content
can be delivered without a CN, but content delivered using a CN has move
value). 

> >In this case DISTRIBUTION and REQUEST-ROUTING are "send only", but
> >ACCOUNTING can be in either direction (and possibly "receive only").
> 
> I see I was not clear enough in that section. "Send-only" may be too 
> abstract of a term, or I may just need to define it better. 
> Any type of 
> peering obviously requires two-way communication, it's just a 
> question of 
> what advertisements or payloads flow in each direction. So for 
> distribution, the "payload" consists of actual content 
> signals or content 
> updates, and that's what's "send-only" in the PCN case. By 
> the same logic, 
> I'd say the "payload" of accounting peering is actual CDRs in 
> log files, 
> and hence "receive-only" in the PCN case as you say. As for 
> Request-Routing, as the requirements draft currently states, 
> we're really 
> looking at advertisements flowing in both directions (area, 
> content), and a 
> PCN would only be doing "content advertisements".
> 
> I'll plan to make this stuff clearer, assuming people 
> continue to see some 
> value in enumerating this kinda stuff. :)

Yes, it has value (comments on "Models and Scenarios" to follow).

Don Estberg

> --
> Phil Rzewski - Senior Architect - Inktomi Corporation
> 650-653-2487 (office) - 650-303-3790 (cell) - 650-653-1848 (fax)
> 
>