[Ndn-interest] any comments on naming convention?

[Thompson, Jeff]

Hi Dave. You say:

> I¹ll note that the semantics and encoding of the typed name components
>needs to be (and is in the current proposal) done in such a way that
>simple byte-wise compares do the right thing for all of exact match, LPM,
> and anti-aliasing.

Do I understand correctly that byte-wise compare works for longest prefix
match because the type field of the TLV is fixed-length?  If NDN-TLV
adopts typed name components, would it also have to use a fixed-length
type encoding in order to preserve byte-wise compares?

- Jeff T

On 2014/9/16 6:35 AM, "Dave Oran (oran)" <oran at cisco.com> wrote:

>
>On Sep 16, 2014, at 5:12 AM, Massimo Gallo
><massimo.gallo at alcatel-lucent.com> wrote:
>
>> 
>> Dear all,
>> 
>> Interesting discussion!
>> 
>> Here are my 2 cents to the discussion.
>> 
>> I think we should avoid having explicit components' type.
>Below you seem to argue pretty much the opposite.
>
>> CCN/NDN are layer three technologies that allow an end host process to
>>retrieve some     named data. The networking layer does need only to
>>check local cache (exact match IMO), PIT (exact match IMO) and FIB (LPM,
>>I think we all agree on this :D!).
>I certainly wish we could agree on this change to the design, but I think
>it¹s premature to say we all agree that LPM on the PIT and CS has proven
>to be highly problematic.
>
>>  The way a "consumer" requests the next in order segment is up to the
>>transport layer as Tarek said and not a layer three functionality.
>Agree, but we¹re discussing the protocol encoding, not the fetch
>algorithm. Names as a data structure are ³shared² across multiple layers
>(a good thing IMO) and hence defining their semantics once as opposed to
>having different interpretaitons in different layers seems a good
>tradeoff, even it ³exposes² some things to layer 3 that are not strictly
>necessary for layer 3 operation and could be opaque. I¹ll note that the
>semantics and encoding of the typed name components needs to be (and is
>in the current proposal) done in such a way that simple byte-wise
>compares do the right thing for all of exact match, LPM,  and
>anti-aliasing.
>
>> Moreover, adding components' types may introduce problems as type
>>explosion (also pointed by someone else in this thread).
>Type explosion is a concern, but frankly is equally a problem no matter
>whether typing is done by convention, markers, or types. What
>distinguishes the option in my opinion is resilience against aliasing,
>for which I think explicit typing has substantial advantages.
>
>> 
>> That said there might be some "special" components requiring
>>conventions:
>> 
>> Segment: the most important one IMO because with that field many
>>segments can be identified as a single object and treated differently
>>for caching purposes. (i.e. a naming convention here can be that Segment
>>ID must be last name's component hence without an explicit segment
>>identification)
>> 
>Precisely. Which means all applications have to agree on a convention, or
>this needs to be ³baked² into the architecture somehow. There are
>multiple wats to do this, but typed name components seems utterly
>straightforward, and can leverage the exact registration policy and
>machinery that is used to control all architectural constants defined by
>the protocol.
>
>> Versioning and Timestamp: there might be a case for explicitly identify
>>those two components as suggested in the NDN-TR-22 but, IMO, too many
>>naming conventions will complexify layer three operations that I would
>>keep as simple as possible.
>> 
>As long as L3 can treat these as opaque and is not required to be
>cognizant of name component types, their existence does not complicate L3
>in any way.
>
>> Max
>> 
>> _______________________________________________
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>
>
>_______________________________________________
>Ndn-interest mailing list
>Ndn-interest at lists.cs.ucla.edu
>http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest