[Nfd-dev] [Ndn-app] Close NFD backdoor

Yingdi Yu yingdi at CS.UCLA.EDU
Tue Sep 9 08:39:08 PDT 2014


On Sep 9, 2014, at 4:17 AM, Dave Oran (oran) <oran at cisco.com> wrote:

> On Sep 8, 2014, at 6:21 PM, Yingdi Yu <yingdi at cs.ucla.edu> wrote:
> 
>> 
>> On Sep 8, 2014, at 12:58 PM, Dave Oran (oran) <oran at cisco.com> wrote:
>> 
>>> I don’t mean to hijack this thread, but it seems that the architecture needs two cache timers, not one.
>>> 
>>> One is an Expiry timer after which the data is no longer considered valid (and hence should not be returned from the cache if an interest arrives)
>> 
>> I am not sure if it is always possible for a data producer to predict the time when the data will become invalid.
> If not the producer, then who?

In many cases, no one knows. For example, you write an article, do you know when you will find some problem in it and change it?

> All data kept outside an application's private (and possibly permanent) store has a validity period, if not shorter then at least no longer than the lifetime of the key that signed it.

Yes, it is no longer than the lifetime of the key, but it could be shorter than that. As a producer, can you tell how shorter that could be?

>> Take DNS as an example, the authoritative server may never know when one of the records will be changed.
>> 
> Wrong analogy. A DNS Authoritative server is like a repo, a producer is in effect the application that updated the DNS.

Ok, then for the "producer" in your mind, can he predict when his DNS record will be changed? I never know when my own domain's A record will be changed, because my ISP occasionally change my home IP address.

Yingdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140909/5a53ce52/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140909/5a53ce52/attachment.bin>


More information about the Nfd-dev mailing list