Original text:
and no trailing newline character. The party then hashes this string with the appropriate algorithm <del> based on the "hash_method" parameter under the "finish" key.  If the "hash_method" value is not present in the client instance's request, the algorithm defaults to "sha3". [[ See issue #56 [11] ]] </del>  <del> 4.2.3.1. </del>  <del> The "sha3" hash method consists of hashing the input string with the 512-bit SHA3 algorithm.  The byte array is then encoded using URL Safe Base64 with no padding RFC4648.  The resulting string is the hash value. </del>  <del> 4.2.3.2. </del>  <del> The "sha2" hash method consists of hashing the input string with the 512-bit SHA2 algorithm.  The byte array is then encoded using URL Safe Base64 with no padding RFC4648.  The resulting string is the </del>  hash value. 5. [10] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/78 <del> [11] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/56 </del>  [12] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/85

Reviewer comments:
To edit notification comments on pull requests, go to your ._
Receive a Callback After Interaction: Editor's note: This should be expandable via a registry of cryptographic options, and it would be good if we didn't define our own identifiers here. Calculating the interaction hash: Editor's note: These hash algorithms should be pluggable, and ideally we shouldn't redefine yet another crypto registry for this purpose, but I'm not convinced an appropriate one already exists. Furthermore, we should be following best practices here whether it's a plain hash, a keyed MAC, an HMAC, or some other form of cryptographic function. I'm not sure what the defaults and options ought to be, but SHA512 and SHA3 were picked based on what was available to early developers.
This is probably the right registry to reference: URL
Please add a changelog, but this looks good to me!

Revised text:
and no trailing newline character. The party then hashes this string with the appropriate algorithm  <ins> based on the "hash_method" parameter under the "finish" key.  The resulting byte array from the hash function is then encoded using URL-Safe Base64 with no padding RFC4648.  The resulting string is the hash value. </ins>  <ins> The "hash_method" value MUST be one of the hash name strings defined in the IANA Named Information Hash Algorithm Registry [11]. </ins>  <ins> If the "hash_method" value is not present in the client instance's request, the algorithm defaults to "sha3-512". </ins>  <ins> For example, the "sha3-512" hash method consists of hashing the input string with the 512-bit SHA3 algorithm.  The byte array is then encoded using URL-Safe Base64 with no padding RFC4648.  The resulting string is the hash value. </ins>  <ins> The "sha2-512" hash method consists of hashing the input string with the 512-bit SHA2 algorithm.  The byte array is then encoded using URL-Safe Base64 with no padding RFC4648.  The resulting string is the </ins> hash value. 5. [10] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/78  <ins> [11] https://www.iana.org/assignments/named-information/named- information.xhtml#hash-alg </ins> [12] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/85