Re: "Group last call": draft-day-cdnp-model-08

[Ian Cooper <ian@the-coopers.org>]

Introduction, 3rd paragraph: space after reference to RFC3040.  Also, you 
mention the terms "reverse caching proxy" and "server accelerator" in 
relation to RFC3040 - the intent in that document was to depreciate the use 
of those terms in favor of "surrogate"... the language used in this 
introduction suggests that these terms are now better defined... doesn't 
seem to fit to me.

Introduction, final paragraph: for a draft I think it's really useful to 
have pointers to all the other documents... are you going to get into 
publication hell with rfc-editor if they stay?

Section 2, 2nd paragraph: "Whereas network infrastructures previously have 
traditionally processed"... are "previously" and "traditionally" both 
required in that sentence?  (I'd stick with "traditionally".)

Section 2.2: While you note that RFC3040 gives information on cases where 
techniques are used to distribute requests from clients to multiple 
proxies, I wonder if it might be more useful to change the earlier wording 
to suggest that it is possible to have a user agent configured to use more 
than one proxy. "When this configuration is properly done, the user's 
entire browsing session goes through a specific caching proxy" - this 
implies (to me, in part at least) it is desirable for all requests to pass 
through that one caching proxy, which I don't believe is the case.  The 
diagram shows some trivial request routing for foo.com and bar.com - there 
are ample cases where this routing is done in the user agents, and 
capturing that point seems useful to me.

Section 2.4: "Caching proxies can improve performance problems due to 
network congestion (since they are situated near the clients) but they 
cache objects based on client demand -- so they may not help the 
distribution load of a given origin server."  I'm not really sure what 
you're trying to say here.  Do you mean ".. help the distributed load..." ? 
(e.g. It's the first hit/cache miss on all those caching proxies where 
they're of no help to the origin server?)

Section 2.4, typo: "To address these limitations. another".  Replace "." 
with ","

Section 2.4: Any chance you can possibly change the icky reference to 
"(forward)" caching proxies.  Perhaps, "A CDN combines the cache-management 
approach of reverse caching proxies[sic] with the placement of caching 
proxies in networks close to the requesting end users."

Section 2.4: Oops: "Compared to using servers and caches in a single data 
center," didn't cache that instance of "caches"

Section 3: I'm guessing the response is "it's a well known or obvious way 
of doing things" but I wonder if there might be some use in actually 
stating that "phrases in uppercase refer to other defined terms".

I agree with Phil's concerns on the definition of CONTENT NETWORK ELEMENT

Section 3: "DELIVERY" ... I'm wondering if the word "presenting" infers 
rendering too strongly.  (You obviously want to make a distinction that 
CLIENT != browser.)

Section 3: "ORIGIN" ... I agree that the definition is compatible with 
2616.  (I'm guessing the intent is to remove or re-word notes in the copy 
going to rfc-editor?  [This latter point is a query regarding section 3 in 
general.])

Section 3: "PUBLISHER" ... does this convey sufficient information?  Or is 
it left intentionally vague?  (Publisher in the media sense, or in the 
sense of the folks whose system moves content bytes from storage to 
network?)

Section 3: In the definition of "SERVER" you mention "REQUEST" - yet I 
cannot find the term defined in one word within this document.  Same with 
RESPONSE.  I think you meant to attach "CONTENT" before each?

Section 3: "SURROGATE" ... Not sure why the "overly elaborate" definition 
in 3040 doesn't work, though I can understand a desire to not go into cross 
reference hell even further (we mention gateways and tunnels, for example). 
Is your definition compatible with 3040?

Section 4: First sentence, does a tactfully placed "as" make that sentence 
easier to read? ("There are limits as to ...")

Agree with Phil's concerns on CONTENT REPLICATION