[Ndn-interest] Renumbering name component types?

[Junxiao Shi]

Dear folks

In 2021-07-23 NFD call, it was brought up that several name component types
have the same TLV-TYPE number assignments as TLV elements in the network
layer:

   - 0x22 (34 in decimal) is both ByteOffsetNameComponent and HopLimit in
   the network layer.
   - 0x24 (36 in decimal) is both TimestampNameComponent
   and ApplicationParameters in the network layer.

https://redmine.named-data.net/projects/ndn-tlv/wiki/NameComponentType
https://named-data.net/doc/NDN-packet-spec/current/types.html

It was proposed that all of the name component types should be renumbered
to a different range, because "TLV-TYPE numbers for name components and
network layer should be unique".
Moreover, it was proposed that not only the above two conflicting numbers
should be moved, but also the other numbers in the currently assigned 0x20
~ 0x25 range.
I am strongly against this proposal.

First, TLV-TYPE numbers for name components and in the network layer are in
distinct numbering space.
They do not have an actual conflict in the protocol and implementations: a
packet parser is expected to know whether it is reading a name component or
not.
In other words, this renumbering proposal "improves perceived cleanness",
but does not solve a bug in the protocol.

Second, Naming Convention rev2 was published in 2019, and a number of
applications have already adopted it.
For example, I current operate the largest video streaming service on the
NDN testbed, and all the video packets have been encoded with TLV-TYPE
numbers specified in Naming Convention rev2, and in particular
0x23 VersionNameComponent and 0x21 SegmentNameComponent.
If the Naming Convention is changed once again, it would create one of two
undesirable scenarios:

   - I would have to re-encode all video packets.
   - I could stay with rev2 and not move to rev3. This causes my packets to
   become incompatible with tools such as ndncatchunks.

I would be slightly less against this proposal, if it only renumbers 0x22
and 0x24, without changing number assignments of other name component types.

Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20210723/e6f68989/attachment.html>