Subject: Re: [apps-discuss] Review of draft-ietf-cdni-problem-statement-04

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 30 Apr 2012 20:03:55 +0000

Francois, Vijay,

See below for responses/comments and see attached for the current working
text.

Francois - let me know if you want me to publish -05 from this working
text or not.

On 25/04/2012 19:34, "Francois Le Faucheur" <[email-masked]> wrote:

>Vijay, Ben, Nabil, all,
>
>On 16 Apr 2012, at 17:44, Vijay K. Gurbani wrote:
>
>
>Major Issues:
>- S6: I believe that expanding the security considerations for each
> CDNI interface will help in the long run.
>
>
>
>FLF: Below is an edited/expanded version of the Security Considerations
>section that integrates Vijay's comment and also captures a couple of
>high-level points from the Security Considerations section of the
>cdni-framework. Can you guys review and refine if needed?

I included the majority of your suggested text verbatim but I did a few
minor tweaks mainly for grammar. Rather than quote the whole section here
- see attached for the current working text of -05 with the new security
section.

>- 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.

This is quite difficult to do in a generalised way because the interplays
can vary quite a lot, this is what I came up with, does it address your
comment?

   A typical content delivery scenario involves an End User requesting a
   given content item from a Content Service Provider (CSP) who
   contracts a CDN to perform delivery on the content on behalf of the
   CSP.  Content delivered by the CDN may traverse one or more NSP
   networks in order to reach the End User.  The CSP, CDN and NSP roles
   may be played by separate entities or a single entoty may play more
   than one role.  For example an NSP may also have a CDN that 3rd party
   CSPs can contract for the delivery of their content, or the NSP may
   offer video services directly to their subscribers and therefore also
   play the role of CSP while contracting the delivery of the content to
   a 3rd party CDN.  Etc.

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

The idea of the ordering was that forward references are minimised, so the
definition of a given term is only dependent on the preceding definitions.
I suggest we leave it to the RFC Editor to align with their preferred
ordering.

>- 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.

Replaced with "the parameters to use to retrieve the content for example
the IP address/hostname to connect to, what protocol to use to retrieve
the content, etc."

>- 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 ...

Done.

>- 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.

Agreed. I've replaced all instances of log line with log record.

> 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.

The list wasn't intended to be exhaustive but I added your examples in.

>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".

I changed in section 1. I'll leave the abstract to the RFC Editor as they
have some rules over what they like expanded/not expanded in the abstract
that I can never remember.

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

I've changed to "regardless of that EU's location or the network they are
attached to" does that make the intent clearer?

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

Done.

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

Done.

Ben

>
>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 <http://acm.org>} /
>[email-masked]
>Web:   http://ect.bell-labs.com/who/vkg/
>
>
>
>
>
>
>
>Francois Le Faucheur
>Distinguished Engineer
>Service Provider Video Technology Group
>[email-masked]
>Phone: +33 49 723 2619
>Mobile: +33 6 19 98 50 90
>
>
>
>Cisco Systems France
>Greenside
>400 Ave de Roumanille
>06410 Sophia Antipolis
>France
>Cisco.com <http://www.cisco.com>
>
>
> 
>
> Think before you print.
>This email may contain confidential and privileged material for the sole
>use of the intended recipient. Any review, use, distribution or
>disclosure by others is strictly prohibited. If you are not the intended
>recipient (or authorized to receive for the recipient), please contact
>the sender by reply email and delete all copies of this message.
>
>Cisco Systems France, Société à responsabiité limitée, Rue Camille
>Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les
>Moulineaux, Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur
>de la publication: Jean-Luc Michel Givone.
>
>For corporate legal information go to:
>http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>
>
>
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 02 May 2012 14:33:10 -0500

On 04/30/2012 03:03 PM, Ben Niven-Jenkins wrote:
> text.  [...]

Ben, Francois: Thanks for addressing my review in the manner you
suggested.

I have no further comments on the draft.  It is good to go from my side.

Ciao,

- 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} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 3 May 2012 11:31:43 +0100

> I have no further comments on the draft.  It is good to go from my side.

Thanks, I uploaded a new version that addresses your comments and includes some other edits by Francois.

http://www.ietf.org/id/draft-ietf-cdni-problem-statement-05.txt

Ben

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 3 May 2012 11:16:21 +0200

Hi Ben,

Attached is a slightly edited version (changes showing up with change bars). They are purely editorial, except one change: which is I moved and tweaked the text addressing Vijay's comment suggesting we better expand the interplay relationships between the 4 entity. I think this text needs to be moved somewhere towards the end of paragraph 2 , instead of before paragraph 2, because paragraph 2 is where we first introduce the notion of interconnecting CDNs, and that notion is required to expand the full interplay relationship. 

Also, I have the following comment/questions:

*** ALTO reference.
In section 4.1, you added a ref to the ALTO-Charter. I wonder if this is a permanent enough ref (i.e. does charter URI remain as is if WG concludes)? How about referring an ALTO RFC (e.g. ALTO Problem Statement)?
I know we already refer to the charter in the discussion on relationship to ALTO, but that has been moved to the Appendix , precisely to avoid issues of instability.

*** adding scp in list of example protocols:
Is there a clear reference we can use for SCP? If yes, we should probably include it. If not, I wonder if we really need to include that example.
 
*** Ack section:
A few sentences I introduced in the security considerations section are heavily inspired by some text in the Framework document., So we we may want to add Larry Peterson's name in the Ack section (or alternatively ack that we leveraged some work of framework doc re security considerations).

Cheers

Francois

Francois Le Faucheur
Distinguished Engineer

Cisco Systems France
Greenside
400 Ave de Roumanille
06410 Sophia Antipolis
France
Cisco.com

 Think before you print.

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

Cisco Systems France, Société à responsabiité limitée, Rue Camille Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux, Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel Givone.