Dirk: agenda bashing Final Agenda * Welcome, Agenda Bashing, Minutes taker, Bluesheets, Status - Chairs (10 min) * Reports from interim meetings in Paris and Buenos Aires -- 15 min Document update (see WG meeting slides) Need more readers for draft-zhang-icnrg-icniot-requirements Report from icnrg Paris interim (see WG meeting slides) Report from icnrg BA interim (see WG meeting slides) * Long discussion of NDN project design principles * Long in-depth session on privacy - Content privacy rather than connection overlay - No value in "session privacy" from IP * CableLabs white paper presentation (30 min) - Greg White https://www.ietf.org/proceedings/95/slides/slides-95-icnrg-0.pdf Q/A: Marc Mosko: Interesting presentation; thanks. First slide showed “flat line”; how do we anticipate where IP will be 5 years from now? Marc did a cache control paper a while ago that might be applicable? Dave Oran: Might take one approach to moving from existing CDN to ICN; might take a different approach to move to a new ICN CDN. Differences? Greg White: Yes. But he didn’t investigate it. DO: Speculation? GW: HTTP->CDN will be needed both ways. Where caches live might change? Dirk Kutcher: Do you have plans to continue? GW: Yes; but currently on hold. * Small specification updates (Marc/Nacho/Chris) (20 min) https://www.ietf.org/proceedings/95/slides/slides-95-icnrg-2.pdf Presentation based on diff2 lci:// => ccn:// Hash agility; MUST support SHA256; ContentObjectHashRestriction SHOULD be SHA256 to guarantee interoperability Ravi's questions on mailing list 1. Should nameless objects be in the specs DO: Causing trouble with terminology "nameless objects"; what can we call something that is matched by hash but fetched by name? Routing info is *separate* from identifier info. DO: Discussion on mailing list didn't really terminate. Need to decide whether to separate routing from identification through semantics or syntax. Nacho Solis: "nameless object" not really used in docs; objects are "objects" regardless Dean Bogdanovich: suggested another name 2. Should there be an explicit separation of locator names from identified names 3. How does this all affect the forwarding label draft? 4. Introduce a 3rd message type as NamelessContentObject in addition to a (Named)ContentObject? Next steps: WG participation needed. DO (chair hat on): trajectory is to publish as Experimental RFCs. Any RG members think this trajectory is problematic (no response) DO: Anyone working on implementations? At least 3; plus CCNx-lite * CCNx (was LCI) naming document updates (Marc/Nacho/Chris?) (30 min) https://www.ietf.org/proceedings/95/slides/slides-95-icnrg-1.pdf MM: Asks RG to accept as RG document DO: We have a semantics doc for meaning, protocol doc for how to put on wire, URI doc for representing to apps. But we have name types; we need the minimum subset of the name types somewhere. NS: PARC has drafts on chunking, etc., but haven't moved them forward. PARC thinks the 3 docs are consistent and form a base set of documents. Manifests are close to being done. DO: Purpose of experimental RFCs is so people can experiment. What is the set of things really needed to enable experiments? Strongly encourage to identify and bring forward pieces that are really important. NS: Chunking and fragmentation docs are important but not critical. * IoT (30 min) -- postponed as Ravi could not make it https://tools.ietf.org/html/draft-zhang-icn-iot-architecture-00 * Status of terminology work NS: RG documents all use terminology in slightly different ways. Want to write docs that capture most popular (or maybe two most popular) definitions for certain terms. Bastion Wissingh: Target is a first draft before the next IETF in Berlin. We currently have Dave Oran, Lixia Zhang, Christian Tschudin, Nacho Solis and Bastiaan Wissingh Participating in the work. If you would also like to participate, contact one of us. * Moving to a WG (not on original agenda) NS: Move more stable work (three base docs) to IETF WG: transport, forwarding. Routing, security, etc. would stay in RG. NS: Target is BoF in Berlin. Mailing list is next step. Charter, BoF discussion would be first topics or mailing list. DO: Discussion about BoF on new list or on icnrg mailing list? Room? DB: Using existing mailing list better to capture existing participants DO: Anyone annoyed by extra traffic (no response). OK, will take question to icnrg mailing list. RD: Either move forward icnrg docs or generally ICN protocols. MM: Want to move CCN/NDN docs forward; depends on which area * Discussion on future work items/topics (20 min) - Possible Interop in Berlin? - Routing - Application design experience/considerations MM: Get a bibliography of applicable routing papers; ask authors to talk about that work DO: likes the idea; target at ICN conference interim because they will be at ICN conference. Application experience in Berlin? DO: Anybody building applications; chairs to encourage application focus in Berlin MM: advertise on mailing list first * Wrap up, Next meetings (10 min) - Interim in Berlin? DK: Any objections (no response) DK: RIOT Summit July 15-16 - Interim in Japan in conjunction with ACM ICN-2016 conference DK: Will send info to mailing list; looking for venue CCN Principles (not on agenda) https://www.ietf.org/proceedings/95/slides/slides-95-icnrg-4.pdf NS: Read NDN principles and notes from discussion on Sunday NS: Starting point for discussion (See slides) MM: (explains slide 1) Bore Ohlman: What is "bigger object" from which "segments" or "chunks" are taken from? MM: "provenance" does not mean "endpoint"; more generally "cryptographic principal" DO: Avoid "everything works at every level": identify "scope" as "spanning layer"; not part of, e.g., "application layer" Kevin Fall: does "provenance" include entire history or just source? MM: consumer can determine provenance that it cares about; imagine different contributors to a movie KF: multiple names for different subcomponents? KF: haven't said that namespace is unique here or borrowed from elsewhere? KF: separating naming from transport would be useful. MM: letting applications pick names is a good thing but different from the transport names BO: elaborate on "consumers must use privacy" MM: producer of data can require privacy DO: confounding privacy and confidentiality; previous statement was confidentiality NS: Different set of invariants, single names (see slides) NS: Universal: runs everywhere NS: resilient/robust: as r/r as possible; don't depend on layer below for r/r NS: scalable: many simultaneous clients; router can manage many simultaneous "flows" or packets NS: efficient: low latency, etc. NS: strictly participative: only those nodes in the "path" participate in a packet exchange NS: discreet: reveals only what is needed for some action; remainder is hidden KF: suppose underlying mechanism is broadcast; can application communicate with forwarder to ask what information is require? NS: interesting idea KF: app could supply info, network responds "here's what I will use" MM: needs to be a "contract" about network services; e.g. router requirements, APIs, etc. DO: too high level, not enough oxygen? E.g., need to separate active and passive participation. Good list, not sure what to do with it. NS: extensible: don’t want to nail things down too early DB: Another principle: How does an app get to know the data is available without knowing where it is DO: the contrapositive - make assertions that a piece of content *doesn't* exist MM: "extensibility" or "upgradable" - new functions and path to transition [end]