Content Distribution Network Interconnection (CDNI) Problem Statement
draft-ietf-cdni-problem-statement-08

I found Appendix A a little suspect. While it demonstrates that the problem could be solved, it also seems to end-run the discussion of which protocol solution should be developed. I would like it if the introduction indicated that the content of the Appendix is purely examples and that further analysis will be made before the WG decides on the correct solutions.

All comments addressed in the -07 version.  Thanks for taking the time!

[Thanks for addressing my DISCUSS and COMMENT, which I kept for the record below, since this draft will be on the next IESG telechat]

DISCUSS:


Preliminary note: between the 3 different chartered items (problem statement, uses cases, and requirement), I'll be specifically checking for the manageability and operational requirements in the requirement document. So hopefully the uses cases document will not only address what the use cases are, but how the operators plan on supporting those use cases.

The only manageability aspect concern I noticed is

   o  CDNI Logging interface: This interface allows the Logging system
      in interconnected CDNs to communicate the relevant activity logs
      in order to allow log consuming applications to operate in a
      multi-CDN environments.  For example, an upstream CDN may collect
      delivery logs from a downstream CDN in order to perform
      consolidated charging of the CSP or for settlement purposes across
      CDNs.  Similarly, an upstream CDN may collect delivery logs from a
      downstream CDN in order to provide consolidated reporting and
      monitoring to the CSP.

The Logging System doesn't mention fault management, which is consistent with the above text.
However, the problem I have is that section 4.3 "CDNI Logging Interface" mentions "events" for the first time.

   The CDNI Logging interface enables details of logs or events to be
   exchanged between interconnected CDNs, where events could be for
   example log records related to the delivery of content (similar to
   the log records recorded in a web server's access log) as well as
   real-time or near-real time events before, during or after content
   delivery and operations and diagnostic messages.

So clearly, the intend here is that you want to cover fault management as well, right?
Please be consistent between the Logging System definition, the CDNI Logging Interface and this section 4.3

COMMENT:

- the terminology order seemed weird initially when I had to search for a specific item. However, while reading through it, the order nicely helps the reader. Thanks.

- the surrogate definition could be improved to express that the device can be caching content.
This is mentioned later on in the draft:

   CDNs allow caching of content closer to the edge of a network so that
   a given item of content can be delivered by a CDN Surrogate (i.e. a
   cache) to multiple User Agents (and their End Users) without
   transiting multiple times through the network core (i.e from the
   content origin to the surrogate).

- In the Appendix B table of content, there is:

   Appendix B.  Additional Material . . . . . . . . . . . . . . . . . 27
     B.1.  Non-Goals for IETF . . . . . . . . . . . . . . . . . . . . 27
     B.2.  Related standardization activites  . . . . . . . . . . . . 29
       B.2.1.  IETF CDI Working Group (Concluded) . . . . . . . . . . 30
       B.2.2.  3GPP . . . . . . . . . . . . . . . . . . . . . . . . . 30
       B.2.3.  ISO MPEG . . . . . . . . . . . . . . . . . . . . . . . 31
       B.2.4.  ATIS IIF . . . . . . . . . . . . . . . . . . . . . . . 32
       B.2.5.  CableLabs  . . . . . . . . . . . . . . . . . . . . . . 32
       B.2.6.  ETSI MCD . . . . . . . . . . . . . . . . . . . . . . . 32
       B.2.7.  ETSI TISPAN  . . . . . . . . . . . . . . . . . . . . . 32
       B.2.8.  ITU-T  . . . . . . . . . . . . . . . . . . . . . . . . 33
       B.2.9.  Open IPTV Forum (OIPF) . . . . . . . . . . . . . . . . 33
       B.2.10. TV-Anytime Forum . . . . . . . . . . . . . . . . . . . 33
       B.2.11. SNIA . . . . . . . . . . . . . . . . . . . . . . . . . 34
       B.2.12. Summary of existing standardization work . . . . . . . 34
     B.3.  Related Research Projects  . . . . . . . . . . . . . . . . 36
       B.3.1.  IRTF P2P Research Group  . . . . . . . . . . . . . . . 36
       B.3.2.  OCEAN  . . . . . . . . . . . . . . . . . . . . . . . . 36
       B.3.3.  Eurescom P1955 . . . . . . . . . . . . . . . . . . . . 36
     B.4.  Relationship to relevant IETF Working Groups . . . . . . . 37

B.1 is useful: too many times we don't express which problem(s) we don't plan on addressing
Note that there is a little important line in there that is worth stressing: "Element management interfaces"
B.2 will be obsolete in a year from now. Personally I would not include this one. No strong feelings though
B.3 is not interesting, except maybe the IRTF P2P which could go in B.4
B.4 is very important to us.

Conclusion: I would definitively keep B1 and B4, maybe B2, and not B3 (except IRTF)

Sorry for the late defer. I really want to read this document and I won't get to it tonight.

  As suggested in the Gen-ART Review by Wassim Haddad, please define
  "Quality of Experience".  This phrase is mentioned four times in the
  document.