[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