Re: "Group last call":draft-cain-cdnp-known-request-routing-03.txt

["Phil Rzewski" <philr@inktomi.com>]

Looking good. Here's some minor edits... mostly
grammatical/formatting/meticulous things... just wanna save us bouncing
when we
submit for wider approval.

- I think it needs a general scrub to make sure it's RFC-format clean. For
example, I didn't see the usual hard ^L page separators.

- The page headers show "May 2002", but I believe the custom is to have the
publish date up there (November 2001).

- The title contains the legacy term "CDN", whereas I'm seeing more of our
documents referring to "CN" nowadays (except where we want to draw people's
attention specifically to the CDN market, e.g. the Akamai/Digital Islands of
the world). While MOST of the methods described in this document are, in fact,
used only in those very CDN networks, some of the methods (in-path elements)
are used in more general CNs. My suggestion (but I'm open to other thoughts
here) would be to avoid worrying about contexts to say CDN vs. CN and just say
CN everywhere.

- Abstract. "...and possible set of metrics." I think this should be "...and a
possible set of metrics" (that is, include the "a").

- Introduction (first paragraph). Same as previous edit

- Introduction (third paragraph). I think the last sentence should be cut,
since the reader is not assumed to know what DNS Request-Routing is yet.

- Section 2 (last sentence). I think this should close "...based on user
defined policies, metrics, or a combination of both."

- Section 2.3.1 (third paragraph). The sentence "Basically, the last DNS
server
solely determines the TTL for this record" is redundant, since you said the
same thing in the first sentence.

- Section 2.6 (third paragraph). "The same address, is used by multiple
physical DNS servers". I think you can remove the comma in there.

- Section 2.6 (third paragraph). Probably good to replace the references to
"OSPF and BGP" with the more generic "IGP and EGP" (since some people use ISIS
and RIP instead of OSPF).

- Section 2.7 (first sentence). I think this should read "...object type,
object hash, or similar information..." (that is, include a comma).

- Section 2.8 (bullet #2). "(TTL)values" include a space after the ")".

- Section 2.8 (bullet #2). Probably clearer to replace "hanging conditions"
with just the single word "outages".

- Section 2.3 (bullet #4, last sentence). Probably should read "...to
determine
a client's proximity..." (that is, include the "a").

- Section 3 (first paragraph). In the text "...could be used in combination of
user-defined policies..." should probably replace "of" with "with".

- Section 3 (second paragraph, last sentence) "...would typically takes the
direct path". Replaces "takes" with "take".

- Section 4.1.1.1 (first paragraph). Mention of HTTP and RTSP should probably
include a numbered [ ] reference after each one.

- Section 4.1.1.2. You may want to mention that in-path elements are roughly
equivalent to interception methods (aren't they?) and point people to RFC3143
for a more detailed discussion on the drawback of those methods. I think this
will placate many end-to-end fetishists.

- Section 4.1.1.2 (last paragraph, last sentence). You may want to change
"...non-cacheable objects..." to "...non-cacheable object types..." (or
something else that indicates you're choosing not to redirect based on
examining request URI or headers). Without this, some smartypants may point
out
"how do you know it's not cacheable until you get the object?

- Section 4.2.3 (first sentence). I think this is clearer if it were written
"As a Request-Routing mechanism, content modification suffers from the
following limitations:"

- Section 4.2.3. Would we want to list as another limitation that someone may
bookmark an item that has a URL pointing directly to a surrogate? (I suppose
this is a limitation with 302 methods as well.)

- Section A.1.1 (second paragraph, last sentence). "...and to probe those
blocks." Should we say "and to probe random addresses within those blocks". As
we know, there's really no way to "probe a prefix", you can only probe a host.

- Section A.2.2 (first sentence). It's more of a list than a summary, so
perhaps it should just read "The following is a list of several metrics used
for surrogate feedback."

--
Phil


At 12:42 PM 11/2/2001 -0500, Abbie Barbir wrote: 

>
> hi all, 
>
> This is a CDI "Group last call" for comments on draft 
> "draft-cain-cdnp-known-request-routing-03.txt". 
>
> This last call closes on Sunday November 18th. 
>
> Please post any final comments you have on this draft to this list by that
> date. 
>
> The draft is available at 
>
>
> <http://www.ietf.org/internet-drafts/draft-cain-cdnp-known-request-routing
>
> -03.txt>http://www.ietf.org/internet-drafts/draft-cain-cdnp-known-request-
> routing-03.txt 
>
>
> thanks 
> abbie 



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