Subject: [CDNi] comments on draft-lefaucheur-cdni-requirements-00

From: "Kent Leung (kleung)" <[email-masked]>
Date: Wed, 30 Mar 2011 07:39:47 -0700

Here are some comments on this draft.  I hope there aren't too many
overlaps with previous discussions or already addressed in version -01.
Also, there are additional editorial nits that I will send directly to
the authors.  Overall, I think it is well written.

1.       Sect. 3.1: Not sure where to put the requirement that a CDN
must be able to perform as both Upstream CDN and Downstream CDN.  Maybe
this is obvious?  A CDN may be perform the role of only Upstream CDN,
Downstream CDN, or both functions.

2.       R5: Content acquisition requirement is defined within CDNI
scope, but Figure 1 shows out-of-scope. Content acquisition should be an
interface defined between CDNs and within scope of CDNI.  Other
protocols besides HTTP may be introduced in the future.

3.       Sect. 4: There should be one interface for CDNI Control API.
However, there may be one or more protocols to provide the required
functions.

4.       Sect. 4.1: Does Control API need to be reliable?  Assume so,
should be specified.

5.       R12: "coarse information" -> Maybe "basic information"?  That
is: The intent is to provide sufficient information to perform the
rudimentary tasks of content distribution and delivery.

6.       R13: I think this requirement should stay in Control API.  This
is to bootstrap the Request Routing API by providing reachability info
on the RR System.  I assume that it's not providing any semantics for
RR.  Regardless, it would be useful to spell out the reasoning for
putting the requirement in Control API vs RR/Metadata APIs to be
consistent.

7.       R16: I think this requirement should remain under Metadata API
because Control API should only deal with the parameter of the other
APIs (e.g. limit on requests for RR, storage capacity of metadata and/or
content, etc.)  The specifics of which object or content to remove from
cache should be a function of distribution interface (Metadata API).  

8.       R17: Why isn't this within initial CDNI scope?  Seems
establish, update, and terminate CDNI is needed right away.

9.       R18: Useful to mention "loop free". :)

10.   R19: Does this mean "DNS or HTTP or both"?  What level of
granularity is specified (e.g. for DNS, method used is NS, CNAME, and/or
A)?  RTSP redirect?

11.   R25: I agree with this.  But Content Acquisition is not a defined
CDNI API.  It should be so this requirement can be met.

12.   R25: ATIS C2 is an interface, not protocol in the example.

13.   R27: E.g. specify events that trigger reporting, reporting rate,
what to do when reports cannot be received

14.   Sect. 5.1: Does RR API need to be reliable?  Or depend on UA to
re-transmit the request if API message is lost?

15.   R28/R29: Small vs large objects need to be defined in the RR API.
Or another way to put it, size determines DNS or HTTP method.

16.   R30: Cascaded CDNs is not mandatory for initial CDNI scope, right?

17.   R31: Cascaded CDNs is not mandatory for initial CDNI scope.
Should iterative be mandatory, but  recursive is optional (similar to
DNS)?

18.   Sect. 5.2: RR API should handle case when mechanism does not
conform to the policy dictated in the Control API (e.g. HTTP message
received by downstream CDN when DNS was negotiated).  Should this event
trigger Control API messaging?

19.   Sect. 6: Metadata API is a single interface, which may have
multiple protocols, right?

20.   R44: Not clear.  If "no metadata is communicated", then there's no
need for "how/where to acquire".

21.   R45: Why shouldn't Metadata API support this mode?

22.   R47: For "beyond initial CDNI", Downstream CDN can acquire from
Upstream-upstream CDN in the cascaded case?  One level up may not be the
Origin Server.

23.   Sect. 7: Single interface, may be multiple protocols

24.   Sect. 7.2: Logging API may provide aggregate counters based on
filters (time period, topology, etc.)?  This avoids volume of logging
records for each request routing or content distribution if that is not
desired.

25.   R66: Should this be part of Control API, which sets the Logging
API endpoints and possibly transport mechanism? Related to earlier
comment about reasoning for Control API vs. Other CDNI APIs.

Kent