Re: [CDNi] New version (and IPR statement) of draft-brandenburg-cdni-uri-signing-for-has

[Kevin Ma J <[e-mail]>]

Hi Ray,

  (As an individual) I finally found some time to read through the updated draft.  Some comments and questions below.

thanx!

--  Kevin J. Ma

- section 4.1, step 3.E: What if the user pauses, or there is an ad inserted, and the token expires?  Understood that it's probably up to the media player to handle that case, but would they need to go back to the CP to get a new valid manifest URL?  Which would have a token that is valid for the chunks as well?

- section 4.1, steps 9, 11.B, 11.E, 12.B, and 12.F, section 7.1 step 1, section 7.2 steps 3.A.d and 3.B.d, and section 7.4 steps 10.A.2, 10.A.5, 10.B.2, and 10.B.6: Should the UPC be percent-encoded?  And should CIP be encrypted?

- section 4.1, steps 9, 11.B, 11.E, 12.B, 12.F, section 5.2, and section 7.1 step 1: If the token is only good for segments, but is attached to the manifest request, does that mean that there is no signature validation on the manifest request?  In the 2xx non-redirect case, would you expect a v1 manifest signature be in the query string and a separate v2 chunk signature be in the cookie?

- section 4.1, step 10, sections 5/6, and section 7.4 step 9: Seems like a chicken and egg problem.  The STT says that the token is in the cookie, but the STT is in the token that's inside the cookie.  Does the initial token always have to be in a token?  Should the initial token always be in the query string to be compatible with v1, since the VER=2 is also inside the token inside the cookie?  From the client perspective, should only subsequent tokens be in the cookie?  From the CDN perspective, unless passed in the metadata, how will the CDN know where to look for the token, or does it always check everywhere?  If the process is to always check the query string first and the cookie second, do we even need STT?  New STT values are going to require and update to the procedure in section 6, as well as registration of new STT values?

- section 5.2: The v1 draft also supports token as a path parameter; is that intentionally omitted here?


- section 7.1 steps 2 and 3: I would expect that v2 would have a new GenericMetadata ptype (MI.UriSigning.v2?) and that ptype would tell the dCDN what it should expect in the token?  It would be nice if the draft could define v2 such that it supported both VER=1 and VER=2, so that the MI.UriSigning.v2 metadata could be a superset of information needed to process all known token types, and make the token processing a runtime decision?

- section 7.4, general: This draft removes the "Note that re-signing a URI MUST..." text from the v1 draft(section 3.1).  Since this is about resigning, I think the text about maintaning the same values should be added here, specifically for KID/KID_NUM, HMAC, and DSA.


- Do you have an idea as to what additional registries, metadata, and/or logging fields will be needed?  Will the new ptype just be MI.UriSigning.v2?


From: CDNi [mailto:[e-mail]] On Behalf Of Brandenburg, R. (Ray) van
Sent: Friday, June 10, 2016 11:34 AM
To: [e-mail]
Subject: [CDNi] New version (and IPR statement) of draft-brandenburg-cdni-uri-signing-for-has

Hi all,

As you might have seen, I’ve recently uploaded a new version of draft-brandenburg-cdni-uri-signing-for-has (-03).

https://tools.ietf.org/html/draft-brandenburg-cdni-uri-signing-for-has-03

What is important to note is that KPN has updated it’s IPR statement on this document to be in line with the IPR statements that have been filed on other CDNI documents (i.e. “Royalty-Free, Reasonable and Non-Discriminatory License to All Implementers”). Hopefully this clears up the lengthy IPR discussion we’ve been having around this document so that we can focus on the technical aspects again.

Looking forward to your feedback,
Ray

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.