Skip to main content

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

Yes

(Barry Leiba)

No Objection

(Alia Atlas)
(Alvaro Retana)
(Brian Haberman)
(Deborah Brungard)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Spencer Dawkins)

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

Alexey Melnikov Former IESG member
Yes
Yes (2016-05-19) Unknown
Thank you for addressing my earlier comments!
Barry Leiba Former IESG member
Yes
Yes (for -11) Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Alissa Cooper Former IESG member
(was Discuss) No Objection
No Objection (2016-04-29 for -13) Unknown
Thanks for addressing my comments.
Alvaro Retana Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Ben Campbell Former IESG member
(was Discuss) No Objection
No Objection (2016-05-19) Unknown
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?
Brian Haberman Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Deborah Brungard Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (2016-01-06 for -11) Unknown
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.
Martin Stiemerling Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2016-01-07 for -11) Unknown
- 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.