[Nfd-dev] Proposed NDN spec change

[Christos Papadopoulos]

At the heart of what we are discussing here is reasonable defaults. We 
should always pick those carefully, else we end up with strange failure 
modes. Defaults should result in the communication still working for 
most scanarios. Is leaving out this field the common case?

Having the absence of FreshnessPeriod mean "never fresh" (is this 
equivalent to "always stale"?) seems reasonable, but I worry about 
failure modes where someone carelessly leaves the optional field out and 
ends up in a situation that is hard to debug. This may happen if someone 
is trying to build a "thin" stack for embedded devices for example.

Would it make sense to make the field mandatory and use "zero" and "all 
ones" for "never fresh" and "always fresh"? Is the penalty of another 
mandatory field too high?

I am not advocating one or the other, I just want to see the discussion.

Christos.

On 07/01/2015 07:29 AM, Burke, Jeff wrote:
> Hi Junxiao,
> This makes sense to me if the convention is documented.
> Jeff
>
> From: Junxiao Shi
> Date: Monday, June 22, 2015 at 9:25 PM
> To: Jeff Burke
> Cc: Alex Afanasyev, "<nfd-dev at lists.cs.ucla.edu
> <mailto:nfd-dev at lists.cs.ucla.edu>>"
> Subject: Re: [Nfd-dev] Proposed NDN spec change
>
>     Hi Jeff
>
>     FreshnessPeriod is a nonNegativeInteger, whose upper bound is 2^64-1.
>     This upper bound value gives a FreshnessPeriod that is millions of
>     years, which is practically "always fresh".
>     It's unnecessary to have a special FreshnessPeriod value to indicate
>     "always fresh".
>
>     Yours, Junxiao
>
>     On Wed, Jun 10, 2015 at 9:27 PM, Burke, Jeff <jburke at remap.ucla.edu
>     <mailto:jburke at remap.ucla.edu>> wrote:
>
>         Would it make sense to provide a way to encode whether the
>         packet should be considered "always fresh" or "always stale"
>         explicitly?
>
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>