[Ndn-interest] NDN Packet Spec

[Gordon Irlam]

Hi,

I'm new here. I was reading the NDN Packet Specification 0.2-alpha-2 and
had a few questions and comments.

1. The BNF for a Name allows an ImplictSha256DigestComponent to appear
other than at the end of a name:

    Name ::= NAME-TYPE TLV-LENGTH NameComponent*
    NameComponent ::= GenericNameComponent | ImplicitSha256DigestComponent

should probably make clear this is not actually allowed (or define the
semantics):

    Name ::= NAME-TYPE TLV-LENGTH GenericNameComponent*
ImplicitSha256DigestComponent?

2. Interest packet ChildSelector. "For example ... setting ChildSelector to
be 1 will retrieve the rightmost version number (i.e., the latest version)
and the leftmost segment number (i.e., the first segment)". I understand
why the rightmost version number is returned, but am not sure based on the
spec why the leftmost segment number (which is one past the version number)
will be returned.

3. Data packet Content type.  What network level semantics are associated
with content type KEY; why isn't it just another BLOB?  Can a LINK point to
a KEY or just a BLOB?

4. Signature.

      Signature ::= SignatureInfo SignatureBits

SignatureBits is undefined. Should be:

      Signature ::= SignatureInfo SignatureValue

5. Signature type DigestSha256. Cryptographic robustness isn't necessary
for integrity protection, and comes at great cost.  A quick test shows that
Sha256 only runs at around 250Mbytes/sec on a current generation single
core. Thanks in part to a special instruction on the same core, CRC32C runs
at around 24Gbytes/sec. The use case for dispensing with provenance
protection is likely to be the need for high performance. I would therefore
suggest considering adding CRC32C to the spec, and possibly removing
DigestSha256.

thanks,
gordon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20150612/c419c175/attachment.html>