[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: comments on various CDN Internet Drafts



Thanks for the detailed comments. The discussion archives are in the
pub/lists directory of the ftp server ops.ietf.org.  There are several files
of the form cdn.* where the suffix is either a date encoding or "current".

I will respond to your comments on the model document and hope that others
can respond for the other docs.

> draft-day-cdnp-model-05.txt
>
> + p.9 "AUTHORATIVE REQUEST-ROUTING SYSTEM": the following sentence
>   from the request-routing requirements document should be added to
>   the definition to make it more precise: "REQUEST-ROUTING SYSTEMs
>   MUST be able to respond to request-routing requests for content for
>   which they are authoritative" (on p.8).

In the model, I think we are simply identifying what a RRS is, not laying
requirements on it. I agree that it would be helpful to make that difference
in intent clear.

> + p.10 "DISTRIBUTION ...": the paragraph does not make it clear
>   whether communication of CONTENT SIGNALs (as opposed to CONTENT) is
>   part of DISTRIBUTION as well (I guess it is)

Yes, I think it is too. I will work to improve the clarity here.

> + p.11 "REQUEST-ROUTING": append "Some state-of-the-art
>   request-routing techniques are presented in [6]."

Agreed.

> + p.11 "REQUEST-ROUTING SYSTEM": definitions of ACCOUNTING SYSTEM and
>   DISTRIBUTION SYSTEM do not include "single CONTENT NETWORK"
>   constraint; maybe it should be added for reasons of symmetry/clarity

Agreed that these should be consistent.

> + p.11 "Receives a mapped request": if use of REQUEST-ROUTING is
>   preferred over MAPPING, then what's the corresponding verb to use ?

Heh. Technically, I think the right answer is "request-routed", so this
would be corrected to "receives a request-routed request." I don't think
that's pretty, but it's accurate.

> + p.11 "Because CDNs contain": perhaps clarify as "Because CDNs
>   contain ... as discrete elements"; I understand that
>   e.g. proxy-cache-based CNs contain (implicit and very simple)
>   request-routing systems as well

I don't know if I agree with this specific change, but I agree that this
section is still showing some signs of CDN-focused bias, and that I should
fix it.

> + p.13 "DISTRIBUTION PEERING": send-only (INJECTION) and receive-only
>   forms of DISTRIBUTION PEERING are mentioned in this and other
>   documents; maybe extend definition to clarify these sub-terms

OK, agreed that there should be consistency.  I suspect that Phil and I will
have to arm-wrestle or something about the relative importance to assign to
INJECTION, but we should definitely make that uniform across the documents.

> + p.13 "PEERING SYSTEM": it may be worthwhile/correct to add that
>   peering starts with pairwise ralationships, and meshes can then be
>   built by aggregating such point-to-point connections; from the
>   second paragraph in section 3.1 [3] it would seem that PEERING
>   SYSTEMs always constitute parts of CONTENT PEERING GATEWAYs (the
>   corresponding SYSTEMs, such as DISTRIBUTION SYSTEMs, on the other
>   hand belong inside the CONTENT NETWORKs); other descriptions seem to
>   suggest that each CONTENT NETWORK provides its own PEERING SYSTEMs
>   as external interfaces, or that PEERING SYSTEMs are an accumulation
>   of corresponding elements from across all participating CONTENT
>   NETWORKs (e.g. Figure 3 in [2]); please clarify definition; similar
>   (small) inconsistencies exist for the exact relationship between CNs
>   and CPGs

Yes, as this model has evolved and changed numerous small inconsistencies
have crept in.  Thanks for catching them, and I hope we don't trigger
religious wars as we work to eliminate the inconsistencies.

--Mark