Minutes for ICNRG at interim-2016-icnrg-2
minutes-interim-2016-icnrg-2-1

Agenda:
https://trac.tools.ietf.org/group/irtf/trac/wiki/icnrg

Session 1 -- NDN architectural principles (Jeff Burke)
https://www.ietf.org/proceedings/interim/2016/04/03/icnrg/slides/slides-interim-2016-icnrg-2-2.pdf

Nacho Solis: Should we bring up issues from the mailing list here?
Dave Oran: Yes, but the crowd here doesn't represent everyone on the list.
Nacho: It is unclear that every principle applies equally to every part of the
architecture Jeff: Yes, they highlight different parts/levels/layers in the
architecture, and this could be made more clear later. Nacho: It would be
helpful if we also discussed where each principle applies in the architecture.
Jeff: They come from and focus on the NDN thin waist. DaveO: This can help
discussion about what should or should not be in that waist. Nacho: Hard time
treating the principles together (e.g., DTN-style communication in the
Universality principle doesn't jive with the flow control principle) Jeff:
Universality slide is intended to capture certain applications and how they
depend on the network layer. Nacho: "What is it not?" If a principle means NDN
is X, what is NDN *not* (or what does it lose)? DaveO: Packet format semantics
need to be universal (not the encoding). IP had disparity between semantics and
encoding -- it wasn't clear how encodings could change without affecting the
semantics Jeff: In the IoT case, we aren't defining new semantics (universal).
Nacho: How about non-bidirectional links? Jeff: Don't think those are ruled
out. DaveO: Non-universal does presume bidirectional links Marc Mosko:
Principles 2 and 3 have issues with bidirectional links Ralph Droms: Some
problems with IP comes from trying to push IP functionality down (to be
universal, e.g., to extend over L2). Can we write down the L2 properties that
NDN depends on? Asymmetric links is one example of a property that L2 doesn't
provide but NDN depends on. Dave: Second bullet slide 6 (r.e. protocol
evolution) is a sufficient condition, not a necessary one. Nacho: What about
push? Universality is about supporting different types of mechanisms. If push
is needed (for some applications), why is it not included? Jeff: Is push-style
communication the application the network requirement, or is it just how the
application achieves some goal? Dave: Might not be necessary for all principles
to be conflict-free -- some goals can be in conflict. e.g., push and flow
balance are in conflict Jeff: Is the goal of universality to achieve *all*
types of communication or application support (to resolve all mismatches), or
to achieve those which NDN is designed for? Nacho: Do you think IP and CCN also
have the universality principle? Jeff: Yes, it seems so. (Chris: maybe
misunderstood) DaveO: Another goal is "fungability." Many things in IP were
deprecated without killing the protocol The functionality was sufficiently
encapsulated so that poor design decisions don't break the protocol. Marc: One
could argue that IP is not universal -- take NAT and application proxies as an
example. Dave: But those broke the IP principles Marc: Some people do NAT for
address space problems (that seems to have broken the IP universality
principle) and security Dave: If you use it for security you're wrong Dave: Can
you elaborate on the second principle (only data in specific environments
should go to the network adaptation layers)? Nacho: What does it rule out?
Marc: If I have a public key in a packet, does it exist in the same "context"
as the name? It won't be used at L3, only above. Jeff: Notion of data
provenance is seen as a universal requirement. Nacho: What about the LINK
object? Where does that fall here? Jeff: The LINK object is something that's
part of the interest (it directs it somewhere). There's a separation between
the notion of data and it's name (and signature). Nacho: (describes how LINKs
are used) DaveO: A LINK object is a semantic that's defined above the base
network protocol. Nacho: No, it can't be. You have to forward on a LINK object.
DaveO: Name indirection is a fundamental element of the architecture (it isn't
layered on top) - should this be part of the principles? Nacho: First bullet on
slide 9 seems to be incorrect if you bring LINKs (indirection) into the
protocol. DaveO: An alternative architecture that uses indirection would have
included encapsulation as a principle. Jeff: I don't think encapsulation is
ruled out -- need to chat with architecture folks Jeff: Data being defined
independently of the communication environment and being the fundamental unit
transferred in the network is the point here. Marc: Some aspects like "Content
Type" are transport features. Those might be a better example of a public key
since it's related to the data. Nacho: There's a max packet size? Jeff: Not by
the architecture, but by the protocol DaveO: First bullet on slide 9 is false
(there's lots in a packet that is unrelated to the data, e.g., nonce) Jeff: If
the bullet said "data packet format" instead of "packet format" would you feel
the same? DaveO: Yes. There are a number of fields that can be in packets that
are unrelated to the data (e.g.,  "distance" from the consumer from which you
fetched the data). Question: In the case of using ICN for IoT, you might have
data that's used in specific environments (and not others). Jeff: (missed)
Marc: New fields/TLVs are being made flat in the packet. With a layered
approach, there are nested contexts in the packet. This is seems to be a
dichotomy (packet flexibility vs keeping packet format minimal for L3). Nacho:
Negative of the principle: NDN elements and packet format should not include
information that is not data related. App data does not get modified or
appended to by the network at all. InterestReturns and Interests are not
related to the data. There is some part of a packet that the application owns.
The app has to own some piece of data that is network interpretable (so the
packet can be moved by forwarders) DaveO: Another level of nuance -- things
that are end-to-end from the protocol vs things that are hop-by-hop The notion
of having an adaptation layer has to have some notion of preserving end-to-end
semantics Ralph: End-to-end semantics might extend above L3 (data distance
could be useful at higher layers) DaveO: Be very careful of what portions of
the protocol are hidden in a layer and not exposed and what portions/semantics
that need to be exposed across the layer boundary Jeff: What is the layering
strategy or approach? We would like input on the approach: Ravi: Two levels of
management: (1) names, keys, etc. and (2) network management. If everything is
in the application scope then how does a network entity use it? Jeff: It would
be nice to see a design principle in terms of what falls into the "forwarder
strategy" bucket. Missing things just haven't been articulated yet Marc: If one
uses hash-based names in NDN/CCN, you can say it's immutable data. Otherwise,
it's just convention that data is immutable. (Producer that has signed
something won't or must not generate something with the same name and different
data.) Jeff: Same with hash-based names? Marc: Not really -- immutable data is
really being moved with hash-based names. Marc: Ramification of principle then
the majority of packets must use hash-based names. DaveO: Problem: Producer
publishes something with given name (it's assumed to be immutable). If someone
requests it with the hash then it's immutable. If a producer publishes new data
under the same name then the data is not immutable. Th Nacho: If you can get
different data for the same request, then the data is not immutable (from the
application's perspective). DaveO: Immutability is a result of hash-based
requests. DaveO: Another weird example: at every hop, the router modified the
data using the number of hops the data was away from the consumer. Consumer
requests data by knowing this distance and generating the right "request." What
exactly is immutable here (since the request is changing but the correct data
was returned)? DaveO: What about "immune from undetected modification" instead
of "immutability"? Marc: What about incomplete requests? Jeff: Response is not
*not* immutable -- application needs to determine if that's the correct
immutable thing DaveO: "NDN should be capable of fetching uniquely named
immutable data packets" Nacho: Every piece of content has an immutable name
that has to be somehow based. Both architectures let us retrieve the data using
this immutable name (with hash) All agree that there's a unique way to name
data (-> with a hash) Jeff: Name, data, and signature content is considered to
be unique Marc: Maybe rename as "Data producers should uniquely rename their
data so that they don't reuse names" and "you should be able to detect
unintended modifications to the data." Jeff: The definition of immutability (as
written) is for hash-based names and name+data+signature names/requests. Ralph:
When producers use the same name, do producers include the hash in the name?
Marc: "Should" on the slide that hash-based names are used predominately but
that's not the case in NDN (unique produced names are what's used) Ralph:
Second bullet seems to contradict the first on slide 10 DaveO: Slide 13 -- use
integrity instead of security Jeff: There was a reason that we generalized it
(maybe confidentiality properties are included as well) Ravi: What about flat
names? Dave: Flat is a degenerate case of hierarchical names Ravi: But how do
you route on flat names? Why not use something like "hybrid" to capture flat
names as well? Jeff: A flat name is a single component Nacho: You're ruling out
attribute-based naming DaveO: And DAG-based naming Jeff: You can do
attribute-based naming with hierarchical DaveO: No, there's an order Nacho: You
can do hierarchical names with attribute-based names Ralph: When you consider
names with chunks, do they individually identify chunks or the big thing which
is chunked? Marc: The name identifies the security context of the data. Taken
as a whole, with name, hash, etc. is like a "named address." Ralph: (missed)
Marc: Should have probably been principle 0 of "NDN uses a request/response
paradigm for data" Jeff: Part of that was intended to be captured in the data
centrality slide Nacho: Discovery has to exist somewhere. This principle is
about network-layer discovery, but is that the right place for it? Unclear why
it's a principle at this layer DaveO: It's an NDN principle -- should this be
promoted to a general ICN principle? Jeff: If the disagreement is about
performance we can stop there DaveO: There's also a privacy problem - consumers
can explore caches Nacho: In-network discovery forces every node to do it.
Otherwise it doesn't work. Jeff: Not sure that's the position or intention.
Need to chat with arch folks. DaveO: If you don't do discovery, then the other
principle about the network just working is violated. Jeff: The intention is
not to solve discovery for all applications -- but that there's a way to ask
the network for an incomplete name DaveO: You could also say that "every prefix
of a valid name is a valid name," so there is no incomplete name (different
from NDN) Jeff: Other mechanisms for discovery rely on services to answer
questions (e.g., DNS). For some types of applications, the forwarder provides
this discovery service. DaveO: This relies on something above L3 to be
reachable. Nacho: Does this mean that any node that comes into the network can
discovery any resource they desire? DaveO: First sub-bullet of slide 20 should
read "all non-attack interests will..." Ralph: Unless we restrict or specify
what's allowed in a query (or incomplete request), then we open the door to
possibly many, unrestricted queries. That's possibly a dangerous architecture
principle. Nacho: The same functionality can be provided as a service (without
forcing it on every node) DaveO: The consequence of this principle is that
discovery can always happen. Dirk: shouldn't the principle should just be that
interests can have incomplete names? (Instead of in-network discovery) Ravi:
Anyone who wants to write an application that wants to do discovery correctly
would likely do this at the service layer. This means that the usefulness of
the principle is questionable. Jeff: Good question -- it's not clear how much
you can really achieve here vs what you can do at higher service layers. Nacho:
If it's not a principle, then an application cannot opt out. And anyone can
discover traffic (this is bad even if it's encrypted). Jeff: With
exact-matching this can still happen (if the suffix can be guessed). It depends
on the adversary. Not sure about the security problem with traffic discovery.
Nacho: Given that discovery already happens everywhere, why not just make it a
service? Jeff: Might be good to ask on the mailing list DaveO: Architectural
consequence: you need to violate layers if the discovery service needs to look
into a cache or repository. If there's a data structure that is used by two
layers, then we have a violation. DaveO: If GB MTUs are allowed, hop-by-hop
flow balance is broken. Marc: If response sizes can vary greatly, then flow
balance is hard to do well (to allocate receive buffers, e.g.) Nacho: In old
CCN, broadcast interests could result in multiple replies and we chose one at
random DaveO: Each interest packet should bring back no more than one data
packet, but there might be more than one instance of that data packet Marc: Not
true if you use incomplete names Jeff: Maybe an articulation issue with the
principle. Could replace "link" with "at every hop" (to handle the broadcast
problem above) Jeff: This is motivating the idea that "one interest results in
one response" Nacho: Maybe the inverse should be said "if you receive one
interest then you'll reply with one response." Jeff: The principle of
flow-balance in multi-party setting is not realistic. DaveO: We have the sketch
of a proof that single congestion control algorithm can’t get both fairness and
max network utilization if you do both multi-path and multi-destination
delivery DaveO: Nuance: flow-balance is neither a necessary or sufficient
condition for doing better whats in slide 24. Hop-by-hop congestion control is
necessary. Marc: Right now the amount of data in a data object is controlled by
the producer, and an interest has no information about that, so routers can't
pre-allocate buffers and whatnot DaveO: "There is in my scheme" (N.B. this is
Note Well disclosure of possible IPR) Nacho: Router cannot predict anything at
all Marc: Router can't commit bandwidth for a response unless the request
conveys this information DaveO: Cisco submitted a patent on a scheme that
includes this information (response size)

Session 2 -- CCNx Simulator Announcement (Marc Mosko)
Working on ns3 module for CCNx
Will be released under the same license as C code on Github
Users will download ns3, download the module, run a patch, and then be good to
go.

Session 2 -- CCNx Software Distribution Overview (Nacho Solis)
Note: Metis is deprecated in favor Athena
(Went through code, compilation, and unit test workflow setup from Github)

Session 2 -- TLV Compression (Marc Mosko)
https://www.ietf.org/proceedings/interim/2016/04/03/icnrg/slides/slides-interim-2016-icnrg-2-7.pdf

Dirk: Have you looked into ROHC
Marc: Doesn't exactly fit with ICN-like exchange -- ROHC is very general for
what header compressors can do. We wanted ICN-specific compression on the air
interface. Dirk: In ROHC you have to specify the compression scheme. Marc: Even
if we're running ICN over UDP (as LTE does it) you could use a custom
compressor for distinct ports.

Session 2 -- Name Resolution (Jungha Hong)
https://www.ietf.org/proceedings/interim/2016/04/03/icnrg/slides/slides-interim-2016-icnrg-2-6.pdf

Nacho: Do you consider DNS to be an overlay on IP?
Jungha: No
Nacho: Why is NRS considered to be an overlay?
Jungha: Overlay here means above the network layer
Borje Ohlman: This appears to be a service
Dirk: Overlay implies that there is a network graph that you can embed into the
network, but that's not what you describe Jungha: That's right Jungha: Data has
the same name wherever it is cached, and so a name can be mapped to different
locators (based on where its cached). If you get multiple locators back from
the NRS then the object must be cached somewhere in the network. Nacho; Slide 7
is trying to describe a use case, right? Is this that the caches register with
the NRS? Jungha: Caches register locators with NRS Nacho: For every object, a
cache has to tell the NRS that the cache is located at that location DaveO:
Does the word "cache" mean an alternative authoritative place to store data
(replica) or any intermediate router that can store data. Jungha: The second
one (opportunistic caching) DaveO: If you have a network with many routers,
they all have to report to the NRS Jungha: Essentially, yes. Nacho: Would
Google be an "NRS"? Marc: Google is much more general than NRS Borje: Caches
were controlled in Netinf (missed rest of the comment) Nacho: If objects are
packets (small size), then this doesn't scale. Maybe it would work if this was
for the whole object. Borje: Netinf registering involved manifests, not chunks
of a manifest Jungha: Nacho's question(s) might be out of scope -- this is just
about the motivation for the NRS Nacho: Just trying to understand the use case
to motivate the NRS properly Jungha: NDN and CCN are not representative of all
ICNs -- some ICNs use NRS Nacho: A lot of ICN work uses NDN/CCN. These two
might still need functionality like NRS. Unclear about what the motivation of
the NRS is (the need for something like a NRS or a specific type of NRS?)
Borje: Some kind of name resolution or redirection service would be needed for
ICN for publisher mobility (among other reasons), and she is trying to motivate
people to work on that problem Ravi: One good use case is in Jeff's slides --
the admittance of flat names Ravi: You can run without a NRS, but some
applications might need one. DaveO: Name to name is a good use case. Two things
considered here. Is the purpose of the NRS to convert non-topological names in
a namespace to topological names in the same namespace? Or is it to convert
those to topological names for data that can be located elsewhere? Nacho: Some
namespaces are managed (due to topological nature), others are not. Can the NRS
map to both? Nacho/Dave: Resolving to names which are not under control can be
avoided if the mapping scheme is more well defined. Nacho: (r.e. name to IP
address): some people believe that DNS can solve everything. Can't the NRS just
be solved by the DNS right now? Marc: DNS query inputs are limited (e.g., bytes
per segment) -- authorities are input, not generic URLs Ravi: Might need a more
distribtued resolution system to handle mobility Dirk: Using DNS as a protocol
vs using DNS as part of the ICN infrastructure -- two important differences.
Borje: Thinks DNS could be reused, but the details must still be worked out.
That could be one possible outcome of work in this area. Dirk: We want to
discuss how we should continue this discussion. Borje: Might be advantageous to
write up a draft that discusses the design and implementation issues. Comment:
Maybe the document should include the assumptions, motivations, and limitations
of using DNS.

Session 3 - Privacy
Intro (Dirk)
have been discussing privacy over past couple meetings, consensus was that we
needed to discuss more deeply seeing what is going on in IETF for privacy- more
encryption in the network also some issues - privacy vs. optimizing network
performance (tls & cdn) in ICN we have a more powerful forwarding layer and
ways to correlate requests to responses

Private Communication in ICN -- Chris Wood
https://www.ietf.org/proceedings/interim/2016/04/03/icnrg/slides/slides-interim-2016-icnrg-2-1.pdf

state of privacy in ICN relative to maintaining parity with IP
Table of options vs features
DaveO- for case of group key -
there is correlation within users in the group
there is also correlation by users outside the group
Jeff - for group key & forward secrecy  - this assumes a particular use of
group keys and assumes a session-based communication, that may or may not hold
DaveO - the term "Session" is overloaded - most general: multiple exchanges use
the same key; more specific implies ordering and more constraints DaveO - on
private context claim - should also say "...or some necessary application
feature." Nacho - why isn't private context the default and applications can
opt out? Chris - applications should not be allowed to opt out Nacho - ??!
DaveO - dangers of allowing app developers to screw things up is too great
DaveO - some examples of "application feature" - by intl law, some money
transfers need to be sent in the clear.  But this isn't a "desire" it is a
requirement. Jeff - private context means what? Chris - we generally mean one
consumer and one or more affiliated producer instances Jeff - is the consumer
aware of the multiple producers? DaveO - multiple producers would share the
same key What does private mean? Stephen - do you include applications like
payroll Chris - yes Dirk/Dave - not all applications need authentication Chris-
we meant server authentication DaveO -OK Implications Stephen Farrell - what do
you mean "DTLS-like"? Chris - use key exchange protocol, over connectionless
transport Stephen - but it is not two party Marc - not necessarily, it could be
two party for the exchange, but one party could then share the keys with
replicas Dave/Chris - we've chosen DTLS-like, but it may not be the only
solution that meets the requirements Borje - what is an endpoint? Chris - for
an Interest, it is any of the set of hosts that can serve that prefix Outer and
Inner Context Jeff -How much information is leaked by the outer context Dave-
for parity, should leak no more than is leaked in tls - address and port number
Nacho- QUIC hides even retransmissions, Marc - if retransmission re-sends same
outer context, then there is leakage, but doesn't have to do it this way Nacho-
what is the boundary between DaveO - another approach is to examine obfuscation
by information theoretic approaches, these shouldn't be off the table Chris -
similar to the paper at ICN last year? Dave- yes Chris - looking at that with
Christian(?) paper coming soon

O & I Context Implications
DaveO - opportunistic caching can still provide temporal reuse (handle
retransmission) Chris - unless you take the approach Marc mentioned
(retransmission uses new outer envelope) Stephen - on public key usage - but
you are still using public keys for the PKI? Chris - right, for the
authentication, just not for the encryption Questions to Answer Chris - goal of
this was to investigate what "parity" means and understand the implications
DaveO - in ICN, can separate authentication from privacy MCTLS can kind of do
this, but you'd have to jump through a lot of hoops Stephen - but you get rid
of all of the caching benefits of ICN? DaveO - but there is still a lot of ICN
goodness - the argument would be that an ICN router would be much cheaper than
a CDN proxy DaveO - ICN approach could prevent the custodial transfer present
in CDN Stephen - multiparty extension of DTLS needs a lot of examination

Approaching Privacy over ICN: Values-in-Design Approach -- Jeff
https://www.ietf.org/proceedings/interim/2016/04/03/icnrg/slides/slides-interim-2016-icnrg-2-9.pdf

Critical misinterpretations/misconceptions about NDN
DaveO - but you do need to assume that data is around forever
More accurate..
DaveO - by cleartext, you don't only mean human readable
Jeff - yes, any encoding that can be used to derive information about the comms
Some proposed reframing
Nacho - Is this about TLS or about private communications
Jeff - private communication
Use case #1
Jeff - Just having a secure connection to the service provider is not the end
of the story Nacho - question should be: can ICN provide tools that could
provide a better model than is possible in the current network architecture?
ie. more than just protecting privacy of the connection to the service What if
a core contribution...(use case #2) DaveO - this is an example of misalignment
of interests between producer and consumer. there are cases where there is
alignment and cases with misalignment Stephen - misalignment might be too
strong DaveO - yes. "interests are different" Use case #3 Jeff- can we really
make the statement that in these environments we require session-based privacy?
Nacho - but you could support caching via an explicit proxy Jeff - so do we
need to design a proxy service to enable this? This may not be the simplest
solution to achieve the goals DaveO - what do you need to prevent cache
pollution - it may be not much less than what you need to do session-based
encryption Stephen - can't make the assumption that these users have no privacy
concerns, or that their privacy concerns are less important than the bandwidth
concern Nacho - another example might be better for this use case - a network
in which a single entity controls all of the network and applications and
users, they may be more concerned about network performance DaveO - the
villagers example could be handled via group keying Use case #4 Stephen -
Ubiquity is important for this case- if you want to solve it, you have to use
the solution all of the time Opportunities Ravi - need to define what it is to
be an ICN service provider. It may be very different than an ISP, and could
involve examining requests and providing better services. DaveO- history has
shown that people will give up their privacy in exchange for services, without
really knowing what they've given up Marc - just because the communication
between two peers is private doesn't mean that the peers have to be consumer
and publisher, could be between consumer and ICN service provider. Service
provider could provide caching service, etc. Onus is on application to
understand/decide which sessions require privacy end-to-end vs ones for which
the MIM can be trusted. Jeff - so the KE approach is just focused on providing
a secure connection, not necessarily to the producer? Marc - yes

Meaningful privacy protection in ICN -- Stephen Farrell
https://www.ietf.org/proceedings/interim/2016/04/03/icnrg/slides/slides-interim-2016-icnrg-2-8.pdf

Stephen - With untrusted caches, it doesn't appear that there is a solution
with existing crypto (possibly homomorphic ciphers) DaveO- ICN doesn't have the
same "hard edges" in privacy support that exist in the IP world.  May not need
to throw away the nuance that exists in ICN in the name of providing "parity"
to IP. Nacho - where we usually end up in discussions is that the more privacy
you want, the less you get out of caching Marc - with KE protocol, we wanted to
try to solve the most common - easy use cases Stephen -did you look at Kerberos
rather than DTLS? Marc/Chris - “No -- we focused on DTLS for the key exchange
but used Kerberos for the MoveToken

CCNx-KE vs (D)TLS -- Chris
https://www.ietf.org/proceedings/interim/2016/04/03/icnrg/slides/slides-interim-2016-icnrg-2-3.pdf

Chris gave an overview following the slide deck. No questions
Move token - Chris
Dirk - move token is another example of a host-based communication

Session 4 -- draft-forwarding-label-ccn-02.txt (Ravi)
https://www.ietf.org/proceedings/interim/2016/04/03/icnrg/slides/slides-interim-2016-icnrg-2-11.pdf

Borje: Have you updated the slides?
Ravi: No
Nacho: First sub-bullet on slide "FL for manifests" -- what do you mean?
Ravi: If you separate the locator from the name, then there is no ambiguity
problem. A name is always a name. Nacho: Would a rename in the field be less
confusing? What if ContentObjecthashId == ImplicitName? What if the Name was
called the ForwardingName? (Without changing the functionality.) Nacho: We have
no application names in CCN Ravi: That's not true. Manifests are created with
application names. Nacho: Applications can't choose random names Ravi: It
cannot but there might be semantics about how it's used. Applications decide
what goes into a name (beyond locator). Nacho: Feels like this is adding more
complexity into the interpretation of the name. Nacho: If I understand, you
want to replace the Name with the Forwarding Label? Ravi: No, use the name as
the forwarding label and keep the ContentId as it is today.

Session 4 -- draft-ravi-ccn-notification-00.txt (Ravi)
https://www.ietf.org/proceedings/interim/2016/04/03/icnrg/slides/slides-interim-2016-icnrg-2-10.pdf

DaveO: Semantically, what is "all intended receivers"?
Ravi: Parties that can get the data
DaveO: How to identify without flooding?
Ravi: Many ways, e.g., multicast ID
DaveO: Multicast as a notification mechanism?
Ravi: Assumes there are receivers subscribed (i.e., subscription is required).
DaveO: Wasn't clear.
DaveO: Does "forwarding support" imply that the communication pattern wanted to
be used is embedded in the name Ravi: Yes DaveO: Something with the same name
can't determine what type of communication (unicast vs multicast) to use. Seems
to be similar to IP where portions of the namespace are reserved for different
comm. paradigms. Is that considered to be a good idea in the IP world? Is this
a good idea in ICN world? DaveO: This partition is generally considered to be a
bad idea. So why adopt it here? Ravi: Two things: (1) are you saying that
multicast is bad? DaveO: No -- I'm just saying that embedding the communication
type in the name is considered to be a bad idea (from IP). Ravi: So we
shouldn't have names that identify the type of communication? DaveO: Yes,
that's right. Nacho: IP multicast relies on some partition as the namespace
Ravi: Not sure how to make this distinction in a forwarder without putting it
in the name Dirk: Why don't you just specify a complete pub-sub system? Ravi:
Pub-sub is only one system you can build on this scheme. This is a new third
primitive in the network layer.