I know nothing about DRIP. I skimmed RFC 9153 and the suggested draft. Take thesze comments with appropriate skepticism. ASTM needs to be expanded. Are "pages" basically packets? A confirmation/explanation, perhaps in the definitions section would help. The definitions points to drip-requirements draft, but then documents "aircraft"? Really? :) There are far too many one-paragraph sections. Come up with broader titles and merge things a bit; I think it will read better. I know kthis is not a trivial amount of work. Sec 3.3.1: the bit numbering is opposite of what I'm used to (i.e., 31->0, this is 0->31). This holds for all other ascii-art protocol blocks. Consider breaking up the top byte into two nibbles AH and PH Pad out AuthType into Sec 3.3.2 the constraints/requirements should be first. Sec 4.1.2.1 Put spaces between the logical parts of the bytes: 12 50098960bf8c0504200100100 0a00145aac6b00abba268b7 Is that correct? Why only the last 23? Maybe I am missing some other checksum, or don't know enough about Reed-Solomon. Sec 5, "UNIX timestamp offset by ..." you mean Unix-style timestamp but with an epoch of ... right? Is the "UA signature" defined somewhere? Same question about the signatures in Sec 6, etc. Related question, where are the algorithms for the "Message Hash" and other hashes within the doc defined? Should be a forward reference. Or worse, it's an external reference? Sec 6.3.5.1 "multiplexing" seems out of place. General comment, putting all limitations, constraints, requirements, etc., should be up front. Is Appendix A useful here? I don't see how. The sample messages in C do not seem useful, as they seem to be repeating just the packet layouts. I do not understand what the "Hex" values in C.3 mean and there seems to be no way to re-compute/verify them.