Just spent hours tracking down the "DOCSIS TLV" config-file format and implementing it.  This is one of those things where the project spec says "do what that spec says to do", pointing you at a deprecated version of the big spec, then the updated version of that spec says "do what this other spec says to do", but that spec is then defined in terms of 2 other specs... an enormous amount of reading to specify something that can be described in a tiny amount of code.

The key thing that gets left out AFAICS is that the spec is recursive; so for option 43.1, 43.2, or 43.3.4.5.2.3.4.5.6, for example, you do all of the encoding steps as though you were doing a top-level encoding for the various named (numbered) sub-options at each level, then you break the resulting (potentially very long) value into 255-byte chunks of top-level encodings.  For instance, our last example there with a value of 'hello' looks like:

[43,21,3,19,4,17,5,15,2,13,3,11,4,9,5,7,6,5,104,101,108,108,111]

Once you actually get all that, it's one of those relatively simple specs that likely should just be wrapped up in a standard library... but that would be hundreds of times more work than putting together something that can do what you need for this tiny project.

There are likely stupid little corner cases, such as whether to do splitting of long option-values only at the top-level, or whether you are intended to also split them in the recursive elements if an individual sub-element is > 255 chars.  There's also some checksums and the like, basically just some sha1 hashes.

The fact that you need lookup tables for all non-trivial interpretation makes the whole thing look way too messy to bother with beyond the needs of your clients of the day.  In the example above, unless you *know* that 43.3 has internal structure you can't parse the result meaningfully.  It might just as easily be a single long string.  The T (type) in TLV is just a single-byte-integer reference into the current table space, not a direct data-type value.  Those tables are vendor, and potentially even project, specific, so you then need to create a mechanism for users to define the tables... ick.  Makes one appreciate context-free formats all the more.