Content Distribution Network Interconnection (CDNI) Requirements
draft-ietf-cdni-requirements-17

[Ballot comment]

--- old comments

- Please define "sign" as you intend it to be used and
distinguish between digital signatures (e.g. generated
with an RSA private key) and MACing. Being vague on that
in these requirements may lead to pain later on, e.g. if
you realise that you need to add (or protect) some key
management gunk too late in the day.

- FCI-5: RTMP needs a reference

- SEC-*: The term non-repudiation seems meaningless here
(as usual;-). But I think I recall that CDNI has its own
definition for that - in which case you really would be
better to include or refer to that.

[Ballot comment]
After discussion with both Transport ADs, they've convinced me that this requirement is about the CDN having the ability to deliver via HTTP to the UA - not that the requirements are on the UA-CDN interconnection.  I'll leave it to the authors/ADs to decide whether any updates to the draft are required based on that.

[Ballot comment]
Thanks for addressing my DISCUSS.

-
1.1. Terminology

  This document uses the terminology defined in [RFC6707] as well as in
  section 1.1 of Framework for CDN Interconnection
  [I-D.ietf-cdni-framework].

Can you either the following sentence
  In this document, as in [RFC6707], the first letter of each term in the
  terminology section is capitalized.
Alternatively, include the terms used in this document.
  The A, B, C, D,terms, used in
  this document are defined in [RFC6707].

For example, I was confused by the User Agent, user agent, user-agent, until I realized that User Agent is actually a definition from RFC 6707

[Ballot discuss]
(1) GEN-12 (and probably elsewhere) - when this says
"identify a user agent" does that mean e.g. "FF/chrome" or
"Joe User using FF/chrome"? In the latter case the privacy
issues are harder to handle, so I think you should be
precise with such statements.

(2)-(5) cleared

[Ballot comment]

- Please define "sign" as you intend it to be used and
distinguish between digital signatures (e.g. generated
with an RSA private key) and MACing. Being vague on that
in these requirements may lead to pain later on, e.g. if
you realise that you need to add (or protect) some key
management gunk too late in the day.

- FCI-5: RTMP needs a reference

- SEC-*: The term non-repudiation seems meaningless here
(as usual;-). But I think I recall that CDNI has its own
definition for that - in which case you really would be
better to include or refer to that.

[Ballot discuss]

(1) GEN-12 (and probably elsewhere) - when this says
"identify a user agent" does that mean e.g. "FF/chrome" or
"Joe User using FF/chrome"? In the latter case the privacy
issues are harder to handle, so I think you should be
precise with such statements.

(2) RI-8 - including location-determining information here
is privacy sensitive - what requirements exist to
obfuscate or protect privacy in such cases?

(3) RI-14 - this reads like a solution and not a
requirement and at least needs some reference to the
"authorization group ID." I'm not sure what to suggest to
fix that though - is there a more generic way to state
what you need, that's less solution-like?

(4) LI-17 - I don't get the justification for why this is
"{MED}" and would personally consider it "{HIGH}" - what
is that justifiction? But thank you for inlcluding this,
it will I suspect be important for CDNI to be accepted in
various places at various times in the future.

(5) Overall: I would have preferred to see some overall
privacy requirements stated - don't you think that that
would offer advantages? Did the WG consider doing that?
I'll clear this point when you answer but wanted to at
least give you the chance to think about whether to ask
the WG, if that didn't happen before.

[Ballot comment]


- Please define "sign" as you intend it to be used and
distinguish between digital signatures (e.g. generated
with an RSA private key) and MACing. Being vague on that
in these requirements may lead to pain later on, e.g. if
you realise that you need to add (or protect) some key
management gunk too late in the day.

- FCI-5: RTMP needs a reference

- SEC-*: The term non-repudiation seems meaningless here
(as usual;-). But I think I recall that CDNI has its own
definition for that - in which case you really would be
better to include or refer to that.

[Ballot discuss]
-
Like Adrian, I'm surprised that the priority scheme you have applied to the
requirements says nothing about the importance of the functions to
CDNI.
I've seen Kent's reply to Adrian's feedback.

However, I had to review multiple times the HIGH/MEDIUM/LOW definitions while reading the doc.
This was bothering me, and I called François to clarify a few things.
What elevates this to a DISCUSS is that the High/Medium/Low don't speak about the same criteria: "can be met" on one side, delay the WG on the other side
The outcome of discussion with François is that
- There is no notion of requirements importance in High/Medium/Low
- What's missing is that all requirements in this document are really about all important day 1 requirements.
- It's really about priority sequence for what the WG should be working on.
  Hence the name "High Priority" versus High (implicitly meaning Importance)


So
* important req. for day 1 and if WG needs to delay the solution to solve it, so be it = high
* important req. for day 1 but if it takes too long for the WG to solve it for the day 1 solution, this req. could be dropped = medium
* important req. for day 1 and would do it if the WG finds an easy fix that would not delay the day 1 solution = low

From here, two proposals:
1. An extra sentence in "High Priority"

      "High Priority" indicates requirements that are to be supported by
      the CDNI interfaces.  A requirement is stated as "High Priority"
      when it is established by the working group that it can be met to
      achieve the goal of a deployable solution in a short timeframe as
      needed by the industry.  The WG would be willing to delay the solution
      to meet that requirement. This is tagged as "{HIGH}".

And add a sentence about: all requirements in this document are really about all important day 1 requirements.
Now, I understand that, since the WG has been working on the solution already, the WG knows already that the High Priority requirement can be met.

2. Don't change the definitions but add an extra paragraph explaining:
* important req. for day 1 and if WG needs to delay the solution to solve it, so be it = high
* important req. for day 1 but if it takes too long for the WG to solve it for the day 1 solution, this req. could be dropped = medium
* important req. for day 1 and would do it if the WG finds an easy fix that would not delay the day 1 solution = low


-
Data model extensibility (extensions or proprietary informations)
I see this requirements for the CDNI Logging interface. This is fine.

  LI-14  {HIGH} The CDNI Logging interface shall support the exchange
          of extensible log file formats to support proprietary
          information fields.  These information fields shall be agreed
          upon ahead of time between the corresponding CDNs.

However, I don't see the same requirement for metadata (section 7) and capabilities advertisement (section 6)
The metadata and capabilities advertisement requirements will need to be different in the future, to enable new services.
Such requirements in this document would lead to
- thinking on how to do your data model
- thinking on how to extend the data model and specify protocol extensions
- IANA potential implications

[Ballot comment]
-
1.1. Terminology

  This document uses the terminology defined in [RFC6707] as well as in
  section 1.1 of Framework for CDN Interconnection
  [I-D.ietf-cdni-framework].

Can you either the following sentence
  In this document, as in [RFC6707], the first letter of each term in the
  terminology section is capitalized.
Alternatively, include the terms used in this document.
  The A, B, C, D,terms, used in
  this document are defined in [RFC6707].

For example, I was confused by the User Agent, user agent, user-agent, until I realized that User Agent is actually a definition from RFC 6707

-

  GEN-5  {HIGH} The CDNI solution shall support delivery to the user
          agent based on HTTP [RFC2616].  (Note that while delivery and
          acquisition "data plane" protocols are out of the CDNI
          solution scope, the CDNI solution "control plane" protocols
          are expected to participate in enabling, selecting or
          facilitating operations of such acquisition and delivery
          protocols.  Hence it is useful to state requirements on the
          CDNI solution in terms of which acquisition and delivery
          protocols).

Is the last sentence complete? Or you should remove "which"

-
  CI-12  {LOW} The CDNI Control interface may allow bootstrapping of
          the CDNI Logging interface.  This information could, for
          example, include:

          *  discovery of the Logging protocol endpoints


Logging protocol endpoints? I don't understand.
Maybe "discovery of CDNI logging interface endpoints"

-
CI-12  {LOW} The CDNI Control interface may allow bootstrapping of
          the CDNI Logging interface.  This information could, for
          example, include:

          *  discovery of the Logging protocol endpoints

          *  information necessary to establish secure communication
              between the Logging protocol endpoints

          *  negotiation/definition of the log file format and set of
              fields to be exported through the Logging protocol, with
              some granularity (e.g.  On a per content type basis).

          *  negotiation/definition of parameters related to
              transaction Logs export (e.g., export protocol, file
              compression, export frequency, directory).


So I understand that CDNI logging interface is file based?
Good, this is inline with:

  LI-6  {HIGH} The CDNI Logging interface shall define a log file
          format and a set of fields to be exported for various CDNI
          logging events.

However, what about real-time?
  LI-5  {MED} The CDNI Logging interface should also support
          additional timing constraints for some types of logging
          records (e.g. near-real time for monitoring and analytics
          applications)

So file or records for real time? Or records in a file?
I guess a file based system will not work for real time...

OLD:
  LI-5  {MED} The CDNI Logging interface should also support
          additional timing constraints for some types of logging
          records (e.g. near-real time for monitoring and analytics
          applications)

NEW:
  LI-5  {MED} The CDNI Logging interface should also support
          an additional mechanism taking into accounting timing constraints
          for some types of logging records (e.g. near-real time for monitoring
          and analytics applications). 

This would allow some more freedom to have a non file-based solution, if needed.


- Acknowledgment

Phil Eardly -> Phil Eardley

[Ballot discuss]
GEN-5 and GEN-6 levy HTTP requirements on the UA - don't you also need to levy requirements on TLS to the UA in s9? If you're requiring HTTP to the UA what else are you going to realistically use other than TLS?

Because the UA is kind of in scope now is access control included as well - or is that part of authentication?

[Ballot discuss]
GEN-5 and GEN-6 levy HTTP requirements on the UA - don't you also need to levy requirements on TLS to the UA in s9? If you're requiring HTTP to the UA what else are you going to realistically use other than TLS?

Because the UA is kind of in scope now is access control included as well - or is that part of authentication?  Assuming SEC-1 also applies to the UA are you going to allow HTTP-Basic or HTTP-Digest?

[Ballot discuss]
I have no objection to the publication of this document, but there is a
small issue I'd like you to look at before I change by ballot to No
Objection.

---

I think [I-D.ietf-cdni-framework] is a normative reference as you rely
on it for terminology.

But there has to be some concern about Section 2. You are quoting for
convenience, but what happens when/if the text in
[I-D.ietf-cdni-framework] is changed?  That could easily happen because
that document is not out of the WG yet.

[Ballot comment]
I couldn't help being puzzled by the very first sentence.

  Content Delivery Networks (CDNs) are frequently used for content
  delivery.

What else would a CDN be used for? It is like "IP Networks are
frequently used for exchanging IP packets."

I think you mean something very different...

  Content delivery is frequently provided by specifically architected
  and provisioned Content Delivery Networks (CDNs).

---

I was surprised that the priority scheme you have applied to the
requirements says nothing about the importance of the functions to
CDNI. I don't object to what you have done and can see that this is
what the WG finds useful, but it just seems odd to me that "we already
know we can do it" is a higher priority than "CDNI will be pointless
unless we do it."

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-cdni-requirements-12, which is currently
in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA
Actions that need completion.  IANA requests that the IANA
Considerations section of the document remain in place upon
publication.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Content Distribution Network Interconnection (CDNI) Requirements) to Informational RFC


The IESG has received a request from the Content Delivery Networks
Interconnection WG (cdni) to consider the following document:
- 'Content Distribution Network Interconnection (CDNI) Requirements'
  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 2013-11-26. 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 frequently used for content
  delivery.  As a result of significant growth in content delivered
  over IP networks, existing CDN providers are scaling up their
  infrastructure.  Many Network Service Providers and Enterprise
  Service Providers are also deploying their own CDNs.  To deliver
  contents from the Content Service Provider (CSP) to end users, the
  contents may traverse across multiple CDNs.  This creates a need for
  interconnecting (previously) standalone CDNs so that they can
  collectively act as a single delivery platform from the CSP to the
  end users.

  The goal of the present document is to outline the requirements for
  the solution and interfaces to be specified by the CDNI working
  group.




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

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


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

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