NFD

Answer to #2841 note-13:

Can we call "NdnlpHeaderExtension" a "Feature"?

No, they are distinct concepts.

A feature can have zero or more header extensions (and trailer extensions).

For example, indexed fragmentation feature defines two HeaderExtensions: NdnlpFragIndex and NdnlpFragCount.

Why don't we call "Nack" as "NackReason" or just "Reason". The description already calls it this way. For "DuplicataNack" and "GiveUpNack" I would lose "Nack" suffix. Why NACK reason should have "Nack" in it's name?

Agreed.

Why NdnlpPacket is assigned code 100 (0x64)?

This is to avoid clashing with NDNLP-TLV and LocalControlHeader, both of which use 80 as TLV-TYPE code for top-level element.

20150608 conference call reviewed revision 213b5818fefc773902728e66d5685cebf883f106.

Some comments are:

• The Ndnlp prefix on all types are unnecessary, because the design is in NDN context. However, Lp prefix should appear on some types, because the "namespace" of TLV-TYPE declarations is flat, and Lp is necessary to distinguish the type as part of NDNLPv2.
• Currently there are only 21 TLV-TYPEs reserved for link protocols, which would be insufficient according to the roadmap of NDNLPv2. We decide to reserve a block of TLV-TYPEs in 3-octet range for link protocols, and assign 3-octet codes to less common fields.
• The concept of HeaderExtension is confusing. It shall be renamed as HeaderField.
• It's unnecessary to let Sequence stand out. Instead, it could be one choice of HeaderField.
• HeaderFields under a header should be sorted in increasing TLV-TYPE order, so that there's only one way to encode a packet.
• NdnlpHeader and NdnlpTrailer wrappers are wasting octets. Those wrappers should be dropped, in favor of letting header and trailer fields appear directly under LpPacket struct.

Junxiao Shi wrote:

Question: should I change CachingPolicy header field to use a structure similar to Nack?

It would create consistency within the API. Does CachingPolicy need anything besides a non-negative integer to indicate the policy?

Answer to #2841 note-33:

I don't really like that you completely removed NackReason-specific elements in the spec. Why do you want to modify core parts of the specification (i.e., suddenly adding rules that Nack can actually contain multiple elements and define rules how to process those elements) instead of defining it just once upfront?

It's pointless to define something that won't be used.

We have decided not to define LpTrailerField until it's first used.
For the same reason, NackReason-specific elements won't be defined until it's first used.

Junxiao Shi wrote:

Question: should I change CachingPolicy header field to use a structure similar to Nack?

I don't have a strong preference, but leaning towards consistency (so, towards the change).

Spec is updated to revision 4893b3a6183b2751755cc2e9ee208c0c0bbfb8bc with NackReasons defined in #3032 note-2.