CDNI Working Group Minutes IETF-93, Prague, Czech Republic - Chaired by Francois Le Faucheur and Daryl Malas - Meeting notes captured by Kevin and Rich Salz, edited by Francois Le Faucheur - Audio Recording at: https://www.ietf.org/audio/ietf93/ietf93-karlini_ii-20150720-1300.mp3 - Slides accessible at: http://www.ietf.org/proceedings/93/cdni.html Monday, July 20, 2015, 13:00-15:00, Karlin I/II =================================================== - about 60 people in the room, plus 5 on MeetEcho Introduction and Agenda (WG chairs) --------------------------------------------------------------- - Introduction by the WG chairs, and Note Well statement. - Barry Leiba (AD): The “Note Well” statement applies to participation (any form of participation), but does not apply if just sitting - Agenda review, no request to change agenda - No New Published RFCs (since previous IETF meeting) - Document Update and progress against the charter milestones * cdni-logging: in “IESG Review.” Received comments, most addressed, the one significant remaining open item is Privacy. * cdni-metadata: Ready for WG Last Call, once the MIME type discussion is resolved and JSON expert review comments are addressed. * cdni-redirection: Security text aligned, Privacy discussion added. Ready to move to IESG review ? * cdni-control-triggers: JSON expert review comments addressed, security text aligned, privacy text added. Ready for IESG review ? * cdni-footprint-capabilities-semantics: Semantics I-D ready for WG Last Call once MIME Type discussion is resolved. * cdni-uri-signing: WG made a decision in Dallas to include support for segmented content in same I-D. Liaison was sent to MPEG to notify them of that decision (and respond to their earlier Liaison). As announced by Ray, an IPR statement has been issued (http://datatracker.ietf.org/ipr/2603/) that needs to be discussed by WG. - Documents beyond the charter: * CDNI rate pacing: not revved up, waiting on other interfaces specs to solidify * CDNI handling of HTTPS Delegation: Problem raised and discussed in Dallas, 2 Internet-Drafts submitted for IETF-93 that will be discussed today. CDNI Logging, draft-ietf-cdni-logging-19: Iuniana Oprescu --------------------------------------------------------- - Iuniana: update on ABNF, updated security text re TLS as agreed in Dallas, Text about order, dependency, sanitization; added examples. - Francois: Discussion with IESG regarding handling of privacy in logging draft. IESG wants better guidance to make cdni logging more privacy-friendly. Meeting between IESG and I-D authors at lunch time just before this meeting. Agreement to put together a Design Team to assess what is achievable in what timeframes and recommend how to proceed. WG will decide plan of action based on these assessment and recommendations. This “Logging Privacy” Design Team will comprise folks with CDNI expertise + folks with Privacy/Security expertise (designated by Stephen Farrell). - Francois: Log aggregation suggest by Stephen Farrell as one approach that could solve aggregation. One drawback is that it considerably reduces the ability to do fine-grain analytics/monitoring/reporting. There are 2 forms of log aggregation: 1) collapse of all segments log (in HTTP Adaptive streaming) into a single log entry for the entire movie; and 2) aggregate something like delivery of one content to 1000 users into a single log entry. Stephen Farrell is thinking about the latter wrt privacy. 1) has been discussed a lot at the beginning of the WG and explicitly kept for fuser study as it is tricky and we needed a simple solution quickly first. - Francois: Is there WG interest in working on aggregated logging? - WG: Noone expresses interest. - Ben Niven-Jenkins: Is aggregation just for privacy? - Francois: Aggregation is both for privacy and to make logs smaller - Ben: Client issues a request to the uCDN in the first place; if uCDN subcontracted to dCDN, uCDN still gets logs, and there is no privacy issue. - Jon Peterson: Aggregation does not necessarily solve privacy issues; need to define privacy issues first before it can be solved. - Design Team volunteer in CDNI WG: Kevin Ma, Ray van Brandenburg, Inuiana Oprescu and Francois Le Faucheur. - Design Team target: make recommendations within 4 weeks of Design Team being formed (i.e. when privacy/security experts are on-board) Also anonymization, e.g., of IP addresses such as rfc 6235. Goal is 4weeks to come up with the estimate. Volunteers include Ray and Kevin. CDNI Metadata, draft-ietf-cdni-metadata-10: Ben Niven-Jenkins ------------------------------------------------------------ - Ben: Feedback from Apps Directorate review; lots of comments, nothing seem hugely major. About half-done. - Ben: Need to double-check to see it meets the consensus for security considerations (logging draft is the best statement thereof) - Francois: I will review the security considerations section and give guidance - Ben: target to issue a new rev of draft by mid-september - Barry Leiba: why so many media types, instead of one parameterized? - Ben: glad to have input; discussion, see below. - Barry: New media types are cumbersome; need CDNI review not media type review. Single media type seems like a more sensible way to go. - Jan Seedorf: Media type discussion coming up with FCI discussion. Would want a media type expert to help. FCI Documents: Jan Seedorf draft-ietf-cdni-footprint-capabilities-semantics-06 draft-ma-cdni-capabilities-07 draft-seedorf-cdni-request-routing-alto-06 ------------------------------------------------------------------------------- - Jan: FCI/Metadata had a registry, Metadata switched to mime types, FCI switched to mime type as well. Meeting on Wednesday at 1pm to talk about registry vs mime type - Jon: Can we solve the mime type vs registry issues here and now? 1. register mime types 2. create a single mime type and use subtypes 3. create a registry for CDNI types - Barry: they are called “media types”, not “mime types” - suggests parameter for object type, with CDNI controlled registry of object types, with CDNI experts reviewing. - Ben: Don't think we need that much oversight, but will go with group consensus. - Barry: Having media type experts review CDNI object types doesn't make sense. - Jon: Can make the expert review easy to pass; e.g. have Ben rubber stamp all requests. - Francois: Would it be useful to define two policies ? - Jon: Not justified to have two policies; just have one. - Ben: Just use one policy. - Barry: Specification required is probably good enough, with light oversight suggested to the designated expert. - Jon: Doesn't “specification required” only require a specification? - Barry: Expert checks that the spec is suitable for interop. - Jon: Prefers expert review. - Francois: Everyone seems ok with single media type. Does anyone object to that? - WG: Noone objects - Jan: So we have concensus - use Wednesday meeting to work out details. Routing Request Redirection for CDN Interconnection, draft-ietf-cdni-redirection-10: Ray van Brandenburg -------------------------------------------------------------------------------------------------- — Ray van Brandenburg: Redirection Draft Update - AppsDir comments - Ray: Privacy - dCDN can learn client IP without serving content. Text says users of the RI can mask IP before sending the request. No comment from the room - Francois: RI works for subnets; and the delegated request will come to the dCDN anyway so it will see the full IP address - Jon: wrt HTTPS, RI discusses HTTP redirections well, but not DNS redirection (problems noted by HTTPS use case drafts). - Francois: Good point, Ray to reflect this in next update and then we can submit to IESG (once Media-type conclusion is reflected) CDNI Control Interface, draft-ietf-cdni-triggers-08: Rob Murray ------------------------------------------------------- - Rob: addressed Appsdir review comments, addressed comments from Francois (aligned TLS text + added privacy section). No known issue - Rob: where will the single Media Type be defined. - Ben: it can be defined in metadata I-D and other CDNI spec refer to that. - Francois: Media Type decision needs to be reflected in next rev of cdni-triggers. After that, document can go to IESG review. CDNI URI Signing, draft-ietf-cdni-uri-signing-04: Ray van Brandenburg ------------------------------------------------------------- Ray: URI Signing IPR discussion Francois: IPR disclosure only applies to segmented content (that was added according to Dallas decision, following MPEG DASH liaison) Daryl: Segmented content not strictly required to meet the CDNI WG requirements (segmented content is for “phase 2”); MPEG asked us to pursue segmented content. Jon: Did we get a liaison statement asking us to add content to URI signing? Francois/Daryl: We got a liaison statement saying it would be useful and the working group decided to do the work. Francois: presented key aspects of http://datatracker.ietf.org/ipr/2603/ including the fact that the licensing declaration mentions “possible royalties/fees” Francois: Options: 1. publish as is 2. split into two documents: segmented (stays WG document) vs non-segmented (individual I-D) 3. change the solution to no longer be IPR encumbered 4. drop the IPR encumbered segmented content altogether Kent Leung: Options 2 and 4 are essentially the same? Francois: With option 4, the working group drops work on segmented content all together. Jon: Does the working group care about segmented content. Why not just option 4? Francois: Solution is not just for MPEG; working group wanted to solve the problem if possible. Jon: If we care about segmented content, do option 2, else do option 4. Kevin: The work is done; not sure why we would't do option 2. Kent: Option 3 is probably not feasible (i.e. difficult to reliably circumvent IPR). Preference for option 2. Phillip Sorber: I like option 3. Segmented content is important; worth looking at the IPR to see if we can get around it. Francois (as an individual): I vote for Option 2. No reason to drop the work. Option 2 does not preclude changing the solution to not be IPR encumbered if we realise we can do that later. Francois: Would Phillip volunteer to look into a non-IPR-encumbered solution? Phillip: yes Rick Salz: Go for option 1 but make segmented content support optional. Iuniana: I recommend Option 2 and Option 3. Separate and try to un-IPR-encumber. Daryl: Separate charter requirement for segmented content URI Signing. Jon: Move to a separate document (option 2). Daryl (as an individual): Option 2. Barry: There seems to be a strong consensus for Option 2. Ask who can't live with option 2. Francois: Hum if uncomfortable with option 2. no one hummed. Daryl: Ray to submit segmented content work as an individual draft, and reissue draft-ietf-cdni-uri-signing without the segmented content support. Kent: What is the next step for the WG draft? Revert, then what? Daryl: Revert and do an in-depth review. Leif Hedstrom: volunteered to do the URI Signing in-depth review. HTTPS and delegation of encrypted traffic, draft-fieau-https-delivery-delegation-00: Iuniana Oprescu -------------------------------------------------------------------- Iuniana: Redirection methods, Need clarification on manifest rewrite issues, Need to consider DNS redirection issues and topology hiding, DNSSEC HTTPS and delegation of encrypted traffic, draft-slovetskiy-cdni-https-delegation-approaches-00: Sergey Slovetsky -------------------------------------------------------------------- Sergey: HTTP->HTTPS works, but not secure; HTTPS->HTTPS works, but may not be secure ; DNS HTTPS redirect doesn't work Daryl: We agreed to discuss in Dallas; so let’s assume we want to work on that and discuss the details of the two drafts. Can authors combine their drafts? Jon: What does DANE and the token give beyond DNSSEC Sergey: ? Jon: Not sure what the token buys. Ben: What is the use case that is solved by the solution? Is it the redirection that doesn't work? Is it a desire to not have to share keys? you shoudl describe the high level problem you are solving (e.g. is it redirection that does not work? or is it that CDNs d not want to share keys?) Sergey: It kind of works; but do we need something stronger? Jon: What extra security does the token provide over redirect over TLS? Iuniana: HTTP redirect works; DNS is the problem Daryl: When issuing new rev of draft, clearly identify the perceived problem and then define the solution to address that problem. Jon: This is about redirection; so make sur the redirection document mentions the limitations of current support. Meeting closes --------------