CDNI Working Group Minutes IETF-89, London, UK - Chaired by Francois Le Faucheur and Daryl Malas - Meeting notes captured by Ray Van Brandenburg, edited by Francois Le Faucheur & Daryl Malas - Audio Recording at : http://www.ietf.org/audio/ietf89/ietf89-parksuite-20140306-1300-pm1.mp3 - Slides accessible at: https://datatracker.ietf.org/meeting/88/materials.html#wg-cdni Thursday, March 6, 2014, 13:00-15:00, Park Suite =================================================== - about 50 people in the room, 1 person on WebEx, no jabber scribe Introduction and Agenda (WG chairs) --------------------------------------------------------------- - Introduction by the WG chairs, and Note Well statement. - Agenda review, no request to change agenda - Published RFCs: * RFC 6707: CDNI Problem Statement (Informational) * RFC 6707: CDNI Use Cases (Informational) * RFC 6983 : Models for HTTP-Adaptive-Streaming- Aware CDNI (Informational/Independent Submission) - Document Update and progress against the charter milestones * cdni-requirements: in “RFC Editor Queue” state, held by normative ref to cdni-framework * cdni-framework: under IESG review, first comments received, Ray and Larry to address IESG review comments * cdni-redirection: Chairs have appointed an additional Editor (Ray van Brandenburg) to assist * other documents to be discussed in rest of the WG meeting - Documents beyond the charter: * cdni-rate-pacing: see discussion below CDNI Metadata, draft-ietf-cdni-metadata-06: Kevin Ma ---------------------------------------------------- - Document ready from authors viewpoint - already addresses detailed review by Vijay Gurbani - Francois Le Faucheur is doing Chair Review (comments on first half of the document already posted) - Ben Niven-Jenkins indicated he has a few remaining comments that he will pass along. - Next Steps: * authors to issue new rev addressing Chair Review + Ben’s comments * Chairs will issue a WG Last Call on that new rev on the list - Dayrl: anyone has concern about these next steps? —> noone expresses concerns CDNI Logging, draft-ietf-cdni-logging-10: Iuniana Oprescu --------------------------------------------------------- - Presenting changes since version -08 (now at -10) - Specifically mentions improved Privacy section Jan Seedorf: Is it just mentioning privacy concerns, or are there any changes to the draft? Are there any specific measures? Francois le F.: Yes, it describes specific measures such as anonymization and “filtered uris” to deal with privacy concerns. In addition provides recommendations on how to use and limitations. Jon Peterson: Draft currently says ‘SHOULD use TLS’. Is there any good reason not to make that a MUST? If not, add comment in which cases you would’t use TLS. Jan S.: You can also say must use TLS, and use perfect forward secrecy. Kent Leung: If it is going through TLS, you might not need anonymization? Kevin M: anonymization is useful anyway to protect on the receiving side (independently of transport protection). Kevin M: I like having the choice, e.g. if you’re using IPsec, you might not need TLS. Iuniana Oprescu: the document already identifies a few situations (e.g. in private nework secured by VPN) where you may not need to use TLS. Francois le F.: Right, so I think current wording (SHOULD) is ok. Jan S.: How about: if you’re using TLS, you MUST use perfect forward secrecy Jon P.: I’m ok with SHOULD, although need to clean up wording because examples of where you may not use TLS are discussed in a different place than where the SHOULD is stated. Spencer Dawkins: IESG currently looking at cipher suites and perfect forward secrecy. No formal decision yet about whether specifying cipher suites is mandatory for drafts. Jan S.: Once IESG is done, I’m willing to help with updating draft to reflect outcome. Rob Murray: Will we have the same discussion for other interfaces as well? Maybe have transport in separate draft? Daryl M.: Don’t think that’s a good idea. Jan, could you help with recommendation while we wait for IESG (i.e. send proposed text for that to authors)? Jan S.: Ok. Spencer D.: Most important thing right now is that you’ve thought about it. Fact that we’re having this discussion is a good sign. - Iuniana: In next rev, add statement about applicability of current logging format to cases where content is delivered over HTTP2.0 and/or HTTPS (as detail don slide). Although you might want to log additional info in those cases, not going to do that in this draft. Francois le F.: Does everybody agree with that approach for HTTP2.0 and/or HTTPS ? (No comments to the contrary) - Next Steps: * authors to issue new rev addressing : o “SHOULD” editing + Jan cypher suite recommendation o applicability to HTTP2.0 and/or HTTPS * Chairs will issue a WG Last Call on that new rev on the list FCI Semantics, draft-ietf-cdni-footprint-capabilities-semantics-02: Jan Seedorf ------------------------------------------------------------------------------- - Draft defines FCI semantics, updated version includes IANA registries. - Explains details of IANA registries Kevin Ma: We still need to add capabilities for optional logging and (if any) for optional metadata fields. Jan Seedorf: Yes, after that we’re done. Francois Le Faucheur: I had provided a list of optional logging capabilities, do you still have that? Kevin Ma: Yes, we have it. Daryl M.: Currently looking for somebody who would like to do a thorough review of the next revision, after that we can go to WG Last Call. (Iuniana O. is a likely volunteer) FCI candidate protocol analysis conducted by Matt Caulfield: presented by Daryl Malas on behalf of Matt ------------------------------------------------------------------------------------------------------- - Third party analysis of [draft-seedorf-cdni-request-routing-alto] and [draft-ma-cdni-capabilities] Brent Hirshman: When you say that draft-seedorf does not describe extensibility, doesn’t ALTO describe that in his specs? Jan Seedorf: Yes, ALTO describes extensibility, but draft-seedorf does not address how you would use those capabilities. - draft-seedorf depends on efforts within ALTO WG. draft-ma requires more effort in CDNI WG. Jan Seedorf: I don’t agree with conclusion on slides that Explicit Capabilities are better than inherited. Jon Peterson: Neither drafts are currently sufficiently well specified to compare their technical pros/cons. - Daryl: Both drafts well written and good starting points. WG must decide if benefits of reusing ALTO syntax and semantics outweigh the costs and dependencies. Matt recommends were focus on simple HTTP GET before attempting to solve incremental updates (if ever) FCI, candidate protocol discussion: lead by Daryl Malas ------------------------------------------------------- - Daryl Malas: Yesterday we had another informal and open meeting on FCI. Decided on a potential approach. Idea is to focus on developing a common FCI object, based on the semantics draft and Kevin’s baseline. After that, we can ask ALTO WG whether they can define a new ALTO service for this purpose. If that creates issues, we can fallback on a CDNI-specified interface. Daryl Malas (as individual): Propose to first work on FCI object. After that we start on the transport as individual draft, not as WG doc, so that we can decide whether we need to finish it here or in ALTO WG. Jon Peterson: Hard to completely decouple object and transport, will affect each other. Kevin Ma: Agree with approach. Francois Le Faucheur: can the ALTO WG chairs comment on this proposal from an ALTO WG perspective? Enrico Marocco: This wouldn’t be my first approach, but I can understand arguments. Would first like to see object definition. Defining RESTful protocol is difficult, would argue for reusing ALTO. Jon Peterson: Worst case ALTO won’t work, then we can always define something else. Work on FCI object won’t be a waste. Francois Le Faucheur (as chair): Let’s do hum test. * who agrees with this approach? —> reasonably strong hum * who disagrees with this approach? —> no hum Francois Le Faucheur (as chair): the hum supports the proposal CDNI Control - Triggers, draft-ietf-cdni-control-triggers-02: Rob Murray ------------------------------------------------------------------------ - Presenting changes since previous version - document ready from authors viewpoint (apart from formatting issues reported by Francois) - Kevin Ma volunteered to do a detailed review. - Next Steps: * Rob to issue new rev (fix formatting) * Kevin to review * Rob to address Kevin’s comments in new rev * then chairs will trigger WG Last Call Routing Request Redirection for CDN Interconnection, draft-ietf-cdni-redirection-01: Ben Niven-Jenkins ------------------------------------------------------------------------------------------------------ - No new draft since Vancouver, didn’t have time. - Ray van Brandenburg has been appointed by chairs as additional editor. He will create new version. A meeting between Ben and Ray has taken place in London so “To-Do” list and input have been passed on to Ray. - Main open issues: Defining errors & how to deal with them, more examples, dealing with scope & cacheability (overlapping scopes), security considerations, align with URI Signing draft. - Regarding overlapping scopes: Do we agree that freshness is better than longest prefix matching? Kevin Ma: Sounds reasonable, if it’s about reducing latency instead of hard commitment from dCDN Ben Niven Jenkins: Correct. We are aiming for something simple. - Regarding extensibility: We don’t expect multiple parallel extensions, so regarding extensibility we have a slightly different approach than CDNI Metadata. Francois Le Faucheur (as individual): To me it seems to make sense to have the dCDN do the signing, because it gives complete independence between uCDN and dCDN (dCDN is the one doing both the signing and the validation) Ray van Brandenburg: Don’t agree, only upside of having the dCDN do it is that you don’t have to do key exchange. On the downside, you have to make sure that things like expiration time, hash functions etc are all communicated to dCDN so it can perform signing correctly. In addition, it would mean that the uCDN and dCDN have to use the RI for every individual request. Kevin Ma: Signing in dCDN gives the dCDN the ability to use a unique key per request, but I agree that’s not worth the down sides. Francois Le Faucheur: Could you send a mail with a summary of the pros/cons of both approaches + recommendation to the list to close on that question? (Kent and/or Ray will do so) - Ben Niven Jenkins: Explains reasons for defining own errors instead of reusing draft-notthingham-http-problem Francois Le Faucheur: Could you send a mail to list with this conclusion, with a cc to Mark N.? - Ben: will do CDNI URI Signing, draft-leung-cdni-uri-signing-05: Kent Leung ------------------------------------------------------------- - Presents changes since -03 version (now at -05) - Addresses comments from Mark Nottingham regarding URI squatting. Solves it with URI Signing Package Attribute (configured via CDNI Metadata, but with default value (not registered with IANA)). - Since we now have a single URI query attribute, means that if you want to anonymise, you not only remove the Client IP but all other Information Elements as well. - Next steps: fill in Impact on CDNI Interfaces section (especially Metadata) Francois Le Faucheur: Did you have confirmation from Mark that he is happy with the result regarding URI squatting? Kent Leung: Well, discussed with him, and on remaining issue inserted some of Mark’s own words, so Yes. Daryl (as chair): This is a deliverable on our charter, but not many people have read the draft yet, so will take question for WG adoption to the list to give people time to read it. CDNI Rate Pacing, (draft-caulfield-cdni-rate-pacing-01): Francois Le Faucheur (on behalf of Matt Caulfield) ------------------------------------------------------------------------------------------------------ - Draft addresses problem of having dCDN sending content faster to Client than Client can consume it. Causes issues regarding compensation when client does not consume all of it. This draft presents a system for having uCDN tell dCDN the speed with which he needs to send content to client. - Document is not yet in charter - Next steps: Address comments from Francois, solicit additional reviews/comments - Francois notes that this draft is a good test for testing the extensibility mechanisms of the various CDNI specifications (metadata, logging,...) Francois Le Faucheur (as Chair): Proceed as individual draft for now. Rate pacing will be a candidate additional topic if/when CDNI recharters. If document is ready, it can be adopted by WG than. Meeting closes --------------