<div dir="ltr">Hi,<br><br>I'm new here. I was reading the NDN Packet Specification 0.2-alpha-2 and had a few questions and comments.<br><br>1. The BNF for a Name allows an ImplictSha256DigestComponent to appear other than at the end of a name:<br><br>    Name ::= NAME-TYPE TLV-LENGTH NameComponent*<br>    NameComponent ::= GenericNameComponent | ImplicitSha256DigestComponent<br><br>should probably make clear this is not actually allowed (or define the semantics):<br><br>    Name ::= NAME-TYPE TLV-LENGTH GenericNameComponent* ImplicitSha256DigestComponent?<br><br>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.<br><br>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?<br><br>4. Signature.<br><br>      Signature ::= SignatureInfo SignatureBits<br><br>SignatureBits is undefined. Should be:<br><br>      Signature ::= SignatureInfo SignatureValue<br><br>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.<br><br>thanks,<br>gordon<br><br></div>