Subject: Re: [icnrg] The myth of meaningful names (was: Locator hint)

From: "Thompson, Jeff" <[email-masked]>
Date: Fri, 16 Oct 2015 20:08:42 +0000

Ravi writes:
> Also the notion of nameless objects seems to contradict, when the basic primitive of ICN  is named data.

No contradiction from current practice. Here is an interest name that I just grabbed from the NDN test bed: "/ndn/edu/ucla/remap/ndnrtc/chat/remap/F6PCWlqWrV/1444850865/1". The prefix "/ndn/edu/ucla/remap/ndnrtc/chat/remap" is only useful to route the interest to the application. All the thousands of interests flying towards this application have the same prefix. The last part "F6PCWlqWrV/1444850865/1" only means something because the producer application told the consumer application to ask for it. This name in no way "self-describes" the object, so it is in effect "nameless" already from an outside observer. There is little difference if the producer application told the consumer application to ask for an object by hash. This is similar to how I understand the problematically-termed "nameless object": An object is requested in an interest with a routable prefix and another part (the hash) which the producer application told the consumer application to ask for.

- Jeff T

From: icnrg <[email-masked]<mailto:[email-masked]>> on behalf of Ravi Ravindran <[email-masked]<mailto:[email-masked]>>
Date: Friday, October 16, 2015 at 12:22:00
To: Dirk Kutscher <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [icnrg] Locator hint

Agree that we shouldn’t mix the two semantics that of a ID and a Locator, they operate and are managed in two different domains, one at the application and the other at the network level. Also the notion of nameless  objects seems to contradict, when the basic primitive of ICN  is named data. All this comes by mixing the ID/locator definitions, resulting in Interest message carry locators which are supposed to be meant for persistent IDs; a clear separation of the two in the protocol will serve many purposes, manifests, mobility, routing scalability. Agree there are security implications like cache poisoning or exploitation use of these name separation and should be addressed considering the different trust context.

Regards,
Ravi

From: icnrg [mailto:[email-masked]] On Behalf Of Dirk Kutscher
Sent: Friday, October 16, 2015 10:35 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [icnrg] Locator hint

Not disagreeing, but: another way of seeing this is that entangling object identification, representation of organizational structure and location information in an aggregatable fashion in a single naming framework is likely to cause some headaches – and we are currently figuring out how to disentangle this again – with names hashes and nameless objects.

We want to be able to connect a bunch of ICN nodes locally, e.g., in a building automation scenario, and address Interests to semantically meaningful names like “/jp/yokohama/pacifico/room123/light-switch42” and want the same concept and names to be useful for global-scale communication. This can only work with a few very strong assumptions: We can get inter-domain routing to work based on such names – and there is no  mobility.

Obviously, flat naming schemes are facing similar problems. One pattern here is to use some organizationally structured part of the name to look up: locators (or location hints) – indirection…

Dirk

From: icnrg [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Freitag, 16. Oktober 2015 18:37
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [icnrg] Locator hint

The Locator Hint or Link Object are proposed solutions to a big ICN/CCN/NDN problem, namely the misguided belief the name is independent of location.  This is a somewhat incorrect assumption if we also believe, at the same time, that the name is used for routing.  By definition, routing is location.

There are numerous ways to get around this contradiction.

1- We allow anybody to publish any name anywhere and have the network look for it (in other words, no routing, just discovery)
2- Have routing update on the fly (allow any node to advertise, via routing, the presence of name/namespace)
3- Do some form of indirection

In this email we’ll rule out options 1 and 2, which have some serious scalability issues for a real network.  That leaves us with option 3.

Locator Hints and Link Objects are in effect a version of option 3.  CCNx uses manifests to indirect to hash based names, also a version of 3.

The Link Object proposed in this paper gets rid of cache poisoning with a number of techniques that boil down to one big sacrifice:

- "The cache can then impose the restriction that only interests carrying the same link object can be satisfied with the specific instance of the data item."

Basically, what it’s saying is that if you retrieve something with the name /a/b with a link to /foo/bar  it can only be answered by an interest with the name /a/b and a link to /foo/bar.   Effectively, we are routing and matching /foo/bar/a/b when talking about object /a/b.  Disadvantage: A request for /a/b will not match the object (this would lead to cache poisoning)[1].  Advantage: The signature for /a/b (the object) can be done at a different level than the signature of /foo/bar/a/b (the link).

Note that this is a form of encapsulation.  I could achieve similar results by just encapsulating /a/b into /foo/bar/a/b and not require any link object.

The paper suggests verifying link objects. This is not sufficient to prevent poisoning.  I can have a valid link object (from an attacker) that brings me  an invalid content object.  If that content object is matched on name then poisoning will occur. The only way around this would be to have a reverse crypto mapping from the object name to the link object. (Like a signed content object + link object together from the content object’s key).

The paper also mentions that caches can check signatures and consumers can use excludes to help with poisoning. This is unscalable for a number of reasons and probably deserves another thread.

The current CCNx approach is to use hash based naming and objects with no names (only implied hashes). This allows us to get around many of these problems.  NDN could potentially use similar techniques (with or without the link object).

Nacho

[1] Some people believe that we’re not going to be in a world where this type of caching matters, so this may not be a disadvantage.

--
Nacho (Ignacio) Solis
Protocol Architect
Principal Scientist
Palo Alto Research Center (PARC)
+1(650)812-4458
[email-masked]<mailto:[email-masked]>

On 10/16/15, 12:22 AM, "Andrea Detti" <[email-masked]<mailto:[email-masked]>> wrote:

Dear All,
do you remember this old discussion?

Citing DaveO "While we may be forced into doing something like this ultimately....".

Well, this email is just to point out that NDN team embraced the Locator Hint, aka Link Object, principles in their NFD software, with a clever technique to avoid cache poisoning .

References:

http://redmine.named-data.net/attachments/download/427/forwarding-hint_20150814.pptx
http://named-data.net/wp-content/uploads/2015/03/SNAMP-NDN-Scalability.pdf
see also "network_region" configuration section in nfd.conf

Regards,

Andrea

On 09/01/2015 23:38, Andrea Detti wrote:
Great news.
Is there already a document presenting these interesting features or it will be released shortly ?

Andrea

On 01/09/2015 08:06 PM, [email-masked]<mailto:[email-masked]> wrote:
CCN 1.0 has gone major revisions since the old CCN.  In the current system
there are a number of features that make these issues less of a problem.

Specifically, we have Manifests and Name-less objects.  These basically
allow you to have name indirection and objects hosted independently of
location.

The name, which for us is a network name, is what the network uses to find
stuff. It¹s easy to thing of this as the same as the user defined name.
In some cases it is, but in some cases it might not be.

In CCN we can currently use manifests to do a form of secure translation
of one name to another. There are some limitations in terms of publisher
but the primitives are currently holding up for what we want to achieve.

So, to answer your initial question, I think that the primitives we have
right now can give you a lot of what you¹re looking for.  Will we need to
have some extra locator or some other scalability mechanism?  Maybe, but I
think we can get far with the primitives we currently have.

Nacho

--
Nacho (Ignacio) Solis
Protocol Architect
Principal Scientist
Palo Alto Research Center (PARC)
+1(650)812-4458
[email-masked]<mailto:[email-masked]>

On 1/9/15, 10:26 AM, "Andrea Detti" <[email-masked]><mailto:[email-masked]> wrote:

I agree on all your points.

Consequently, I see two choices in front of us before to think to use
ICN in the global scale:

1) either we found a reasonable way to scale the routing by object name
(including mobility and multi-destinations/multi-sources cases);
2) or we found a reliable and secure translation mechanism.

Which of two will require less effort?

I do not know :-)

Andrea

On 01/09/2015 06:21 PM, David Oran wrote:
While we may be forced into doing something like this ultimately, every
time you introduce a level of indirection via some kind of translation
function, you dramatically increase the attack surface against the
system. Not only do you have to secure the input and the output values
in the packets, you also have secure the translations against spoofing
and the service that performs the translation against the full panoply
of vulnerabilities.

Routing hints are particularly tricky. I recall a proposal for NDN
routing hints that was presented at a recent NDN retreat that looked
superficially clever, but collapsed in a heap of security problems after
a few hours of scrutiny.

Invalidation of mappings is also quite delicate for routing systems
where the expectations of routing disruption durations are much shorter
than say, name mapping disruptions in systems like DNS due to
translation cache TTLs.

One thing that makes routing hints (as opposed to name->name
translations) particularly tricky for NDN/CCN-like architectures is
doing them in a way that does not break or substantially constrain
multi-destination delivery. It¹s much easier to do this with
single-destination delivery - one example of a full-worked scheme is the
LISP mapping service for IP.

DaveO.

On Jan 9, 2015, at 2:30 AM, Andrea Detti <[email-masked]><mailto:[email-masked]>
wrote:

On 01/08/2015 06:00 PM, [email-masked]<mailto:[email-masked]> wrote:
PARC will be releasing the next version of our working documents
shortly, before the icnrg meeting.  We have for a while supported an
Interest carrying a Payload field that can carry extended information
that is not part of the name.  Intermediate nodes do not process the
payload.

If the payload can make a difference to a dynamic content publisher,
then the requester must put a marker of the payload in the name ‹ i.e.
put the hash of the payload a a name component, or use a nonce.  This
will allow proper multiplexing of different payloads in the name.
I see that this is a way to indicate to the router which is the part
of the name that is relevant for the PIT/FIB purposes. And it sounds
good to me, since it speeds up the lookup processes.

However, let me pose a more general question: is it really "ICN
mandatory" to use a component of the object name to forward?

What we would lose, if we used the object name only for PIT and
caching operations and (optionally) another "routing info" field
completely decoupled from the name for FIB forwarding purposes?

If we do not lose so much, why do not open an ICN 1.01 phase (2.0 was
too ambitious ;-))  in which we recognize that routing by object name
creates scalability problem in the large area, and so in these cases
ICN can be helped by a plain old by routing by locator (aka routing
info, routing hint, label, forwarding alias, etc.)?

If this was obvious, probably it is now the right time to define such
a TLV. Simirarily to KeyLocator we could define a ContentLocator that
specifies a (or more) routable Name where it it is possible to found
the object.

I know that I am rediscovering the wheel since many other excellent
projects/researchers before have predicted that, e.g.

SAIL project 2010  ³Routing hints²

S. Shenker, 2011 - Naming in content-oriented Architectures: ³Šthe
fetch-terms enable the routing system to more easily find the object²

http://www.icsi.berkeley.edu/pubs/networking/ICSI_namingincontentoriente
d11.pdf

Presentation of D. Oran, 2011 - NDN and IP Routing: Can it scale? 
³ŠUse a translation lookup to convert from content name to routing
label(s)²

http://tools.ietf.org/group/irtf/trac/raw-attachment/wiki/icnrg/IRTF%20-
%20CCN%20And%20IP%20Routing%20-%202.pdf

Hermans et. al,  2012 - Global source mobility in the content-centric
networking architecture- ³Separate namespaces for identifier and
locators².
http://user.it.uu.se/~frehe489/publications/hermans12global.pdf

L. Zhang, 2013 - Scaling NDN Routing: Old Tale, New Design,
³Application names are used for caching and signature verification,
while the forwarding alias, which reflects the service provider of the
content producer, serves as a hint to routers about where the packet
may be forwarded²

http://named-data.net/wp-content/uploads/2014/08/ndn-tr-4-scaling-ndn-ro
uting.pdf

N. Solis (PARC developer of CCNx 1.0), presentation at CCNxCon 2013 
Ordered-Element Naming (OEN), ³I presented a matching system with order
of preference based on labels (which included hashes of content)²
http://www.ccnx.org/events/ccnxcon-2013/

      Regards,

Andrea
It is not mandatory that applications do this ‹ some data might
rightly belong in the name.

Using this method relieves the forwarding plane from having to
process and store in the PIT large names that make no difference in
routing.  It also means that the potentially large payload does not
need to be echoed back to the client in the response name.

The previous PARC spec is at
http://www.ccnx.org/pubs/ccnx-mosko-tlvmessages-02.html
.  It will be updated in the next day or so and we will send an email
to the list.

Marc

On Jan 8, 2015, at 8:19 AM, Mark Stapp
<[email-masked]><mailto:[email-masked]>
   wrote:

On 1/8/15 4:24 AM, Andrea Detti wrote:

Dear Mark,

I found rather interesting this question

"Is it really necessary to continue to force all of the information
in
Interests into the Name?  Wouldn't it be clearer to use the Name
only
for publisher/routing info, object name info, and segment/sequence
number?"

and wonder ICN community think about that. Especially with respect
to
the routing info.
That specific question has been open for quite a long time - not
really in the routing context however. One position has been that
Interests carry "only" a name, and therefore all application-specific
data must be in the name. Now in fact Interests have been permitted
to carry several additional "meta" items - such as filters/selectors
(another open topic) and timeout values. Another position asks
whether there are types of application-specific data that could also
be carried outside the Interest name. We've asked whether REST-ful
application state transfer might be one example.

I see a scalability problem with the ICN routing plane,
yes, of course - that's a very long-standing problem.

especially when

objects are multi-sourced (same object on my PC and on my phone) and
objects are provided by mobile devices.  This framework could be the
norm in the future.
that's ... certainly an assertion I've heard before, but "could be"
is about as strong as it gets. there are a lot of questions about
whether encapsulation mechanisms, or "name resolution" mechanisms, or
some other mechanisms will be needed to deal with the expected name
scale, whether or not there will be any significant of peer-to-peer
communication. personally, I think it's highly unlikely that my phone
will "publish" anything directly, but that's just another speculation
really.

at the moment, I'd be happy if there could be progress on even the
most basic aspects of messaging - such as what names look like,
something that seems truly fundamental.

Thanks,
Mark

_______________________________________________
icnrg mailing list

[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/icnrg
_______________________________________________
icnrg mailing list

[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/icnrg

_______________________________________________
icnrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/icnrg
_______________________________________________
icnrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/icnrg

_______________________________________________
icnrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/icnrg

---

From: Ravi Ravindran <[email-masked]>
Date: Fri, 16 Oct 2015 21:08:45 +0000

Hi Jeff,

So it depends on who suggested the routing prefix part of the name to the producer, does that come from the network ?, I don’t think that is the case. What I understand is that the whole name is a persistent ID, it only happens that applications share that authority prefix hence is able to make use of name aggregation,  and no matter where you publish this content object should always carry the same name. In this sense, I disagree with the separation you describe, also a reason for the LINK object proposal in NDN.

Regards,
Ravi

From: Thompson, Jeff [mailto:[email-masked]]
Sent: Friday, October 16, 2015 1:09 PM
To: Ravi Ravindran; [email-masked]
Subject: Re: The myth of meaningful names (was: Locator hint)

- Jeff T

Regards,
Ravi

Dirk

Nacho

Dear All,

References:

Regards,

Andrea

Andrea

Nacho

I do not know :-)

Andrea

DaveO.

      Regards,

Andrea

Marc

Dear Mark,

especially when

Thanks,
Mark

---

From: [email-masked]
Date: Sat, 17 Oct 2015 00:10:20 +0200 (CEST)

Hi Jeff,

hmm, I think that names should have more meaning as they have today and 
hope that the "myth" that you claim is only temporary. At least they 
should have more meaning for the network.

While I agree and also claim that today's names are "flat" from a 
meaning point of view, I wished they would reveal more information, for 
example where the application part starts, which part is provider- or 
hoster-specific, and which one only relates to the producer. The typical 
use case of LINK is to only rewrite the provider part (or if no provider 
is included in the name, to "prepend" one).

A second remark then on the hash - this discussion belongs to the 
selector realm, not the "name realm" anyway. This is nicely visible in 
the tag given by CCNx1.0: HashRestriction. Same for "KeyID restriction" 
which addresses the producer.

So there is a pattern that restrictions relate to parts of what we 
usuall call "the name", given that the parts are identifiable. Once we 
have more structure in the "name", we could express also restrictions 
e.g. on the provider part (hey, has this been proposed already?) This is 
my point: The network can only work on restrictions if it understands 
more what is inside a name (PubSub already saw this direction). And 
because the USP of ICN is network empowerment (caching, selecting etc), 
I think that we need names with rich structure, not flat names.

best, c

PS: yes, I can't resist to point out named functions which only make 
sense when the network can parse non-flat names.

On Fri, 16 Oct 2015, Thompson, Jeff wrote:

> No contradiction from current practice. Here is an interest name that I just grabbed from the NDN test bed:
> "/ndn/edu/ucla/remap/ndnrtc/chat/remap/F6PCWlqWrV/1444850865/1". The prefix "/ndn/edu/ucla/remap/ndnrtc/chat/remap" is only useful to route
> the interest to the application. All the thousands of interests flying towards this application have the same prefix. The last part
> "F6PCWlqWrV/1444850865/1" only means something because the producer application told the consumer application to ask for it. This name in no
> way "self-describes" the object, so it is in effect "nameless" already from an outside observer. There is little difference if the producer
> application told the consumer application to ask for an object by hash. This is similar to how I understand the problematically-termed
> "nameless object": An object is requested in an interest with a routable prefix and another part (the hash) which the producer application
> told the consumer application to ask for.
> 
> - Jeff T
> 
> From: icnrg <[email-masked]> on behalf of Ravi Ravindran <[email-masked]>
> To: Dirk Kutscher <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]"
> <[email-masked]>, "[email-masked]" <[email-masked]>
> Agree that we shouldn’t mix the two semantics that of a ID and a Locator, they operate and are managed in two different domains, one at the
> application and the other at the network level. Also the notion of nameless  objects seems to contradict, when the basic primitive of ICN  is
> named data. All this comes by mixing the ID/locator definitions, resulting in Interest message carry locators which are supposed to be meant
> for persistent IDs; a clear separation of the two in the protocol will serve many purposes, manifests, mobility, routing scalability. Agree
> there are security implications like cache poisoning or exploitation use of these name separation and should be addressed considering the
> different trust context.
>
> 
> 
> Regards,
> 
> Ravi
>
> 
> 
> To: [email-masked]; [email-masked]; [email-masked]
> Not disagreeing, but: another way of seeing this is that entangling object identification, representation of organizational structure and
> location information in an aggregatable fashion in a single naming framework is likely to cause some headaches – and we are currently
> figuring out how to disentangle this again – with names hashes and nameless objects.
>
> 
> 
> We want to be able to connect a bunch of ICN nodes locally, e.g., in a building automation scenario, and address Interests to semantically
> meaningful names like “/jp/yokohama/pacifico/room123/light-switch42” and want the same concept and names to be useful for global-scale
> communication. This can only work with a few very strong assumptions: We can get inter-domain routing to work based on such names – and there
> is no  mobility.
>
> 
> 
> Obviously, flat naming schemes are facing similar problems. One pattern here is to use some organizationally structured part of the name to
> look up: locators (or location hints) – indirection…
>
> 
> 
> Dirk
>
> 
> 
> From: icnrg [mailto:[email-masked]] On Behalf Of [email-masked]
> To: [email-masked]; [email-masked]
> The Locator Hint or Link Object are proposed solutions to a big ICN/CCN/NDN problem, namely the misguided belief the name is independent of
> location.  This is a somewhat incorrect assumption if we also believe, at the same time, that the name is used for routing.  By definition,
> routing is location.
>
> 
> 
> Basically, what it’s saying is that if you retrieve something with the name /a/b with a link to /foo/bar  it can only be answered by an
> interest with the name /a/b and a link to /foo/bar.   Effectively, we are routing and matching /foo/bar/a/b when talking about object /a/b.
>  Disadvantage: A request for /a/b will not match the object (this would lead to cache poisoning)[1].  Advantage: The signature for /a/b (the
> object) can be done at a different level than the signature of /foo/bar/a/b (the link).
>
> 
> 
> The paper suggests verifying link objects. This is not sufficient to prevent poisoning.  I can have a valid link object (from an attacker)
> that brings me  an invalid content object.  If that content object is matched on name then poisoning will occur. The only way around this
> would be to have a reverse crypto mapping from the object name to the link object. (Like a signed content object + link object together from
> the content object’s key).
>
> 
> 
> The paper also mentions that caches can check signatures and consumers can use excludes to help with poisoning. This is unscalable for a
> number of reasons and probably deserves another thread.
>
> 
> 
> The current CCNx approach is to use hash based naming and objects with no names (only implied hashes). This allows us to get around many of
> these problems.  NDN could potentially use similar techniques (with or without the link object).
>
> 
> 
> Nacho
>
> 
>
> 
> 
> [email-masked]
> On 10/16/15, 12:22 AM, "Andrea Detti" <[email-masked]> wrote:
>
> 
>
>       Dear All,
>       Well, this email is just to point out that NDN team embraced the Locator Hint, aka Link Object, principles in their NFD software,
>       with a clever technique to avoid cache poisoning .
>
>       References:
>
>       On 01/09/2015 08:06 PM, [email-masked] wrote:
>
>       [email-masked]
>       On 1/9/15, 10:26 AM, "Andrea Detti" <[email-masked]> wrote:
>
>       On Jan 9, 2015, at 2:30 AM, Andrea Detti <[email-masked]>
>       wrote:
>
>       On 01/08/2015 06:00 PM, [email-masked] wrote:
>
>       <[email-masked]>
>       [email-masked]
>       [email-masked]
>       [email-masked]
>       [email-masked]
>       [email-masked]

---

From: Antonio Carzaniga <[email-masked]>
Date: Sat, 17 Oct 2015 19:25:31 +0200

I wonder what would be the advantage of an ICN architecture in which
names have no meaning or are tied to a network location.  Such an ICN
would not offer much beyond the current Web, and I don't believe that
that would be compelling or even helpful to application and network
designers.

So the question remains: how do we keep names meaningful and at the same
time obtain a scalable routing scheme?

As a first step I would suggest a divide and conquer approach.  In
particular, I think that the notion of "name" is overloaded in terms of
its functions within the network.  As is becoming clear from this
discussion, names serve at least three purposes.  They

   (1) describe objects for the purposes of applications;

   (2) locate objects within the network (i.e., routing/forwarding);

   (3) identify specific data chunks (e.g., for caching and transport);

CCN already distinguishes the third use from the other two by means of a
specialized header (content-hash), and Jeff's example shows that, in
practice, NDN names often combine a locator and an identifier.  But none
of these naming schemes go very far in combining expressiveness for
applications and scalable routing.  The next step would be to
disentangle the "descriptor" function from the "locator" function.

In other words, I am proposing an ICN with two forwarding functions:
forward-by-descriptor, and forward-by-locator.  Locators are
network-defined, and can be extremely efficient and compact for the
purpose of routing (and can also support mobility).  Descriptors are
application-defined, and therefore can be expressive and effective for
applications.

Of course, this is just a high-level design that, in and of itself, does
not immediately solve all our problems.  In fact, the scalability of
descriptor-based routing remains an open problem [1]. Still, I think it
would be a good step forward.

-Antonio

[1] We have already developed this idea a bit. See Papalini et al.
    "Scalable Routing for Tag-based Information-centric Networking", in
    ICN'14. (http://www.inf.usi.ch/carzaniga/papers/pckw_icn14.pdf)

---

From: Mark Stapp <[email-masked]>
Date: Mon, 19 Oct 2015 11:51:40 -0400

love this, Jeff - this is a very good point.

there seem to be folks who think that it will somehow be possible to 
make all application semantics so explicit in ICN names that "the 
network" will be able to make all applications work. if there are folks 
who think that there won't be any more applications, with their own 
servers and application protocol semantics, then those folks need to 
explain pretty crisply why they think that's a likely - or even remotely 
possible - outcome.

Thanks,
Mark

On 10/16/15 4:08 PM, Thompson, Jeff wrote:
> "/ndn/edu/ucla/remap/ndnrtc/chat/remap/F6PCWlqWrV/1444850865/1". The
> prefix "/ndn/edu/ucla/remap/ndnrtc/chat/remap" is only useful to route
> the interest to the application. All the thousands of interests flying
> towards this application have the same prefix. The last part
> "F6PCWlqWrV/1444850865/1" only means something because the producer
> application told the consumer application to ask for it. This name in no
> way "self-describes" the object, so it is in effect "nameless" already
> from an outside observer. There is little difference if the producer
> application told the consumer application to ask for an object by hash.
> This is similar to how I understand the problematically-termed "nameless
> object": An object is requested in an interest with a routable prefix
> and another part (the hash) which the producer application told the
> consumer application to ask for.
>
> - Jeff T
>

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Mon, 19 Oct 2015 11:59:19 -0400

Aren’t we getting back into the “name” vs. “context” discussion here? I am of the thinking that the app (or whatever these things will end up be named) gives the context. I do not think we can find explicit names for every sensor/switch/picture etc. with a global meaning - I am not even thinking of possibility but of practicability and the difficulty of finding and managing that namespace.

/mjm
> On Oct 19, 2015, at 11:51 AM, Mark Stapp <[email-masked]> wrote:
> 
> there seem to be folks who think that it will somehow be possible to make all application semantics so explicit in ICN names that "the network" will be able to make all applications work. if there are folks who think that there won't be any more applications, with their own servers and application protocol semantics, then those folks need to explain pretty crisply why they think that's a likely - or even remotely possible - outcome.
> 
> Thanks,
> Mark
>

---

From: Mark Stapp <[email-masked]>
Date: Mon, 19 Oct 2015 12:04:27 -0400

hmm ...

> that would be compelling or even helpful to application and network

there would/could be _lots_ of advantages resulting from stateful, 
multi-path forwarding and path symmetry: improved support for mobile 
nodes, "natural" support for network functions like CDNs and traffic 
engineering, absence of additional "required" services such as DNS, 
potentially improved ddos resistance, transport-agnostic reachability, 
improved support for constrained environments like IoT (where 
shoe-horning IPv6 is quite awkward), new API features, more effective 
explicit status and policy signalling within the network.

I totally don't buy the argument that there are no ICN benefits unless 
_everything_ in every ICN application is in the clear and in the name.

Thanks,
Mark

---

From: Antonio Carzaniga <[email-masked]>
Date: Mon, 19 Oct 2015 20:10:52 +0200

Hi Mark,

 | there would/could be _lots_ of advantages [...]

I agree that some of the things you mentioned would or could be
beneficial.  I still don't see a lot of benefits from the application's
perspective, which was the essence of my argument, but I admit that my
statement was perhaps a bit too strong ("[not] even helpful to
application and network designers.").

 | I totally don't buy the argument that there are no ICN benefits unless 
 | _everything_ in every ICN application is in the clear and in the name.

I most definitely agree with you here.  But I don't think that anyone
ever argued that _everything_ in every ICN application be in the clear
and in the name.  I certainly didn't.  What I argued is that names
should have *some* meaning, and that it should be possible for
applications to use location-independent names.  Without that--that is,
with only meaningless or location-dependent names--the whole idea of ICN
would not be very compelling, especially from the viewpoint of an
application developer.  And then I went on to propose an architecture
that attempts to combine application-defined names with scalable routing
by offering two separate and specialized routing functions, one based on
application-defined names and one based on network-defined locators.

I have to say, I am really surprised that the notion of meaningful and
location-independent names has become controversial in the ICN
community, considering that so many ICN papers describe the essence of
ICN in exactly those terms.  Van Jacobson et al. [CoNEXT'09] propose an
architecture that "[decouples] location from identity, security and
access."  They argue that "people value the Internet for *what* content
it contains, but communication is still in terms of *where*" and that
"mapping content to host locations complicates configuration as well as
implementation of network services," and therefore they propose "to
replace *where* with *what*" (emphasis in original).  And many other
authors make similar arguments.

-Antonio

---

From: Mark Stapp <[email-masked]>
Date: Mon, 19 Oct 2015 14:35:46 -0400

> application and network designers.").

ok, so pull on that thread for a bit. why do you think that applications 
care, particularly? I listed out some network properties that are 
largely infrastructural. applications currently don't know whether some 
part of the network path their traffic uses involves mpls tunnels. many 
OSes now offer application apis that hide IPv4-vs-IPv6 and DNS name 
resolution. are there many applications (outside special-purpose network 
monitoring or management) that know about BGP?

what is it that you think ICN will do for your application? if ICN 
offers you better infrastructure - better mobile client support, or 
better flow- and congestion-control behavior, or less trouble with NAT - 
isn't that valuable enough to be exploring it?

if application semantics don't have to matter to the transit network 
devices, then ... why make them matter? why not explore naming that 
makes networking work?

[...]

> .

umm - not really sure what to do with this. there are a number of 
problems that have arisen, and the "original" formulations have evolved. 
take a look at what the NDN folks have done over the last few years - 
they forward on "routing hints" rather than on object names, they 
brought DNS back in, etc etc. over time, the assertions that offer real 
insight will prove to be robust and helpful, and experiments will 
support them. the assertions that don't prove insightful will fade away. 
we should be testing and questioning and examining the assertions and 
formulations, not just quoting them back and forth at one another.

-- Mark

---

From: "Muhammad Hosain Abdollahi Sabet" <[email-masked]>
Date: Mon, 19 Oct 2015 22:04:14 +0330

Antonio,

 | Van Jacobson et al. [CoNEXT'09] propose an

That is true that _people_ care about _what_, but as Nacho mentioned earlier and I'm agree, _network_ values _routing_ and routing means _location_. Of course by location, we mean _topological_ location, but again we can't get around the notion of location.

I think the same argument can be used about the meaningfulness of names. When we say meaningful, we mean to whom? To people?

Thanks,
Sabet

-----Original Message-----
From: icnrg on behalf of Antonio Carzaniga
Sent: Mon 10/19/2015 9:40 PM
To: Mark Stapp
Cc: [email-masked]
Subject: Re: [icnrg] The myth of meaningful names
 
Hi Mark,

-Antonio

---

From: Antonio Carzaniga <[email-masked]>
Date: Mon, 19 Oct 2015 22:45:11 +0200

| That is true that _people_ care about _what_, but as Nacho mentioned
 | earlier and I'm agree, _network_ values _routing_ and routing means
 | _location_. Of course by location, we mean _topological_ location, but
 | again we can't get around the notion of location.

I agree, in part.  The theoretical results are clear: in general,
routing on what we call application-defined names or descriptors (or
name-dependent routing in theory parlance) is expensive.  However, it is
not impossible or absurd as a concept, and we also know that theoretical
complexity bounds are not always problematic in practice.  And arguably
descriptor-based routing is also beneficial (I'll just give this for
granted here).

So, we are left with an engineering question: can we engineer a network
in which the benefits of application-defined descriptors are worth the
costs of routing based on such descriptors?

I agree 100% that this remains an open question.  But I think that
avoiding the question -- that is, giving up descriptor-based routing
altogether -- also means giving up the essence of ICN.  My opinion.

In order to make progress without giving up descriptor-based routing, as
a first step, I was proposing to separate descriptors from locators: The
network provides two ways to address/route packets.  One with
application-defined descriptors, one network-defined locators.

 | I think the same argument can be used about the meaningfulness of
 | names. When we say meaningful, we mean to whom? To people?

I don't see this as the same argument, but okay.  Anyway, I'd say that
application-defined descriptors/names are meaningful to applications and
of course to the people who use those applications (but I'm not saying
that descriptors that enter the network have to be human-readable).

-Antonio

---

From: Antonio Carzaniga <[email-masked]>
Date: Tue, 20 Oct 2015 00:05:28 +0200

| > I agree that some of the things you mentioned would or could be
 | > beneficial.  I still don't see a lot of benefits from the application's
 | > perspective [...]
 | 
 | ok, so pull on that thread for a bit. why do you think that applications 
 | care, particularly? I listed out some network properties that are 
 | largely infrastructural. applications currently don't know whether some 
 | part of the network path their traffic uses involves mpls tunnels. many 
 | OSes now offer application apis that hide IPv4-vs-IPv6 and DNS name 
 | resolution. are there many applications (outside special-purpose network 
 | monitoring or management) that know about BGP?

right.  That's my point.  Applications don't care about BGP or other
infrastructural mechanisms and problems.  That is, an application
developer would not benefit much (not directly, at least) from an ICN
that improved only on infrastructural elements of the network.

 | what is it that you think ICN will do for your application?

it could provide a higher-level service.  Some people believe that the
network should be fully programmable (computationally complete) but
that's not my personal opinion.  Some people believe that the network
should provide stable storage for application data.  That isn't my
opinion either.  Still, I think that the network could offer a service
that would save applications from having to engineer (program, install,
configure, maintain) a whole bunch of middleware services.  I could be
very specific here and go on for hours talking about various flavors of
higher-level network services. (I've written a bit about this topic, if
you are interested.)  But I hope my point is clear enough.

 | if ICN offers you better infrastructure - better mobile client
 | support, or better flow- and congestion-control behavior, or less
 | trouble with NAT - isn't that valuable enough to be exploring it?

that would be good, of course.  For me, it wouldn't be so interesting
though, and it would really degrade the notion of ICN a bit too much.
My personal opinion and my personal taste for research problems.

 | if application semantics don't have to matter to the transit network 
 | devices, then ... why make them matter?

well... again, the point is that it might be beneficial to let the
network deal with *some* application semantics.

 | umm - not really sure what to do with this. there are a number of 
 | problems that have arisen, and the "original" formulations have evolved. 
[...]
 | the assertions that don't prove insightful will fade away. 

well, I agree with the general principle, but I don't agree on the
specific value judgment here.  I'm convinced that providing routing on
application-defined names is a good idea, and I'm still not convinced
that it's not feasible or not worth the cost.  Again, this is my
opinion, although I also have some evidence that some of what I describe
can be worked out.

 | we should be testing and questioning and examining the assertions and 
 | formulations, not just quoting them back and forth at one another.

oh, I agree 100% with you here: we should definitely examine and
question assertions and formulations.  Always!  In fact, I have been
examining and questioning those assertions and formulations since the
very beginning (and I'm not saying I was right!) and that is also what I
did with my original post: I questioned the mainstream addressing scheme
in ICN and pointed out an alternative.

-Antonio

---

From: [email-masked]
Date: Tue, 20 Oct 2015 12:22:38 +0200 (CEST)

Hi Mark,

between your defensive position and Antonio's ambition I easily choose 
Antonio's, but I don't think that we have to cast it in this 
confrontative way, the debate is more subtle.

The major contribution of ICN, how I see it, is that the NETWORK offers 
a lookup primitive that we know from DNS, as the basic way to interact 
with it, instead of datagrams: here is a name, please return the record 
attached to it.

The twist is that the network does not have to, but CAN help in offering 
this service. In the worst case it forwards the request "to the other 
end", or interferes in that process by serving from network memory.

I think you are righly defending this "network-pass-through" mode. It is 
the base line and requesting more might be asking too much. Wherefore 
you reject all stuff that looks middleware-ish.

But then there is the other side of permitting some nodes in the network 
to do better than pass-through. An important point from the "ambitious 
side" is that the current ICN lookup for an opaque name is not rich 
enough, driven by the conviction that the network should (be able to) do 
more and should assist distributed applications beyond transfering bits 
in pass-through mode. *)

Which is where names and their meaning comes into the picture. The 
current concatenation model for the name destroys information, which is 
one thing that the LINK tries to re-establish. It documents (to me) that 
one should have had, from the beginning, interests with more than one 
"name" entry (descriptors, locators, app-specific parts, ObjID, function 
name vs parameter name etc -- we do not know yet what the good set is). 
I would call this "structural meaning" and say that currently we do not 
have enough of it in "the name" that we pass to the lookup service 
request.

The semantic meaning of the bits, and whether these partial names are 
app or network chosen, is another consideration. Wrt the locator 
discussion which triggered this thread, I think that locators should NOT 
be chosen by the network but be true names, in the old CCN sense of 
topology independence and in the way it is used in LINKs, and maintain 
their anycast meaning. Otherwise we revert back to interface addresses. 
Perhaps we might have to distinguish different locator flavors?

So here is the discussion with you, Mark, and Antonio, but somehow and 
unexpectedly with inverted positions: If I understand right, you try to 
defend opaque (concatenated) names chosen by the producer, while Antonio 
seems to argue for structured names (descriptor+locator) and locators 
beeing network-chosen.

Obviously we are in plain discovery mode.

best, christian

*) Side note: Of course that's my "ambitious" interest in named 
functions. It does not have to be computationally complete, this power 
clearly has to be domesticated: Even RPC would be a big step into 
named-function land and a generalization of the DNS-style lookup.

---

From: "Muhammad Hosain Abdollahi Sabet" <[email-masked]>
Date: Tue, 20 Oct 2015 14:49:40 +0330

Hi Christian,

Actually the SNAMP proposal explicitly claims -though I'm not sure if it holds- that major amount of needed contents could be found and transferred locally, so there is no need to have extra information alongside the name from the beginning. BTW you can add this proposal to previously proposed set of extra information:

Scalable data replication in content-centric networking based on alias names
http://www.sciencedirect.com/science/article/pii/S1084804514002318

It introduces a _meta content instead of the Link object, and alias names as fetch terms. Maybe one way to have richer information  about the content (different flavor in your saying) is to have it somewhere other that the name itself, Although I guess this would widen available surface for attacks.

Thanks,
Sabet 

-----Original Message-----
From: icnrg on behalf of [email-masked]
Sent: Tue 10/20/2015 1:52 PM
To: Mark Stapp
Cc: Antonio Carzaniga; [email-masked]
Subject: Re: [icnrg] The myth of meaningful names
 
Hi Mark,

best, christian

---

From: Mark Stapp <[email-masked]>
Date: Tue, 20 Oct 2015 13:01:00 -0400

oof - have to reply to this one, Christian!

> confrontative way, the debate is more subtle.

hmm - I'm not sure I see the "ambition" in quoting Van at me? I think I 
said "there are lots of potential infrastructural benefits to ICN." is 
that really a controversial statement?

the debate about the details of names' routable prefixes may be subtle, 
but I don't think the debate about exposing users' activity in the clear 
or requiring routers to understand application semantics is subtle. at 
least IMO, the debate about in-the-clear activity is over, in the 
broader internet community anyway, and the ICN community should come to 
grips with that. one way to continue to make progress in ICN is to shift 
energy toward infrastructural capabilities.

that's what I was trying to support. I think Jeff T expressed it in a 
nice clear way - that it's not at all clear that ICN names name stable, 
consistent things called "objects". there are lots of applications and 
forms of network communication that do not have that kind of property. 
in fact some of the very applications that Van pointed to in the paper 
Antonio quoted at me don't work the way the paper claims they work.

> with it, instead of datagrams: here is a name, please return the record

interesting. I think DNS was introduced a long time ago, and has been 
forced to evolve in some significant ways over the decades. what you 
describe is not what DNS is like _now_, like right now. have you taken a 
look at how akamai, for instance, uses the DNS protocol? or taken a look 
at the work that DPRIVE is doing in the IETF?

we've learned that we can't trust "the network" in any of several 
dimensions. that knowledge has been hard-won. I think there's a clear 
emerging consensus that we should know with whom we're interacting, and 
that our interactions should be resistant to observation.

the ICN name really appears to be evolving to name a service, an 
application. the communication pattern is something like "I want to 
communicate with a service to accomplish something. I don't care about 
the endpoint address - I'm happy with multi-destination, multi-path 
service. I do care about authentication and privacy - I don't want to 
expose my activity with anyone but that service with which I have a 
relationship of some kind."

I'm all for continuing to try to forward on names - I don't favor 
re-introducing a name-resolving step. I don't think that the names will 
actually name "objects" or expose detailed semantics in the clear. and I 
don't think they need to, in order for there to be useful value in other 
aspects of an ICN network.

-- Mark

---

From: "Muhammad Hosain Abdollahi Sabet" <[email-masked]>
Date: Tue, 20 Oct 2015 21:14:12 +0330

Hi Mark,

   |the ICN name really appears to be evolving to name a service, an

So, you are suggesting that ICN community get around the very notion we've been calling _opportunistic caching_ over the last few years, am I right?

   |we've learned that we can't trust "the network" in any of several 
   dimensions. that knowledge has been hard-won. I think there's a clear 
   emerging consensus that we should know with whom we're interacting, and 
   that our interactions should be resistant to observation.

For having privacy, you think it is necessary to at least keep the network unaware as possible? Besides, don't you think if we are supposed to know whom we're interacting, we would get close to a contradiction with anycast-like nature of ICN?

Thanks,
Sabet

-----Original Message-----
From: icnrg on behalf of Mark Stapp
Sent: Tue 10/20/2015 8:31 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [icnrg] The myth of meaningful names

-- Mark

---

From: Mark Stapp <[email-masked]>
Date: Tue, 20 Oct 2015 15:29:21 -0400

Hi,

On 10/20/15 1:44 PM, Muhammad Hosain Abdollahi Sabet wrote:
> So, you are suggesting that ICN community get around the very notion
> we've been calling _opportunistic caching_ over the last few years, am I
> right?

yes - the "caching" thing has absorbed a great deal of ICN energy for 
years. and that's been part of what's led to some of the kinds of 
"naming" confusion that is in this thread. if you think you have to 
expose everything about your application activity so that "the network" 
can help you out somehow, then you're led down a path where you find 
yourself trying to figure out how to encode your messages (and 
especially the names) for maximum exposure.

> For having privacy, you think it is necessary to at least keep the
> network unaware as possible? Besides, don't you think if we are supposed
> to know whom we're interacting, we would get close to a contradiction
> with anycast-like nature of ICN?
>

I don't think we have to know (or care) about specific endpoints - any 
more than we do now, really, when we use the many distributed services 
we use every day. it's complicated to make these services work in IP - 
potentially more complicated than it has to be in ICN - but you're 
soaking in it right now. I do think we should expect to continue to have 
authentication, and expect to be able to use the internet without 
exposing the details of our interactions - or our application semantics. 
that seems to me to be a reasonable expectation, and to be technically 
feasible.

Thanks,
Mark

---

From: Andrea Detti <[email-masked]>
Date: Wed, 21 Oct 2015 09:41:00 +0200

Hi Mark,

+1 to your sentence "....it's complicated to make these services work in 
IP - potentially more complicated than it has to be in ICN"

In my academical experience of developing "real" ccn/ndn applications I 
found easier to design and develop network distributed applications by 
exploiting CCN/NDN API rather than TCP/IP or HTTP ones.

*Design,Development,Deployment (3D) simplicity* is a relevant value of 
ICN model in my opinion; clearly not the only one.

Regards,

Andrea

On 20/10/2015 21:29, Mark Stapp wrote:
> expose everything about your application activity so that "the 
> network" can help you out somehow, then you're led down a path where 
> you find yourself trying to figure out how to encode your messages 
> (and especially the names) for maximum exposure.
>
>>
> soaking in it right now. I do think we should expect to continue to 
> have authentication, and expect to be able to use the internet without 
> exposing the details of our interactions - or our application 
> semantics. that seems to me to be a reasonable expectation, and to be 
> technically feasible.
>
> Thanks,
> Mark
>

---

From: "Trossen, Dirk" <[email-masked]>
Date: Wed, 21 Oct 2015 08:41:46 +0000

Mark, all,

Chiming in here since it seems that there are two discussions conflated into one:
1. naming semantics in the clear is indeed controversial, to say the least. In the PURSUIT ICN efforts, we formulated the concept of algorithmic identifiers, which appeared opaque to any element not knowing the underlying algorithmic relation. It still 'encoded' semantics but didn't expose it 'in the clear'. However, this is not the real issue here, I feel, since such obfuscation is possible in NDN/CCN-like systems, too, and even desired for the reasons brought up here.

2. adding locator information to the name: I tend to agree with Antonio (and others)  that returning to the use of locators in the name abandons much of what ICN was touted as being superior at: locationless information. However, also here we have to be subtle.

Firstly, location-dependent naming in itself is nothing new and was even discussed in ICN scenarios since, simply, in some applications such location-dependence makes a lot of sense (in Dirk's light switch scenario, the application could choose to use the location semantic encoded in the name to provide country-specific adjustments). However, this is less about direct routing support but, again, about capturing semantics (either in algorithmic form or in the lesser desirable 'clear form').

Secondly, support for the routing fabric to deliver information is nothing new either but it is the question on how to achieve that goal, particularly when wanting to preserve total freedom for the application to name things/objects/information. In the PURSUIT ICN efforts, the (temporary) delivery relationship, utilized for forwarding information from a set of publishers to a set of subscribers, is kept separate from the 'name' of the information item. Hence, the closest to 'locators' in the current discussion is what PURSUIT calls 'forwarding identifiers' in contrast to its information identifiers. The reason for this separation is one of "separating concerns". PURSUIT did not want to impose the concerns of the routing provider, i.e., operator, on the application by constraining the way things/objects/information were called. You kept the locationless information identification and created temporary delivery relations with their own (routing/forwarding-specific) naming. The problem here might be to consolidate the (initial) discovery foundation for that with the 'routing-on-a-name' approach of CCN (although I would imagine that also a locator hint could be seen as something temporary and discovered at runtime - if I recall the NetInf/SAIL approach to this, I thought that it even was discovered at runtime but I might get that one wrong). Nonetheless, I wanted to mention this since some ICN efforts have thought about this separation and wanted to preserve it, albeit within a certain given architectural framework that the community might not want to adopt.

Best,

Dirk

Dirk Trossen
Principal Engineer
InterDigital UK, Inc.
Shoreditch Business Center
64 Great Eastern Street
London,  EC2A 3QR
T: +44 207.749.9178
[email-masked]
www.InterDigital.com<http://www.interdigital.com>

This e-mail is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and/or otherwise protected from disclosure to anyone other than its intended recipient. Unintended transmission shall not constitute waiver of any privilege or confidentiality obligation. If you received this communication in error, please do not review, copy or distribute it, notify me immediately by email, and delete the original message and any attachments. Unless expressly stated in this e-mail, nothing in this message or any attachment should be construed as a digital or electronic signature.

-----Original Message-----
From: icnrg [mailto:[email-masked]] On Behalf Of Mark Stapp
Sent: 20 October 2015 18:01
To: [email-masked]
Cc: [email-masked]
Subject: Re: [icnrg] The myth of meaningful names

> confrontative way, the debate is more subtle.

hmm - I'm not sure I see the "ambition" in quoting Van at me? I think I said "there are lots of potential infrastructural benefits to ICN." is that really a controversial statement?

the debate about the details of names' routable prefixes may be subtle, but I don't think the debate about exposing users' activity in the clear or requiring routers to understand application semantics is subtle. at least IMO, the debate about in-the-clear activity is over, in the broader internet community anyway, and the ICN community should come to grips with that. one way to continue to make progress in ICN is to shift energy toward infrastructural capabilities.

that's what I was trying to support. I think Jeff T expressed it in a nice clear way - that it's not at all clear that ICN names name stable, consistent things called "objects". there are lots of applications and forms of network communication that do not have that kind of property.
in fact some of the very applications that Van pointed to in the paper Antonio quoted at me don't work the way the paper claims they work.

> The major contribution of ICN, how I see it, is that the NETWORK
> offers a lookup primitive that we know from DNS, as the basic way to
> interact with it, instead of datagrams: here is a name, please return
> the record attached to it.
>

interesting. I think DNS was introduced a long time ago, and has been forced to evolve in some significant ways over the decades. what you describe is not what DNS is like _now_, like right now. have you taken a look at how akamai, for instance, uses the DNS protocol? or taken a look at the work that DPRIVE is doing in the IETF?

we've learned that we can't trust "the network" in any of several dimensions. that knowledge has been hard-won. I think there's a clear emerging consensus that we should know with whom we're interacting, and that our interactions should be resistant to observation.

the ICN name really appears to be evolving to name a service, an application. the communication pattern is something like "I want to communicate with a service to accomplish something. I don't care about the endpoint address - I'm happy with multi-destination, multi-path service. I do care about authentication and privacy - I don't want to expose my activity with anyone but that service with which I have a relationship of some kind."

I'm all for continuing to try to forward on names - I don't favor re-introducing a name-resolving step. I don't think that the names will actually name "objects" or expose detailed semantics in the clear. and I don't think they need to, in order for there to be useful value in other aspects of an ICN network.

-- Mark

---

From: "Trossen, Dirk" <[email-masked]>
Date: Wed, 21 Oct 2015 09:08:06 +0000

....and only now did I see Ravi's draft email on forwarding labels ;-) An interesting realization that this approach is finally discussed in the ICNRG.

Dirk

Dirk Trossen
Principal Engineer
InterDigital UK, Inc.

Reading this e-mail over mobile? InterDigital is a leader in developing and defining mobile networks and devices. Check it out at www.interdigital.com/vault<http://www.interdigital.com/vault>

-----Original Message-----
From: icnrg [mailto:[email-masked]] On Behalf Of Trossen, Dirk
Sent: 21 October 2015 09:42
To: Mark Stapp <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [icnrg] The myth of meaningful names

Mark, all,

Best,

Dirk

Dirk Trossen
Principal Engineer
InterDigital UK, Inc.

-----Original Message-----
From: icnrg [mailto:[email-masked]] On Behalf Of Mark Stapp
Sent: 20 October 2015 18:01
To: [email-masked]
Cc: [email-masked]
Subject: Re: [icnrg] The myth of meaningful names

-- Mark

---

From: Ravi Ravindran <[email-masked]>
Date: Thu, 22 Oct 2015 19:52:01 +0000

This a draft we had discussed many ICN-RGs back which proposed a naming scheme, which also discusses naming requirement, felt this would be a good input to the ID/Locator discussion during interim discussion.

https://tools.ietf.org/html/draft-zhang-icnrg-pid-naming-scheme-03

Regards,
Ravi

-----Original Message-----
From: icnrg [mailto:[email-masked]] On Behalf Of Trossen, Dirk
Sent: Wednesday, October 21, 2015 2:08 AM
To: Mark Stapp; [email-masked]
Cc: [email-masked]
Subject: Re: [icnrg] The myth of meaningful names

Dirk

Dirk Trossen
Principal Engineer
InterDigital UK, Inc.

-----Original Message-----
From: icnrg [mailto:[email-masked]] On Behalf Of Trossen, Dirk
Sent: 21 October 2015 09:42
To: Mark Stapp <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [icnrg] The myth of meaningful names

Mark, all,

Best,

Dirk

Dirk Trossen
Principal Engineer
InterDigital UK, Inc.

-----Original Message-----
From: icnrg [mailto:[email-masked]] On Behalf Of Mark Stapp
Sent: 20 October 2015 18:01
To: [email-masked]
Cc: [email-masked]
Subject: Re: [icnrg] The myth of meaningful names

-- Mark

---

From: Alan Cheilek <[email-masked]>
Date: Fri, 30 Oct 2015 18:35:27 +0000

Sorry to resurrect this old thread but I've been pondering some of these
naming issues as well and was away when it was active.

Is it useful to re-frame these naming issues in database lookup
terminology?  I'm by no means an expert in modern database mechanics but
will give it a try:

Let's suppose we are retrieving objects from a database based on name,
and call the ICN name a primary key.  We are restricting the key to be
strictly hierarchical, which is OK as far as it goes.  Does this then
leave our LINK or hash-based content names as secondary keys, or perhaps
as some form of index?

The same secondary key question comes up when we consider the data
objects themselves..  Are there applications which are using multiple
inheritance on their objects far down the hierarchy?  If so do they need
multiple names to refer to the "same" object depending on which path
through the hierarchy reached it?

Of course this line of thinking about the "network as database" takes me
farther afield into non-naming questions.  It wasn't so long after
database read was implemented that more complicated operations became
needed (set operations, join, and so on).  Is a network that has one
basic primitive (read) going to provide all the application
functionality that is expected today?

I'm afraid, as usual, more questions than answers...

-Alan