Reviewer: Carl Wallace Review result: Has Nits This is a very well written document. A few minor comments are below. In section 4.3, the language for Key or Key Length and Counter or Counter Length is a little difficult to parse. Dropping the commas around "minus one" would help or maybe splitting into two sentences. "If the X flag is set to 0, this field contains the Key ID. Else, this field contains the key ID length minus one." In 4.4, the section title should probably be Encryption Scheme. In 4.4.1, the first sentence of the fifth paragraph should start "A given base_key MUST NOT be used...". There may be a few other places where "key" is used where "base_key" would be more clear (like the "Adding a key for sending", etc. in the example API, in the title of section 4.4.1, etc.). In 4.4.2, there is a typo - encrytion. Throughout, it may be worth indicating which pseudocode method names are not expanded upon in the draft, i.e., encode_big_endian, encode_sframe_header. Maybe prepend with an underscore and note that practice. In table 1, given Nk is used as a table header, it may be best to introduce the composite key notion in section 4.4 (even if only via a forward reference to 4.5.1). It's a bit confusing on a first read to see 48 for the first three rows on a first read. Maybe defining Nka in 4.4.4 would be sufficient. In section 9.1, if only one sender can use a base_key for encryption, why is the KID noted as important to avoiding reuse of (base_key, KID, CTR) combinations? Is the assignment of KIDs to ensure KID values are unique across set of senders in addition to unique base_key values? -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
