I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-cdni-problem-statement-04
Title: Content Distribution Network Interconnection (CDNI) Problem
        Statement
Reviewer: Vijay K. Gurbani
Review Date: Apr-16-2012
IETF Last Call Date: Not known
IESG Telechat Date: Not known

Summary: This draft is ready for publication as an Informational.

Major Issues: 1
Minor Issues: 5
Nits:         4

Major Issues:
- S6: I believe that expanding the security considerations for each
  CDNI interface will help in the long run.  Here is a first stab at
  this that you may want to consider replacing the second paragraph
  with (please feel free to expand this since you are the subject
  matter experts here).  Suggested text:

  6.1 Security of the CDNI Request Routing Interface

    Appropriate levels of authentication and confidentiality must be
    used in this interface because it allows an upstream CDN to
    query capabilities of a downstream CDN, and conversely, allows
    the downstream CDN to control the upstream CDN's Request Routing
    function.

    Absent appropriate security on this interface, a rogue upstream
    CDN can inundate downstream CDNs with bogus requests, or have the
    downstream CDN send the rogue upstream CDN private information
   (e.g., load, resources).

  6.2 Security of the CDNI Control Interface

    Information on this interface is of a very private nature as well.
    A pair of CDNs use this interface to allow bootstrapping of content
    acquisition; an upstream CDN may pre-position content in a downstream
    CDN, or it may purge the contents at a downstream CDN; a downstream
    CDN may provide administrative information to an upstream CDN, etc.
    All of these operations require that the peer CDNs are appropriately
    authenticated and that the confidentiality of information flowing
    between them is maintained.

  6.3 Security of the CDNI Metadata Interface

    Because this interface allows a downstream CDN to request metadata
    from an upstream CDN, the latter must ensure that the former is
    appropriately authenticated before sending the data.  Conversely,
    a downstream CDN must authenticate an upstream CDN before requesting
    metadata to insulate itself from poisoning by rouge upstream CDNs.
    The confidentiality of the information exchanged between the peers
    must be protected.

  6.4 Security of the CDNI Logging Interface

    Logging data consists of potentially sensitive information (which
    user accesses which media resource, IP addresses of users, potential
    names and subscriber account information, etc.)  This information
    must be protected as the log records are moved between hosts.

Minor Issues:

- S1: Your problem statement essentially is an interplay between
  four logical entities: end user, CSP, CDN, and NSP.  I think this
  interplay needs to be laid out a bit more explicitly.  It seems to me
  that your model is that a user is subscribed to a CSP.   The CSP has
  arrangements with various CDN providers to distribute content.  The
  user, at a certain point in time, is in a network owned by a NSP that
  uses a CDN that does not have receive content from CSP.  Thus CSP is
  at a disadvantage since it will have to serve the user from a CDN that
  is not necessarily close to the user, thereby introducing a reduced
  quality of experience for the user.

  What CDNI does is enable the CSP to contract with an "authoritative"
  CDN provider for the delivery of content and that that
  authoritative CDN Provider could contract with one or more downstream
  CDN Provider(s) to distribute and deliver some or all of the content
  on behalf of the authoritative CDN Provider.  Because the downstream
  CDN Provider(s) will be closer to the user, the user is subjected to
  a better viewing experience than he or she would be had the content
  been delivered from a farther CDN.

  I think that laying out the interplay between the four entities in
  the second paragraph of S1 more explicitly may provide better context
  to the reader who is not already well versed with CDNs.

- S1: I would advise to order the terms defined by an alphabetical
  order (if possible).

- S3, last paragraph: The term "where to go" is rather ambiguous.
  Do you mean, "which upstream CDN to acquire content from"?  Or
  something else?  It will help to make this more explicit.

- S4, last paragraph: it is stated that "we assume that this [developing
  a new protocol] is unnecessary".  Based on the contents of S4.1-
  S4.4, I believe you do more than "assume".  You clearly enunciate a
  list of protocols that can be used for the various interfaces, thus
  providing a first order reasoning for why a new protocol for CDNI
  is not needed.

  Therefore, I would exhort you to use a stronger word than "assume";
  something like:

    Secondly, although a new application protocol could be designed
    specifically for CDNI, our analysis below shows that this is
    unnecessary ...

- S4.3: Are these "log lines" or "log records"?  Presumably, one or
  more lines will aggregate to one log record.  It seems appropriate
  in this document to talk about "log records" instead of "log lines".
  The CDNI logging interface draft can tease out more precisely how
  many lines comprise a record, etc.

  Secure ftp and secure copying (scp) appears to be missing in the list
  of protocols.  I would suspect that sftp would be preferred over
  normal ftp.

Nits:

- Global: In the Abstract and S1, "End Users" is employed multiple
  times.  End Users is defined in the Terminology section as a
  definition.  I would propose that attach the acronym "EU" on
  the first encounter of "End User" in the Abstract and S1,
  and from then on simply use "EU".

- S1, second paragraph: "attachment network" sounds incomplete.
  Maybe you meant "attachment to the network"?

- S3: s/existing protocols: this is/existing protocols; this is/

- S4.1, last paragraph: May be good to give a reference to ALTO.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
Web:   http://ect.bell-labs.com/who/vkg/