Content Delivery Network Interconnection (CDNI) Control Interface / Triggers
draft-ietf-cdni-control-triggers-15

Note: This ballot was opened for revision 11 and is now closed.

Barry Leiba Yes

Alexey Melnikov Yes

Comment (2016-05-19)
No email
send info
Thank you for addressing my earlier comments!

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Ben Campbell) (was Discuss) No Objection

Comment (2016-05-19)
No email
send info
Thanks for handling my DISCUSS point related to the TLS requirement.  I had one remaining DISCUSS point that I am not sure has been resolved--but after the conversation that did happen, it is probably no longer DISCUSS-worthy:

- 4.7, 2nd bullet under handling of offline surrogates:

I assume I am missing something here. How does a surrogate know that the situation exists in the first place? How would a surrogate know about invalidate commands that happened while it was offline?
-------------

 The remaining comments are old. I think they've mostly been addressed, but did not recheck them:

- 3, paragraph 5:
SHOULD should not be equated with "optional to implement". MAY means that. SHOULD is intended to be stronger.

- 4.5, 2nd paragraph, 1st sentence:
This is pretty convoluted. I suggest reformulating without the past tense "MUST". For example, "The dCNI MUST report the expiration times if..."

-4.6: "If CDNs B and C delegate delivery of CDN A’s content to each other"
Is this a reasonable configuration? It seems like they might already have a delegation loop before the trigger interface got involved.
Also, the first sentence is a fragment.

= 4.8, first paragraph:
I suggest s/transform/"similarly transform"

- 5.1.3, staleresourcetime, mandatory:
Doesn't this effectively mean the value must be the same across all collections? 

- 5.2.1, content.ccid:
Seems like the reference to [I-D.ietf-cdni-metadata] should be normative.

- 6.2.5:
it looks like the dCDN is sending the request to itself. Is that the intent?

- 8.1, last paragraph: "In this case, the dCDN MUST allow each uCDN from which the content could have been acquired to act upon that content using CI/T Commands."
This seems like a place where local policy might reasonably vary. Is a MUST really appropriate?

Alissa Cooper (was Discuss) No Objection

Comment (2016-04-29 for -13)
No email
send info
Thanks for addressing my comments.

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (2016-01-07 for -11)
No email
send info
- I agree with the discuss points about use of TLS.

- I think it'd be better if you clarified that by
"mutually authenticated" you mean TLS client auth and
TLS server auth and not e.g. HTTP BASIC plus TLS server
auth.

- I think a statement to the effect that the mechanisms
for access control are dCDN-specific (for now at least)
might be a good addition. I'm guessing that someone
might want to use some form of OAuth later on (or is
doing so now) so part(s) of that might be a thing to
standardise later.

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

(Kathleen Moriarty) No Objection

Comment (2016-01-06 for -11)
No email
send info
I'm a no objection, but do want to see why TLS is not a MUST.  I've responded to Ben's discuss that proposes language to make it clear whether or not TLS is a MUST.  Right now, I think it is just a MUST when certain conditions are met - the need for the security properties called out in 8.1 and commercial privacy considerations in 8.3.

Alvaro Retana No Objection

(Martin Stiemerling) No Objection