[Ndn-interest] NDN Packet Format

[Michael Weiss]

Greetings everyone,

I welcome the decision to revisit the packet format [Spec0.1]. I'm 
probably missing some aspects, that are not discussed in that document, 
but here are my thoughts so far:

VAR-NUMBER: 64 bits for a length field matches the size used in many 
systems today but, given that the length is field is variable length 
anyway, I'd rather have he possibilty to use 128 bit length fields, too.

Interest packet: I have not thought too hard about the computational 
implications on this one but in general, I'd prefer to have all required 
fields before the optional fields and thus move to the nonce right after 
the name and before the selectors.

PublisherPublicKeyLocator: It has taken me some time to figure out how 
to handle colliding key names and the only solution I can come up with 
is to include the digest component in the key name. If that is the 
intended way, I suggest to be more explicit about it in the specification.
On a slightly related note, high on my wishlist for format/protocol 
redesigns is the ability to directly use public keys in place of digests 
or locators, especially since implementations with fast operations and 
256 bit public keys [NaCl] are available. Right next to that wish would 
be to use the packet format within signatures or any other complex data 
needed for the core protocols for that matter.

Now, to a more philosophical discussion: TLV
I'm not convinced that we need types at the structure level. Explicitly 
typed values can always be represented with one more level of nesting 
and a type-value pair inside. My recommendation is to use something 
semantically equivalent to S-expressions and work out an interchange 
format for use on the wire. The reasoning behind a typeless (beyond 
length and value) structure is that types in the structure itself 
require a high level of agreement and may hide computational complexity. 
Protocols would still be able to reuse type dictionaries from other 
protocols but that would not require coordination among all other 
protocols. Further, types can be omitted if protocols are precise about 
the set of fields on each level and their order. I argue that the 
inabilty to erase types is a sign of hidden complexity.
On a more practical note, my suggestion for such a format is to use 
Variable Length Values as used by MIDI for length fields, meaning one 
continuation bit and 7 bits of data in each octet in whatever bit and 
byte order the signaling folks among you favour. The minimum number of 
octets MUST be used to ensure uniqueness of representation. The null 
byte could then be used to represent omitted optional fields.
For more insight on the desire for simple exchange formats, I highly 
recommend watching "The Science of Insecurity" held on 28C3 and related 
material on http://langsec.org

Best wishes, m

[Spec0.1] http://named-data.net/wp-content/uploads/2013/11/packetformat.pdf
[NaCl] http://nacl.cr.yp.to/sign.html