CDNI Working Group Minutes IETF-87, Berlin, Germany - Chaired by Francois Le Faucheur and Daryl Malas - Meeting raw notes captured by Rob Murray and Iuniana Oprescu, edited by Francois Le Faucheur & Daryl Malas - Slides accessible at: https://datatracker.ietf.org/meeting/87/materials.html#wg-cdni TUESDAY, July 30, 2013, 15:20-16:50, Potsdam 3 ============================================== - about 50 people in the room, a few people on WebEx, no jabber scribe Introduction and Agenda (WG chairs) --------------------------------------------------------------- - Introduction by the WG chairs, and Note Well statement. - Agenda review - Document Update and progress against the charter milestones * has: published as RFC Informational and Independent Submission * framework: will go to WG Last Call once new rev is posted * requirements: will go to AD review once new rev is posted * RI: WG doc, more progress needed * LI: significant progress since Orlando, only a few remaining issues to address * CI/Triggers: WG doc, more progress needed * FCI: significant progress on semantics (WG doc). ALTO proposal revved up. * MI: only a few remaining issues. Aim for WG Last Call once those are resolved? - WG needs to decide how to handle potential additional items (URI signing, CI/Bootstrapping) - Reminder about final interface names to be used in all WG documents. WG doc editors should update their docs as described in the slides. - Description of the "Expanded Reference Model" that shows both RI and FCI interfaces. To be included in next rev of cdni-framework. - See chair slides - jan seerdorf: reminder about informal Footprint & Capabilities meeting on Thursday - Francois Le Faucheur: reminder about informal Logging meeting on Wed **See meeting materials for additional context Framework, draft-ietf-cdni-framework-03: Matt Caulfield -------------------------------------------------------- - document is stable and does not have open issues - need to finalize text for "URI/Metadata rewrite" - "Expanded Reference Model" that shows both RI and FCI interfaces will be included in next rev of cdni-framework as per chairs slides. - no questions or comments from the room CDNI Metadata, draft-ietf-cdni-metadata-02: Matt Caulfield ---------------------------------------------------------- - Jan Seedorf - help requested from the metadata authors to extract capabilities needing advertisement via the FCI - Kevin Ma - plan is to have a registry of advertisable capabilities, Kevin has agreed to provide text in the MI draft - Ben Niven-Jenkins - the metadata draft is a framework; it defines generic objects but not specifics for HTTP, so it will not be possible to extract specific capabilities, this detail is needed for interoperability - Kevin - agreed, but we're not defining that in the FCI semantics draft - Jan/Matt - agreed to take offline to the FCI side-meeting - Ben - we should be aiming for a minimum set of properties in the draft to enable HTTP interworking (at least) - Matt - agreed, we need to make sure we have enough detail in there to enable HTTP delivery - Kevin - agreed, we haven't yet (for example) enumerated all the values for the protocol ACL - Ben - we have a generic metatadata and framework, but not enough for someone to implement the JSON messages needed for HTTP delivery without making their own assumptions - Francois - expectation is that this draft has enough in it to enable HTTP delivery - Ben - we had this detail in an earlier version but it seems to have got lost - we found when working through the HTTPS doc that we had nowhere to refer to for base HTTP properties... for example, whether auth is needed, or whether to strip query parameters when going to the origin - Matt - there are flags to cover those things - Kevin, Ben, Matt - agreed to make sure there's enough in the draft to allow base HTTP delivery before going to WG last call - Francois - use the cdni email list if there is disagreement about what exactly is needed to allow base HTTP delivery - Francois - we will need confirmation from authors that the CI spec does cover what is needed for HTTP delivery before we can consider moving to WG LAst Call Discussion on slide "Open Item: Capabilities" - there was agreement that in the metadata document we should not aim to provide specific provisioning in view of optimizing extraction of required capabilities from metadata specifically for making request-routing decisions based on such requested capabilities. Such optimization can be implementation specific. CDNI Logging, draft-ietf-cdni-logging-05: Iuniana Oprescu --------------------------------------------------------- - Francois - suggest that we recognise we are not progressing on notifications (e.g. that dCDN req routing is down etc), and leave it for now as it is a medium priority requirement and we can make progress on the base spec - Ben - agreed, if nobody cares enough to write text we should move on - Jan - agreed, in order to avoid potential conflict with capabilities interface - Ray Van Brandenburg - agreed - Francois asked whether anyone has objections - none raised - Iuniana/Francois - not planning to include a mechanism in this draft for real-time log transfer, no objections raised - Jan - request for help from LI draft authors on capabilities draft, agreed to discuss at the FCI side meeting - Francois - there has been discussion about whether log files should be stored compressed or not, especially as the server might decide to compress it after some time - question to Mark on how we should deal with that ... - Mark Nottingham - usual way is to advertise one URL then say in the content encoding whether it is compressed, alternative is to use two different URLs, but the former is more common. - Ben - does accept-encoding relate to transfer or content encoding - Mark - content encoding (end to end rather then per-hop, but the names have changed) - Mark volunteers to be point-of-contact in the httpbis WG - Ben and Francois - will work on a definition and will ask Mark to review. Redirection Interface, draft-ietf-cdni-redirection-00: Ben Niven-Jenkins ------------------------------------------------------------------------ - Francois - would like to avoid dependencies on other docs, for example uri signing is not very mature so we should not depend on it. And RI is behind schedule. In this draft would it be possible to discuss how uri signing fits, but without the detail - Ben - fine with that, although there had been previous comments suggesting that it needs to be included - Kent Leung & Ben - agree that the detail should be left to the uri-signing draft - No objections or concerns raised about that in the room Request interface for CDN Interconnection, draft-choi-cdni-req-intf-00: Taesang Choi ------------------------------------------------------------------------------------ - Leif Hedstrom - why invent a new header for the redirection rather than use something existing like 'multilink' - John Shinn - need to return multiple alternatives for redirection, multilink requires a 200 return code rather than 302, which means the alternatives cannot be supplied - Francois - we should agree on how to proceed with the document: * Approach 1: have separate documents (like URI signing) that cover all aspects of a given functionality and impacts on all interfaces (potentially include impact on request interface), OR * Approach 2: we create a specification for the request interface that aims at covering impact of all functionality on that interface - Francois - key considerations include timing/dependencies and having a single place to go for information about a functionality. As an individual strong preference for Approach 1. - Kent - agreed, better to keep it separate because it affects multiple interfaces - Kevin - agreed, keeping this in one place as a feature makes sense rather than needing to rev all the other drafts - No objections from the room - - so "redirection loop prevention in iterative mode" will remain a separate document - Francois - Should we move "redirection loop prevention in recursive mode" from the RI draft into the same document as "loop prevention in iterative mode"?   - Ben - loop prevention text for in iterative mode is as stable as the rest of the RI text, so it should not create a timing problem for the draft, and it makes sense to leave it in place to make it easier to implement.   - No objections raised. THURSDAY, August 1, 2013, 17:00-18:30, Potsdam 2 ================================================= - about 50 people in the room, a few people on WebEx, few people on jabber FCI Semantics, draft-ietf-cdni-footprint-capabilities-semantics-00: (Jan Seedorf) ------------------------------------------------------------------------------- - update after informal meeting (discussed all open issues) D Malas: Tentative resolution reached at side meeting presented. Feedback or questions on these tentative is invited - capabilities: small set of mandatory capabilities (no idea of commercial contracts/ agreements, so go with basic set) => registry for the non-mandatory logging capabilities / metadata - mandatory types of footprint: AS, country codes, IP prefixes organized as a set of constraints - there could be optional types of footprint - discussion of all open issues, feedback required - pull vs. push => no recommendation in the semantics doc, the solution protocols decide on that aspect K Ma: do not specify how to implement, but a discussion on pros/cons - transitive reachability => is the footprint conveyed if there is a transitive CDN? The protocol can give that info, but not mandatory. - business relationships => no hypothesis made whatsoever of what happens at the business level between uCDN and dCDN - does the dCDN always convey the total state to the uCDN or just partial state / increments / deltas? => let solution protocols decide that - optional capability (related to future protocol extensibility) => IANA "specification required". - mandatory capability => follow IETF normal process (Proposed Standard) - no major issues left. Editing required for the IANA section. D Malas: should we define a template for IANA registration as a separate WG milestone, instead of doing it from within the FCI semantics document? J Peterson: there are precedent for both approaches. In this case, I see no problem about defining the initial registry population within FCI semantics doc. S Dawkins: Agreed. but needs to have policy for new registrations defined in the specification D Malas: Jan, please document all of the tentative decisions from the informal meeting on the list Francois: Jan, when doing so, please indicate the tentative agreement that the semantics doc will contain initial allocation for documents that precedes its publication (e.g. potentially logging/metadata). Footprint & Capabilities Advertisement with ALTO, draft-seedorf-cdni-request-routing-alto-04: (Jan Seedorf) -------------------------------------------------------------------- - pros/cons for implementing FCI w/ ALTO costmaps. Proposal to use only networkmaps. - ALTO server = dCDN, ALTO client = uCDN - footprint advertisement is straightforward (prefixes and PIDs) - extensions to ALTO needed for country codes and AS numbers - a PID name could mean one given capability K Ma: what would this look like for any other arbitrary kind of footprint / location other than prefixes? J Seedorf: going to look into that. J Peterson: PID similar to oranges and bananas from previous discussions (abstraction layer). K Ma: list of footprints = list of strings? can create anything? J Seedorf: in principle, yes. ALTO can go beyond IP prefixes. Scott Wainer (jabber): same question E Marocco: ALTO extensible, but only thing defined so far for PID is IP prefixes. Could be string, JSON, geographical coordinates etc. F LeFaucheur: if we were to define new ALTO PID types shoudl this be done in the ALTO WG (given this is likely more generic than just for CDNI) or in CDNI WG? E Marocco: This is for ADs to decide, but as a minimum requires ALTO group review anyways. Scott Wainer (jabber) : So ALTO would have to be updated for every type of footprint? J Seedorf: correct; K Ma: PID used for capabilities, but we are saying PID is a list of different types of footprints. Can a PID be applied to another PID which is a capability? J Seedorf: multiple options. PID name= RTMP + a couple of prefixes (dCDN can support that protocol for the advertised prefixes) K Ma: can PIDs be defined recursively (i.e. PID pointing to a PID) ? J Seedorf: not recursive. disjoint types of footprints in the same map (e.g., prefixes & AS numbers) Taesang Choi: footprint/capa happens after bootstrapping & init? J Seedorf: yes - request router has fetched network map for each capability, then decision of selection of the dCDN (based on business logic) - summary of advantages / suitability of ALTO: FCI is about giving topology info to uCDN, the exact purpose of the ALTO protocol - I-D is not quite mature, looking for concrete examples. Trying to extend to AS numbers and so on... - ALTO WG is progressing, making it much more suitable for CDNI needs by updating its charter to add new capabilities (e.g. Incremental updates, server-initiated) but timing for availability of those in unknown as we are in the rechartering process. CDNI URI Signing, draft-leung-cdni-uri-signing-02: Kent Leung ------------------------------------------------------------- - 3 new authors - presents overview of the draft, not just a diff between versions - possible scenarios depending on the redirection method (HTTP or DNS) and the type of the keys (symmetric or asymmetric) - HTTP based: uCDN validates the signed URI and sends back a URI also signed by the uCDN. - DNS case: DNS replies pointing to the dCDN, solves IP @ of surrogate. dCDN validates the signed URI. a) assymetric keys - DNS needs public key of CSP b) symmetric keys - HTTP redirection: dCDN needs a shared key w/ uCDN (strightforward because of trust relationship) - DNS: dCDN needs shared key w/ CSP (requires trust relationship) - CDNI attributes (enforcement attributes, signature computation attribute - e.g.: select type of hash function for hmac computation, URI signature attributes = like a container, URI signing token attribute) - avoid attribute collisions (scope of attributes) - operations summary: signing URI & validating URI signature J Seedorf: are you specifying the order, placement etc. in the URI? K Leung: yes, need to add something about sequencing, to make it completely clear - next steps: got some feedback, had informal discussions, have things to be done like expand CDNI interface considerations. Anything related to URI signing should be documented in this particular draft. J Seedorf: why need new interface, why not just use metadata? K Leung: There are things that just need to be specified beyond metadata e.g. actual signing algorithm, impact on other interfaces like RI or LI, think about HTTP ABR J Seedorf: understood K Ma: HTTP ABR, do we really want to define something specific for HAS? K Leung: HAS draft had a section on URI, said we can extend URI signing. Ray van Brandenburg: not really defining something new, mostly going to implement the HAS RFC F LeFaucheur: remember that CDNI HAS RFC is not a WG doc, so just advisory. F LeFaucheur (as an individual): maybe we should aim for a first version of URI signing that doesn't try to be smart about HAS. K Ma, Kent, Ray: everybody agrees. J Seedorf: add URI signing to the Charter? Metadata should be used ?... Kent Leung: some things in metadata, but there are multiple additional things (e.g. signature computation) J Seedorf: ok, so then make a new doc and add it to the charter F LeFaucheur (as an individual): I very much support adding it to the charter. URI signing across CDNs is commonly deployed today using proprietary flavours making it painful to deploy. Subject has good momentum, has attracted some new contributors => good interest in the work - people express their support: Matt Caulfield, Ray van Brandenburg, Kevin Ma, Grant Watson G Watson: Request interface currently outside of CDNI scope... ? need to open CDNI scope to include request interface F LeFaucheur: so far, Request interface is outside of scope, but some aspects are required for URI signing such as URL format etc. So we just need to be careful if we decide to add URI signing in charter about what it says about "request interface". Scott Wainer (jabber): URI signing is a "mandatory to add" to the charter D Malas: hum test for whether "you are you in favor of adding URI signing to the charter?" * in favour: reasonable hum * against: zero hum CDNI Control/Bootstrapping, draft-choi-cdni-control-bootstrapping-01: Taesang Choi ----------------------------------------------------------------------------------- - identified 2 additional requirements: a) discovery, b) negotiation in the bootstrapping process - defined new trigger resources - added procedures and examples - recipient CDN checks preference w/ originator - new property of trigger = cdni.discover (follow trigger model request/response) - negotiation => originating CDN sends preference and recipient CDN replies (slides shows rejection & success scenario) - requires a lot of feedback for this revision Rob Murray: I suggested a simpler interface on the list: these are the types of delivery I support, these are my endpoints etc Taesang Choi: have not seen it on the list. Rob Murray: I will resend suggestions on the list. Taesang Choi: will consider that for next rev Conclusions ---------- F LeFaucheur: - we will update the dates for the deliverables... some are significantly out of date?! - we will confirm on the list tentative agreement to add 1 deliverable for URI signing. Spencer Dawkins: i was nodding my head about rechartering, so now I am voicing it at the mic for the remote people. Framework is virtually done: get a new revision by september (Matt agreed), then it goes to WGLC. Requirements : Needs some editorial updates by early sept. Kent Leung: will do, refer to extended reference model. After that, doc is ready to go to AD review. F LeFaucheur: metadata, control, logging, redirection. Need to continue momentum. Go on with informal meetings, they're productive. Remember to document tentative decisions on the list so that people are aware and can comment. Don't wait for Vancouver to be active! >Meeting closes