CDNI Working Group Minutes IETF-92, Dallas, TX - Chaired by Francois Le Faucheur and Daryl Malas - Meeting notes captured by Jan Seedorf and Ray van Brandenburg - Audio Recording at: https://www.ietf.org/audio/ietf92/ietf92-fareast-20150325-1300-pm1.mp3 - Slides accessible at: http://www.ietf.org/proceedings/92/cdni.html Wednesday, March 25, 2015, 13:00-15:00, Far East =================================================== - about 40 people in the room, plus 16 on MeetEcho Introduction and Agenda (WG chairs) --------------------------------------------------------------- - Introduction by the WG chairs, and Note Well statement. - Agenda review, no request to change agenda - No New Published RFCs (since Honolulu meeting) - Document Update and progress against the charter milestones * cdni-logging: in “IESG Review.” Received comments, most addressed, but still open items. * cdni-metadata: Independent/author reviews, comments addressed. Cover-to-cover review and clean-up by authors. Ready for WGLC ? * cdni-redirection: Independent reviews conducted and comments addressed. Completed WGLC. Ready for IESG review? * cdni-control-triggers: Completed WGLC. Comments addressed. Ready for IESG review? * cdni-footprint-capabilities-semantics: Ready for WGLC? * cdni-uri-signing: Waiting for discussion on MPEG Liaison. WG needs to make a decision on whether the URI Signing draft needs to support segmented content. CDNI Logging, draft-ietf-cdni-logging-17: Francois Le Faucheur --------------------------------------------------------- - Number of new revisions since Honolulu to deal with IESG comments. - Currently a few IESG comments left, but expected to finish relatively soon now. - Francois presenting slides on changes since -15. Lots of changes. - Francois: Quite some discussion on use of TLS. This is not specific for CDNI Logging, but applies to other CDNI interfaces as well. - Francois: Converged on referencing I-D.ietf-uta-tls-bcp instead of trying to come up with own TLS profile. Although current UTA guidelines are meant for existing protocols instead of new ones, the current guidelines are the best we have. - Jon Peterson: If you use a ‘SHOULD’, you should add when you shouldn’t. If you don’t, maybe you should use a MUST - Francois: During IESG discussion it became apparent that even if you use VPN/IPsec/…, you might as well use TLS as well. Little overhead, so we can make it MUST - ?: There can be conditions in which there are valid reasons for someone not wanting to use TLS. I believe a SHOULD is safer than a MUST - Spencer Dawkins (as Individual) : The way I understand the current text wrt UTA reference is that people should read UTA, with the UTA spec describing the corner cases. In that sense, you could make it a MUST - Jon Peterson: Don’t agree with ‘?’, a SHOULD is not necessarily safer. If you use a SHOULD, you need to explain when you SHOULD NOT - Shahid Akhtar: The amount of logs you generate in a CDN is a lot. Encrypting all those logs add significantly to the hardware/processing requirements. If you have a secure network between two networks, you should be able to send the logs in plain text. - Daryl (Chair): there are two aspects in the discussion that need to be distinguished: (i) Use of TLS (Should or Must) and (ii) Follow UTA when you use TLS. - Jon: Nobody is saying that you MUST use TLS. The current text just says that you MUST use something secure, you SHOULD use TLS, and if you do, you SHOULD do it according to UTA. The question is now if the last SHOULD should be a MUST. - Francois: Ok, so we agree that only the ‘SHOULD follow UTA’ will be changed into a MUST. This does not mean that you MUST use TLS (i.e. first paragraph stays unchanged). - Francois: Also quite some discussion on making anonymization mandatory. Except in some very specific debugging cases, you almost never need the full client IP. So draft now makes anonymization a SHOULD while allowing for these specific exceptions. - Bhumip Khasnabish: Is there a way to prevent a specific Logging Record to appear multiple times in the logging file? - Daryl: That is not part of the CDNI requirements - Francois: In theory, dCDN could event invent complete logs. That is not something we try to prevent, is a business issue. - Next steps: Fix remaining IESG issues (primarily ABNF). Changes will be presented on list . CDNI Metadata, draft-ietf-cdni-metadata-09: Ben Niven-Jenkins (remotely) ---------------------------------------------------- - Ben: Addressed comments from independent reviews. In addition, authors did cover-to-cover review. - Ben presenting slides on changes since Hawaii - Jan Seedorf: Regarding MIME types. Does this impact the Footprint & Capabilities Semantics drafts? You seem to have added additional media types and removed the registry. - Ben: Correct, we removed the Generic Metadata Type Registry - Jon Peterson: Why is it preferable for a MIME ‘Doctor’ to review new types, instead of requiring CDNI experts. MIME Doctor doesn’t have domain expertise. - Ben: There is no benefit. The question is more do we need a registry at all? People can come up with new types without having a registry. - Jon: Yes, but vetting can be beneficial. You want someone who understands CDNI semantics to evaluate metadata proposals. - Ben: Let’s take this offline. I agree evaluation might be good, I’m not sure we need a registry. - Jon: In general, I think the whole metadata architecture behind this is getting too complicated between this document, the Footprint Semantics docs, etc. There is a cascading effect. If we change this, this has an impact on the other docs. - Jan: The spec is technically correct, it’s not wrong, but there is definitely an impact. Bigger issue is the question whether we need to formalize an oversight process for new metadata types. - Ben: I’m happy to discuss that. - Francois (as chair): I think we agree that we need to discuss possibilities for oversight. Across this document and the footprint documents. - Jon: I think we need help from the Applications area regarding the interworking between this and HTTP. Let’s take this offline. - Ben takes an action to continue this discussion on the list - Bhumip: Is de-duplication part of this specification? - Ben: No. - Next steps (Francois): Let’s make some progress on the MIME type discussion. After that is resolved (and the JSON expert review comments are addressed), we can go to WGLC. FCI Documents: Jan Seedorf draft-ietf-cdni-footprint-capabilities-semantics-06 draft-ma-cdni-capabilities-07 draft-seedorf-cdni-request-routing-alto-06 ------------------------------------------------------------------------------- - Three documents: One document describing semantics, two others describing both ALTO and HTTP transport - Jan Seedorf presenting slides with changes in Semantics draft (-06) since Hawaii. - Jan: Main issue relates to MIME discussion in Metadata draft (see above) - Jan: Once MIME-types discussion reaches an agreement, I think semantics draft is ready for WGLC. - Chair: Agreed. Once MIME-types discussion reaches an agreement and reflected in new rev, we can go to WGLC. - Jan Seedorf presenting slides with changes in F&C HTTP Transport draft since Hawaii - Jan Seedorf presenting slides with changes in F&C ALTO Transport draft since Hawaii Routing Request Redirection for CDN Interconnection, draft-ietf-cdni-redirection-09: Ray van Brandenburg ------------------------------------------------------- — Completed WGLC. - Ray presented the latest changes, no comments / discussion - Francois reminded the WG to think about the privacy comments raised by the IESG during their review of cdni-logging and encouraged document authors to consider privacy considerations and write some text about it - Ray: there is a statement about the fact that the full IP address is passed, but that is a necessary evil - Francois: One could argue that it may be sufficient to pass a partially masked IP address - Ray: that is true and should work. I will think about that. But in any case, the dCDN will eventually serve the request and will get it from the client with its full IP address, so was it worth hiding it in the cdmi-redirection interaction? - Francois: that is a good argument and should be presented in the draft - Chair : we will proceed to IESG review after update to (i) align with latest TLS usage conclusions (see cdni-logging) , (ii) address comments from upcoming JSON expert review and (iii) add/check statements about privacy. - Ray: since cdni interface are between CDNs and not endusers, and what people care about is user privacy, do we really need much in terms of privacy in the CDNI interfaces (other than logging which can potentially carry a lot of enduser information). - Francois (Chair): the bottom line is that each interface needs to consider its relevant privacy concerns (or lack thereof) and should explain what measure sit takes or does not take. - Francois (Chair): is anyone not comfortable with moving to IESG review once the discussed changed are made? - Noone express being not comfortable. CDNI Control Interface, draft-ietf-cdni-triggers-06: Rob Murray ------------------------------------------------------- - Rob presented on triggers draft and latest changes, doc is ready for IESG review, no comments / discussion - Francois: we will proceed to IESG review after update to (i) align with latest TLS usage conclusions (see cdni-logging) , (ii) address comments from upcoming JSON expert review and (iii) add/check statements about privacy. CDNI URI Signing, draft-ietf-cdni-uri-signing-03: Ray van Brandenburg ------------------------------------------------------------- - Ray presented - Discussed liaison with MPEG and how to proceed with this - Presented possible solutions to handle requests from DASH, ends by asking several questions to the WG how to proceed (see slides) - Craig Taylor (via Meetecho): the approach would require CORS support. - Ray: Yes, that’s correct. - Daryl (as WG chair): is there a risk if we don’t solve the problem of segmented content, is there a risk that MPEG DASH tries to solve this problem themselves? - Ray: yes there is such a risk. - Daryl (as individual): we should address DASH segmented content so we have a single solution across non-segmented and segmented content - Iuniana: we should definitely address DASH segmented content, you’ve done most of the work already. Slight preference for Header approach, but understand Cookie approach is attractive for immediate solution. - Jan: we definitely should consider solving this problem. MPEG DASH is very important traffic. - Francois (as individual): We should only not do it if we realise we cannot do it for some reason. URI singing has applicability for CDNs independently of CDNI, so it is very useful for industry to have a URI signing solution that covers both non-segmented and segmented/DASH content. Please address this problem. - Kent Leung: I support doing that work. - X : there is a requirement for CDNI to support segmented content and there is a growing DASH traffic, so I support developing a solution for URI signing to support segmented content. - Francois (chair): with respect to Ray’s 2nd question (i.e. should it be in existing URI signing document or separate document?), I believe it should be in same document. I believe people who commented before also expected that, but please say so if this is not correct. - Francois : Regarding Ray’s third question: Ray described a general approach and then two specific variants. I believe the general approach is valid. With respect to the two variants, I would recommend we support the two: Cookie approach because it works with existing clients, Header approach because it is cleaner for long run. - Kent: there was a thread on that. I also support developing both, for reasons Francois mentioned. - Francois: for Cookie approach, you don’t need new protocol elements. For Header approach, do you need IETF to define a new Header? - Ray: Yes. you could either specific the Header in MPEG or in IETF. Probably best if developed jointly. - Francois (chair): Take this into account because it will inevitably require time to have this Header standardised, so you may want to define it separately from the Cookie approach that could be closed faster. - Daryl (Chair): we will respond to MPEG liaison, so they know we will be working out a solution. - Francois (Chair): question to AD Spencer: should we get an early Security Review? - Spencer: Yes, let’s trigger an early review, using the regular review process (using alias for request review) - Francois: Chairs will request early Security review. - Authors to rev up with solution for segmented DASH content. HTTPS and delegation of encrypted traffic between interconnected CDNs: Iuniana Oprescu -------------------------------------------------------------------- (New item - not a working group item) - Iuniana presented - Presented the problems with delegation of https traffic and possible solutions - Francois (chair): first question is: is this a useful problem to solve? As an individual I think it is. - Jan: Yes, it is useful. There is growing HTTPS traffic. - Ray: Agree it is a useful problem. - Jon: Yes, it is useful. You should do it with redirection, like Jan said. - Francois (Chair): it seems we have agreement it is useful. So lets’ discuss next step. Let the interested people work together on a draft detailing problem and approaches. Once we understand level of interest and approaches, we can decide if WG takes it on. - Daryl (chair): We can conclude that there is interest. Reiterate next step: write an internet-draft, before reach out to the list to invite interested people to participate in writing of that I-D, have I-D discuss problems and potentials solutions. Meeting closes --------------