Summary: Has enough positions to pass.
Ballot question: "Is this the correct conflict review response?"
I'm happy to see this published as an RFC for use in IETF protocols! A few minor (editorial) notes that may be of use to the authors follow. [obligatory note that RFC 8174 provides an updated version of the BCP 14 boilerplate that fixes an erratum in the RFC 2119 boilerplate] Section 3.1 o Nonce S, which is a salt for password hashing applications. MUST have length not greater than 2^(32)-1 bytes. 16 bytes is RECOMMENDED for password hashing. Salt SHOULD be unique for each password. (nits) Probably s/Salt/S/, and it's surprising to see "length not greater than 2^(32)-1 bytes" in this point but "length from 0 to 2^(32) - 1 bytes" when they (IIUC) convey the same requirement on length. (The "not greater than" formulation is used several more times, later.) Section 3.2 with x being its output length in bytes. Here H^x() applied to string A is the BLAKE2b [BLAKE2] function, which takes (d,|dd|,kk=0,nn=x) as parameters where d is A padded to a multiple of 128 bytes and partitioned into 128-byte blocks. [...] Is "|dd|" a typo? I don't see 'dd' anywhere else in the document (though it is used internally in [BLAKE2]). Section 18.104.22.168 I see "LE64(s)" in the expression but the caption discusses "sl", the slice number. I suspect the expression should use "LE64(sl)". Section 3.5 I wonder if the phrase "row-major order" would be useful in describing the matrix layout. (Perhaps not, as the current description is unambiguous to a careful reader.)