Use Cases for Content Delivery Network Interconnection
draft-ietf-cdni-use-cases-10

[Ballot comment]

Thanks for addressing my discuss points.

While not raising to the level of a discuss  I'd suggest
the following phrases in appendix A might usefully be
changed:

- s/available 28 days after DVD release//

-  "user agent identification or authorization" is odd, why
would a CDN care if I use FF or IE? maybe s/agent//

- s/only in UK//

- Another patent declaration on a use-cases document. Sigh.
(No action is required, I'm just lamenting;-)

[Ballot comment]
Was nothing learnt from RFC 3570 and no mention or acknowledgement of
the authors of that work due?

---

Would it be possible to add a figure to Section 3? They are very helpful
in 1.3 and 2.4.

---

Section 8 could point to A.2

[Ballot discuss]
I support this document, one easy-to-fix DISCUSS though
Section 1.1 Terminology
  We adopt the terminology described in
  [I-D.ietf-cdni-problem-statement], and [I-D.ietf-cdni-framework].

We need to read the terminology from [I-D.ietf-cdni-problem-statement] in order to understand this draft.
So this should be a normative reference, right? Note: this is fine since the cdni-problem-statement is now in the RFC-editor queue.

However, wrt [I-D.ietf-cdni-framework], I don't think it's fine to have an informative reference (regarding terminology) to a future document.
What if the definitions change after this document publication, will this document still be readable? Maybe yes, maybe no.
The good news is that the 7 terms defined in [I-D.ietf-cdni-framework] are not used in this document. So you should simply remove "and [I-D.ietf-cdni-framework]"

[Ballot comment]
- Title says "1.3.  Rationale for Multi-CDN Systems" but the content is about CDN Interconnection.
Shouldn't the title be "Rationale for CDN Interconnection"?
Or maybe I missed a subtle difference between the two terms?

- I like the fact the terms defined in [I-D.ietf-cdni-problem-statement] are capitalized. It would be nice to clearly mention that in the terminology section.
It helps a lot the reader as he doesn't know what he doesn't know (i.e. that a term is defined somewhere else.). Yes sure, you wrote "We adopt the terminology described in [I-D.ietf-cdni-problem-statement]" that would help the reader anyway.

Example: rfc5982
  The IPFIX-specific and PSAMP-specific terminology used in this
  document is defined in [RFC5101] and [RFC5476], respectively.  In
  this document, as in [RFC5101] and [RFC5476], the first letter of
  each IPFIX-specific and PSAMP-specific term is capitalized along with
  the IPFIX Mediation-specific terms defined here.

Note: I haven't checked the consistency of the capitalization

- " The End User benefits from this arrangement through a better Quality
  of Experience (QoE), "

QoE definition in RFC6390

[Ballot comment]
0) Process Question: Do you want to also make RFC 3570 historic?

1) Stephen beat me to the DRM issue - needless to say I agree with him.

2) s1.2: DRM is listed but not used in the draft.  Use it or lose it :)

3) a/s1/s1.3/s2.1: Anytime I see "cost" I think marketing.  Honestly think you could elide the cost discussion from the draft and it would be fine.  Besides cost savings are already called out in the problem statement.  (reminder this is a non-blocking comment).

[Ballot comment]

  Please consider the editorial comment from the Gen-ART Review by
  Suresh Krishnan on 16-July-2012.  The review can be found here:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07608.html

[Ballot discuss]

I am concerned that this document is fairly full of DRM
related use cases, when DRM mechanisms are explicitly ruled
out of scope by the WG charter.

- The "distribution rights" example in 1.3 is basically a
DRM thing. 

- The last paragraph of 2.4 (referring to A.1) is also a DRM
example.

- The second paragraph of 3.1 talks about "exclusive
distriubtion rights."

- A.1 refers explicitly to "license violations."

- A.2 refers to "content protection"

- It seems therefore that section 5 is thus not justified
with the current DRM-only examples.

Are there no better (technical) reasons why policy needs to
be applied that could be used as examples?  Note: I'm not
saying these examples are "wrong" but rather that we need
non-DRM use-cases to motivate things.

[Ballot comment]

- I don't get how End-user B in 2.4, who's not allowed
access stuff, is relevant for CDNI. Are you saying that CNDI
protocols will carry authentication or authorization PDUs
specific to end-users? I didn't think that was going to be
the case.

- Another patent declaration on a use-cases document. Sigh.
(No action is required, I'm just lamenting;-)

[Ballot comment]
Totally trivial:

-- Abbreviations --

  WiFi: Wireless Fidelity

Really?  You made that up, right?  I suggest this:
WiFi: Wireless local area network (WLAN) based on IEEE 802.11.
(Or just the first part.)

IANA has reviewed draft-ietf-cdni-use-cases-08, which is currently in
Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no IANA
Actions that need completion.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Use Cases for Content Delivery Network Interconnection) to Informational RFC


The IESG has received a request from the Content Delivery Networks
Interconnection WG (cdni) to consider the following document:
- 'Use Cases for Content Delivery Network Interconnection'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-07-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Content Delivery Networks (CDNs) are commonly used for improving the
  End User experience of a content delivery service, at a reasonable
  cost.  This document focuses on use cases that correspond to
  identified industry needs and that are expected to be realized once
  open interfaces and protocols supporting interconnection of CDNs are
  specified and implemented.  The document can be used to guide the
  definition of the requirements to be supported by CDN Interconnection
  (CDNI) interfaces.  It obsoletes RFC 3570.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-cdni-use-cases/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-cdni-use-cases/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1764/

Document Shepherd Writeup for "Use Cases for Content Delivery Network Interconnection", draft-ietf-cdni-use-cases-07.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

This draft is intended to become an Informational RFC, and the type is indicated in the title page header.

The document shepherd believes that this is the proper type of RFC for a use cases document.

The type of RFC is stated in the title page header.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

Content Delivery Networks (CDNs) are commonly used for improving the
  End User experience of a content delivery service, at a reasonable
  cost.  This document focuses on use cases that correspond to
  identified industry needs and that are expected to be realized once
  open interfaces and protocols supporting interconnection of CDNs are
  specified and implemented.  The document can be used to guide the
  definition of the requirements to be supported by CDN Interconnection
  (CDNI) interfaces.  It obsoletes RFC 3570.

Working Group Summary

There was strong consensus in the CDNI WG to publish this document
to document the use cases to be supported by the deliverables of the working group.

Document Quality

Despite many existing CDN implementations, there are no
implementations of CDN interconnection that support the use cases presented in this document.
Many CDN technology vendors and service providers are interested in supporting and deploying the use cases discussed in this document.

Personnel

Francois Le Faucheur (flefauch@cisco.com) is the Document Shepherd.
Martin Stiemerling is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document shepherd reviewed the document for nits and for content, and all comments have been thoroughly addressed in this version. The document shepherd believes that this version of the document is ready for publication.

(4) Does the Document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

This draft was appropriately reviewed by the CDNI working group.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

The Document Shepherd doesn't think any additional specific review is required.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

The Document Shepherd has no specific concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes, confirmed by each author.


(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

One IPR disclosure has been filed: https://datatracker.ietf.org/ipr/1764/
This IPR disclosure has been announced to the WG and has not raised any concern. Note that this document is an Informational use case document and also that the IPR and that the IPR statement includes a  "No License Required for Implementers" licensing declaration.


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

This document represents the strong concurrence of a significant proportion of the CDNI working group.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No one has raised an objection against this document, to the best knowledge of the Document Shepherd.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

The Document Shepherd has found no nits with the draft.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

As a Use Cases document with Informational content only, no formal review is required.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

There are no normative references.

(15) Are there downward normative references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

There are no downward normative references.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

This document proposes to replace RFC 3570. This is stated on the pager header, listed in teh abstract and discussed in the introduction.
An alternative approach could be to "Update" RFC 3570 (instead of "Replace" RFC3570). We felt "Replace" was the preferable option since the document touches on the same topic as RFC3570 but described slightly different terminologies and models. So keeping the two documents (and effectively saying that the second one changes the first one whenever they differ) would be confusing and would not bring much extra value. But guidance is welcome.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

This document has no IANA considerations.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No new IANA registries will be created by this document.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

No parts of the document are written in a formal language.

(end)