[icnrg] Draft Minutes of ICNRG Main Meeting @ IETF95

["Dave Oran (oran)" <[e-mail]>]

Please review - comments/corrections to Dave Oran.
I plan to post these to the proceedings over the weekend.

Thanks to note taker Ralph Droms!

————
Here's what I typed...

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.

* 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]