[Ndn-interest] NDN Packet Spec

[Alex Afanasyev]

Hi Gordon,

Thanks for your questions and I have some answers inline:

> On Jun 12, 2015, at 6:24 PM, Gordon Irlam <gordoni at gordoni.com> wrote:
> 
> 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?

We had this definition initially, but decided that it is an unnecessary restriction.  There are cases when you would want to put implicit digest component in the middle of the name (e.g., when you do interest-in-interest encapsulation).  It these cases, the component will not be interpreted as such by the forwarder, but the specification (and therefore implementations) should allowed to define it as part of the name.

> 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.

I'm a little bit lost with your question.  Can you explain a little bit more which part is confusing?

> 
> 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?

We haven't yet defined any specific network-level semantics with KEY type.  However, given keys in NDN network may have more significant importance (i.e., multiple data packets could be signed with the same key), network-level can in theory prioritize data packets with KEY type.


> 4. Signature.
> 
>       Signature ::= SignatureInfo SignatureBits
> 
> SignatureBits is undefined. Should be:
> 
>       Signature ::= SignatureInfo SignatureValue

Thanks for noticing.  We'll fix this bug asap.

> 
> 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 for the suggestion.  We will discuss this issue during our next NFD call.

--
Alex

> 
> thanks,
> gordon

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20150612/422f7e07/attachment.bin>