<div dir="ltr">Dear folks<div><br></div><div>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:</div><div><ul><li>0x22 (34 in decimal) is both ByteOffsetNameComponent and HopLimit in the network layer.</li><li>0x24 (36 in decimal) is both TimestampNameComponent and ApplicationParameters in the network layer.</li></ul></div><div><a href="https://redmine.named-data.net/projects/ndn-tlv/wiki/NameComponentType">https://redmine.named-data.net/projects/ndn-tlv/wiki/NameComponentType</a><br></div><div><a href="https://named-data.net/doc/NDN-packet-spec/current/types.html">https://named-data.net/doc/NDN-packet-spec/current/types.html</a><br></div><div><br></div><div>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".</div><div>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.</div><div>I am strongly against this proposal.</div><div><br></div><div>First, TLV-TYPE numbers for name components and in the network layer are in distinct numbering space.</div><div>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.</div><div>In other words, this renumbering proposal "improves perceived cleanness", but does not solve a bug in the protocol.</div><div><br></div><div>Second, Naming Convention rev2 was published in 2019, and a number of applications have already adopted it.</div><div>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.</div><div>If the Naming Convention is changed once again, it would create one of two undesirable scenarios:</div><div><ul><li>I would have to re-encode all video packets.</li><li>I could stay with rev2 and not move to rev3. This causes my packets to become incompatible with tools such as ndncatchunks.</li></ul></div><div>I would be slightly less against this proposal, if it only renumbers 0x22 and 0x24, without changing number assignments of other name component types.</div><div><br></div><div>Yours, Junxiao</div></div>