Subject: Re: WREC/CDNP/extproxy ... moving forward

From: Michael Condry <[email-masked]>
Date: Wed, 11 Oct 2000 09:56:31 -0700 (PDT)

> X-URI: http://www.cs.utk.edu/~moore/
> .....
> > Isn't there a "content services" model here where one point
> > is a provider that gets paid and the other is a consumer that
> > pays.
> 
> I'd rather leave assumptions about who pays whom out of the model.  
> The information might be freely available, or the provider could be 
> paying the consumer for reading his advertisements.  
> 
> Keith
> 
> p.s. actually I don't even like the provider vs. consumer dichotomy - 
> I'd rather think in terms of a bidirectional flow of information
> without assigning such roles.  after all, nearly every "consumer"
> is a provider of some information - forms that are filled in,
> click trails derived from cookies, etc. - and I don't inherently
> see why consumer-provided information should not be treated with
> the same respect as provider-provided information.  either party
> should have the right to control dissemenation of that 
> information; neither should have it viewed or modified by third
> parties without consent.
> 

We are not in disagreement over concepts, just language. Somewhere
a point requesting content/information, locating the content for
that requestor, and telling the content owner its being used have
be spelled out. I do not like the CDN peering language either but
it does spell some of this out!

---

From: [email-masked] (Gary Tomlinson)
Date: Thu, 12 Oct 2000 08:32:34 -0700

>From: Keith Moore [mailto:[email-masked]]
>Sent: Wednesday, October 11, 2000 8:10 AM

>from a protocol perspective, I don't think it matters whether the CDN
>is owned by the content-provider or whether it is owned by a separate
>party.  we still need to define the interaction between the two, so
>that there are standard components.  then it's a business decision
>on the content-provider's part as to whether to build the CDN itself
>(and whether to do so out of standard components or to roll its own),
>or pay someone else to do that function.

Yes, this in part is the essence of what we've proposed thus far in CDNP.
Peering is the interaction between CDNs (including Content Provider to CDN
relationship as well) and is not intended to constrain business model value
chains.  A slight clarification is in order with respect to building CDNs.
CDNP deals with interaction between CDNs but does not address the components
within CDNs, which is a seperate but interesting topic.  Think of CDNP as
being the exterior protocols used between administrative domains, much like
EGP was used for in IP peering.  

>(note that accounting/billing support are useful even when 
>the content and the CDN  are owned by the same party)

In CDNP, we imagine accounting being of great value in providing feedback to
the system in order to tune it, provision it, as well as determine its
effectiveness.

Gary

---

From: [email-masked] (Gary Tomlinson)
Date: Thu, 12 Oct 2000 09:07:39 -0700

>From: Ian Cooper [mailto:[email-masked]]
>Sent: Tuesday, October 10, 2000 12:49 PM

>WREC
>====
>* Proxy/surrogate discovery protocol for user agents
>   - initial intent is probably for "user agents" to mean browsers;
>   - should also consider some aspects of wider proxy/surrogate discovery 
>or registration that will probably be interesting to CDNP and extproxy 
>(e.g. proxies/surrogates being able to discover other proxies or
surrogates)
>   - obviously of interest to the folks doing the extensible proxy work
>
>* Cache coherence/invalidation protocol
>   - including delta encoding and preloading within the administrative 
>control of the data owner
>   - will probably touch on expiry semantics in passing
>   - will be of interest to the CDNP folks too
>

List looks reasonable.

CDNP BOF -> WG?
 
>====

>* Distribution of data from origin servers outside of the administrative 
>control of the data owner
>
>(I'd specifically exclude the scenario where the distribution occurs within

>a single administrative domain... do we really need to standardize that?)

I second the motion to limit scope to INTER-CDN interactions which implies 
inter administrative domains. The need to standardize within a CDN is IMHO
an
important step to take in the future (outside the scope of CDNP), as it
would allow 
CDNs to be built from  standard components.  Possibly the work undertaken in
WREC 
with repect to discovery and cache coherency would prove usefull in seeding
this.

>
>* Routing request to closest site (service) with the requested data
>   - should probably consider caching proxies in the model
>   - (obviously has some aspects of competitive advantage as was discussed 
>from the WREC KP draft in Pittsburgh)
>   - definition of the "closest" site (see WREC KP draft on known failings 
>of ICP in heterogeneous network)
>   - may overlap with, or provide us with, (or show us that it's 
>unnecessary to have) some replacement for ICP in the caching world

>
>
>Billing (and more)
>==================
>There seems to be a case for billing/accounting to be covered in all three 
>of WREC, CDNP and extensible proxies.  I believe that the extproxy folks 
>have commented that this may be appropriate work for another group (AAA?), 
>and it definitely seems that it's beyond any one of those being discussed
here.

Actually, there is precedence in the IETF for WGs to provide their own AAA
extensions.  mobileip <draft-hiller-cdma2000-aaa-02.txt> and ipv6
<draft-perkins-aaav6-00.txt> are examples.

>If we therefore open the scope to the wider issue of authentication and 
>authorization I guess we can add
>
>* Exchange format for log summaries (essentially some form of accounting 
>records; this is the problem identified in the WREC known problems
document)
>
>* User session management
>
>* Authentication models for multi-sited services/TLS interaction

Authentication is likely needed for surrogates in CDNP.  

Extensible Proxies BOF --> WG?
==================

Here's are strawman on activities within Extensible Proxies

* Trigger rule base syntax & semantics
* Excution run time model and security constraints
* Proxylet distribution protocol
* ICAP remote call out protocol standardization

It makes sense to me to have 3 WGs attacking this space in parallel focused
charters that
can be complete signifiant deliverables in 12-18 months and then address the
issues of 
rechartering to take on deferred work.

Gary