Authors and *Eliot (ISE), While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the source file.
* Eliot, please review question #3 and let us know if you approve. 1) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on <https://www.rfc-editor.org/search>. --> 2) <!-- [rfced] Abbreviations: a) Per Section 3.6 of RFC 7322 ("RFC Style Guide" (https://www.rfc-editor.org/info/rfc7322)), we expanded "MAC" where first used. Please let us know any concerns. Currently: Their good dispersion makes them particularly well suited for hashing nearly identical strings, including URLs, hostnames, filenames, text, and IP and Media Access Control (MAC) addresses. b) For ease of the reader, should the following abbreviations also be defined? If yes, please provide the correct definitions. MASS IDE (We see "IDE" defined as "Integrated Development Environments" in [fasmlab].) BFD (perhaps "Bidirectional Forwarding Detection"?) --> 3) <!-- [rfced] [ISE] Questions for the ISE: a) Because the original Section 1.1 contains the key word "NOT RECOMMENDED", we (1) prepended the existing Section 1.1 with a new Section 1.1 with the title "Conventions Used in This Document", (2) added the typical boilerplate text, and (3) added entries for RFCs 2119 and 8174 to the Normative References section. Please let us know any concerns. b) May we list the years in the copyright notices within all of the code components (17 instances) as "2016-2025" per guidance from our legal counsel? One example Original: /* Copyright (c) 2016, 2024, 2025 IETF Trust and the persons * identified as authors of the code. All rights reserved. Perhaps: /* Copyright (c) 2016-2025 IETF Trust and the persons * identified as authors of the code. All rights reserved. --> 4) <!-- [rfced] Sections 1.1 and subsequent: Do the instances of "2**" in running text (seven, by our count) indicate superscripted numbers? If yes, would you like us to apply the <sup> (superscript) element, even though the artwork and sourcecode will still use the "**"s? Original: ... collisions among the hashes of more than 2**N distinct inputs. And if the hash function can produce hashes covering all 2**N possible ... also a power of 2, in particular n = 2**s. For each such n-bit FNV ... bits in it: one relatively high order one bit, the 2**9 bit, and 4 or ... hash size S such that 2**S > max. Then, calculate the following: ... from a bias against large values with the bias being larger if 2**S ... arithmetic mod 2**HashSize. --> 5) <!-- [rfced] Section 1.1: We found this sentence difficult to follow. We updated it as noted below. If this is incorrect, please provide clarifying text. Original: FNV is NOT RECOMMENDED for any application that requires that it be computationally infeasible to succeed in one of the above attacks. Currently: FNV is NOT RECOMMENDED for any application that requires that it be computationally infeasible for one of the above types of attacks to succeed. --> 6) <!-- [rfced] Section 1.2: Will "libketama" be clear to readers? Would it be helpful to also cite <https://www.metabrew.com/article/ libketama-consistent-hashing-algo-memcached-clients> ("libketama: Consistent Hashing library for memcached clients") here and list it in the Informative References section? We ask because we don't see "libketama" mentioned on the [memcache] page. Original: * used in an implementation of libketama for use in items such as [memcache], --> 7) <!-- [rfced] Section 1.2 and Informative References: As the cited page does not mention "libstr" and shows "Standard Incident Reporter library" at the top of the page, we changed "libstr" to "libsir" accordingly. Please let us know any concerns. Also, for the reference entry, we could not identify "Lederman, R." at <https://github.com/aremmell/libsir>, and we were unsure if "RML aremmell" is the same person. Please let us know if any further updates are needed. Original: * the libstr logging library [libstr], ... [libstr] Lederman, R. and J. Johnson, "libstr logging library", <https://github.com/aremmell/libsir>. Currently: * the libsir logging library [libsir], ... [libsir] Lederman, R. and J. Johnson, "libsir logging library", commit 0ae0173, 3 December 2025, <https://github.com/aremmell/libsir>. --> 8) <!-- [rfced] Section 1.2: We had trouble following these sentences. If the suggested text is not correct, please clarify. Please note that [BFDseq] underwent significant changes since March 2022 and no longer mentions FNV, so we took that into account in the suggested text. If the suggested text is incorrect, please let us know how this text should be updated. Original: A study has recommended FNV in connection with the IPv6 Flow Label field [IPv6flow]. Additionally, there was a proposal to use FNV for BFD sequence number generation [BFDseq] and a recent article and study on non-cryptographic hash functions [NCHF]. Suggested: [IPv6flow] researched and recommended using 32-bit FNV1a in connection with the IPv6 flow label value. Additionally, [ISAAC-Auth] proposes the use of Indirection, Shift, Accumulate, Add, and Count (ISAAC) as a means of BFD sequence number generation, and [NCHF] discusses criteria for evaluating non-cryptographic hash functions. --> 9) <!-- [rfced] Section 1.2: Please confirm that <[email protected]> is still a valid, working email address. Original: If you use an FNV function in an application, you are kindly requested to send an EMail about it to <[email protected]> with "FNV hash function" forming part of the subject line. --> 10) <!-- [rfced] <sourcecode> entries: Please review the sourcecode-type settings in this document, and please refer to <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types> for the list of approved types. Please note that we changed 'type="C"' to 'type="c"' per the sourcecode-types page. Also, please note that "makefile" is not included on the sourcecode-types page. Does the page contain an acceptable substitute that you could use? If not, it's fine to leave the "type" attribute unset. Another option: If the sourcecode-types page does not contain an applicable type, please let us know if you would like us to request that additional sourcecode types (e.g., "makefile") be approved and listed on the sourcecode-types page. (As noted above, it's also fine to leave the "type" attribute unset.) Also, please let us know whether any artwork elements should be marked as sourcecode; if yes, please provide the sourcecode type. --> 11) <!-- [rfced] Section 2.1: Is "criteria" used in the singular here (as currently indicated by "is more complex"), or is it used to indicate more than one criterion (in which case "is more complex" should be "are more complex")? Original: The case where s > 10 is not considered because of the doubtful utility of such large FNV hashes and because the criteria for such large FNV_Primes is more complex, due to the sparsity of such large primes, and would needlessly clutter the criteria given above. --> 12) <!-- [rfced] Section 2.2: Is the offset_basis sometimes the hash output, or always? If neither suggestion below is correct, please clarify. Original: Any entity that can observe the FNV hash output, and can cause the null string (the string of length zero) to be hashed, will thereby be able to directly observe the offset_basis which will be the hash output. Suggestion #1 (sometimes): Any entity that can observe the FNV hash output, and can cause the null string (the string of length zero) to be hashed, will thereby be able to directly observe the offset_basis that will be the hash output. Suggestion #2 (always): Any entity that can observe the FNV hash output, and can cause the null string (the string of length zero) to be hashed, will thereby be able to directly observe the offset_basis, which will be the hash output. --> 13) <!-- [rfced] Section 2.3: We do not see any code provided in Section 6 ("Security Considerations"). Please let us know which section should be cited here. Original: The code provided in Section 6 has FNV hash functions that return a little endian byte vector for all lengths. --> 14) <!-- [rfced] Section 4: We had trouble parsing this sentence - in particular, the "and ... or" relationships. Will this sentence be clear to readers as written? Original: For FNV, the same hash results if X, Y, and Z are actually concatenated and the FNV hash applied to the resulting string or if FNV is calculated on an initial substring and the result used as the offset_basis when calculating the FNV hash of the remainder of the string. Possibly: For FNV, the same hash results if 1) X, Y, and Z are actually concatenated and the FNV hash is applied to the resulting string or 2) FNV is calculated on an initial substring and the result is used as the offset_basis when calculating the FNV hash of the remainder of the string. --> 15) <!-- [rfced] Section 4: We only see one mention of the idea of "flow ID" in RFC 6437 ("a stateless method of flow identification and label assignment") but quite a few instances of "Flow Label" and "flow label" (and one instance of "Flow label"). Should "flow ID" and "Flow ID" be "flow label" or "Flow Label" here? Original: For example, assume some sort of computer network traffic flow ID, such as the IPv6 flow ID [RFC6437], is to be calculated for network packets based on the source and destination IPv6 address and the Traffic Class [RFC8200]. If the Flow ID is calculated in the originating host, the source IPv6 address would likely always be the same or perhaps assume one of a very small number of values. --> 16) <!-- [rfced] Section 6.1: Is a Routing Information Base the only source of routing information (in which case "i.e.," is correct), or is it an example of a source of routing information (in which case "e.g.," should be used here instead)? Original: Such an arrangement might be used for the symbol table in a compiler or for some of the routing information (i.e., RIB (Routing Information Base)) in a router. --> 17) <!-- [rfced] Section 6.1: As it appears to us that "occur, or service is degraded" means "occur or when service is degraded" as opposed to "occur or if service is degraded", we updated this sentence accordingly. If this is incorrect, please provide clarifying text. Original: * If the adversary cannot detect when collisions occur, or service is degraded, then it is sufficient for the adversary to be unable to predict the hash outcomes. Currently: * If the adversary cannot detect when collisions occur or when service is degraded, then it is sufficient for the adversary to be unable to predict the hash outcomes. --> 18) <!-- [rfced] Section 7: We found the citation for [IEEE] confusing, as we could not readily locate information on the IEEE POSIX P1003.2 committee when searching [IEEE]. Also, in a general web search, we saw a reference to a September 1991 draft (https://mirror.math.princeton.edu/pub/oldlinux/Linux.old/ Ref-docs/POSIX/all.pdf) and a 1992 paper (https://standards.ieee.org/ieee/1003.2/1408/). Will this text and citation be clear to readers? Original: The FNV hash algorithm originated from an idea submitted as reviewer comments to the [IEEE] POSIX P1003.2 committee in 1991 by Glenn Fowler and Phong Vo. --> 19) <!-- [rfced] Section 8.1.1: Should "Base" be "Basis" for these entries? We don't see "Base" used anywhere else in comparable parameter names (e.g., "FNV64stringBasis", "FNV32blockBasis" as used later). Original: FNVxxxstringBase, FNVxxxblockBase, FNVxxxfileBase: ... FNVxxxINTstringBase, FNVxxxINTblockBase, FNVxxxINTfileBase: ... The functions whose name has the "Base" suffix take an additional parameter specifying the offset_basis. --> 20) <!-- [rfced] Section 8.1.1: The following four entries don't seem to have any descriptive information below them. We also see that the first three entries are contained in an <artwork> element but the fourth entry is part of the description list. Will the use/purpose of these four entries be clear to readers, or should all of them have definitions and be part of the same definition list? Original: FNVxxxstring, FNVxxxblock, FNVxxxfile: FNVxxxstringBase, FNVxxxblockBase, FNVxxxfileBase: FNVxxxINTstring, FNVxxxINTblock, FNVxxxINTfile: ... FNVxxxinit, FNVxxxinitBasis: --> 21) <!-- [rfced] Section 8.1.2: Does "a command line invoking compilation" mean "a compilation that invokes a command line" or "a command line invoking a compilation"? Original: By default, this is set in FNVconfig.h based on the compilation target; however, this can be overridden by editing that file or by defining certain symbols in, for example, a command line invoking compilation. --> 22) <!-- [rfced] Section 8.1.2: We had trouble following these sentences. We updated them as follows. If these updates are incorrect, please clarify the text. Original: For support of a single FNV size, say "xxx", in an application, the application itself needs to include the FNVxxx.h (which will, in turn, include the FNVconfig.h and FNVErrorCodes.h) files. To build the particular FNVxxx code itself, compile the FNVxxx.c file with FNVconfig.h, fnv-private.h, FNVErrorCodes.h, and FNVxxx.h available. Currently: For support of a single FNV size, say "xxx" (e.g., FNV64), in an application, the application itself needs to include the appropriate FNVxxx.h file (which will, in turn, include the FNVconfig.h and FNVErrorCodes.h files). To build the particular FNVxxx code itself, compile the FNVxxx.c file with FNVconfig.h, fnv-private.h, FNVErrorCodes.h, and FNVxxx.h (available in Section 8.2). --> 23) <!-- [rfced] Sections 8.2 and subsequent: We changed instances of "RFC NNNN" to "RFC 9923". Please let us know any concerns. --> 24) <!-- [rfced] Sections 8.2.1 and subsequent: Does "a specified length byte vector" mean "a specified 'length byte vector'", "a byte vector of specified length", or something else? We ask because we see text such as "4-byte vector" and "the same size byte vectors" used elsewhere. Please clarify. Examples from original: * FNV32block: hash a specified length byte vector ... * FNV32blockin: hash in a specified length byte vector ... * FNV32INTblock: hash a specified length byte vector ... * FNV64block: hash a specified length byte vector --> 25) <!-- [rfced] Sections 8.2.1 and subsequent: Do instances of "FNV32 hash a ...", "FNV64 hash a", etc. mean "FNV32-hash a ...", "FNV64-hash a", etc. (i.e., to indicate verbs), or do they mean "FNV32: Hash a ...", "FNV64: Hash a", etc. (to indicate instructions, e.g., per "Hash the contents of the file" in Section 8.1.3)? Examples from original: /* FNV32 hash a zero-terminated string not including the zero ... /* FNV64 hash a zero-terminated string not including the zero ... * FNV64string: hash a zero-terminated string not including ... * FNV32block: hash a specified length byte vector ... * FNV32blockin: hash in a specified length byte vector --> 26) <!-- [rfced] Sections 8.2.2 and subsequent: Please note that we removed or added spaces in the following code items. Original (these are most of the items that we modified): int error; (2 instances) int rc; FNV128context ctx; ( memcmp ( was, should, N) != 0 ) (uint8_t *)0 , (we only found one instance of a space before a comma, so we removed the space here) TestR ( "result2", fnvNull, RSLT ( &CTX, (uint8_t *)0 ) ); FNV128result ( &e128Context, hash ) ); TestR ( "result3i", fnvStateError, RSLTINT ( &ctx, &INTV ) ); The spacing changes can be seen in the latest rfc9923-rfcdiff file. Please let us know if you do not agree with these changes, and we will revert them. Please also note that we did not make any changes to Stefan Santesson's code, as we consider it "Do Not Edit" (DNE) and have flagged it as such in the XML file. --> 27) <!-- [rfced] Section 8.2.2: Please review the items listed under "Function Prototypes:" and under the "Hash is returned as an 8-byte vector by the functions above. If 64-bit integers are supported" text in this section. Because it appears that the focus here is on "FNV64" parameters and there may have been some copy-paste issues in this section, please review the following, and advise: a) Because it appears that "FNV164stringBasis" should be "FNV64stringBasis", we updated accordingly. Please let us know if this is incorrect. Original: * FNV164stringBasis: also takes an offset_basis parameter Currently: * FNV64stringBasis: also takes an offset_basis parameter b) It appears that "FNV128fileBasis" and "FNV128filein" should be "FNV64fileBasis" and "FNV64filein". May we update accordingly? Original: * FNV64file: hash the contents of a file * FNV128fileBasis: also takes an offset_basis parameter * * FNV64init: initializes an FNV64 context * FNV64initBasis: initializes an FNV64 context with a * provided 8-byte vector basis * FNV64blockin: hash in a specified length byte vector * FNV64stringin: hash in a zero-terminated string not * including the terminating zero * FNV128filein: hash in the contents of a file * FNV64result: returns the hash value c) It appears that "FNV32INTstringBasis", "FNV32INTblockBasis", and "FNV32INTfileBasis" should be "FNV64INTstringBasis", "FNV64INTblockBasis", and "FNV64INTfileBasis". Should we update accordingly? Original: * FNV64INTstring: hash a zero-terminated string not including * the terminating zero * FNV32INTstringBasis: also takes an offset_basis parameter * * FNV64INTblock: hash a specified length byte vector * FNV32INTblockBasis: also takes an offset_basis parameter * * FNV64INTfile: hash the contents of a file * FNV32INTfileBasis: also takes an offset_basis parameter * * FNV64INTinitBasis: initializes an FNV32 context with a * provided 64-bit integer basis d) Should "FNV64INTinitBasis: initializes an FNV32 context" be "FNV64INTinitBasis: initializes an FNV64 context"? Original: FNV64INTinitBasis: initializes an FNV32 context with a --> 28) <!-- [rfced] Section 8.2.2: Does "Null input/out pointer" mean "Null input/output pointer", "Null input pointer /out pointer", or something else? Original: return fnvNull; /* Null input/out pointer */ --> 29) <!-- [rfced] Sections 8.2.3, 8.2.4, 8.2.5, and 8.2.6: Please review the following, and let us know if any changes are needed: a) Please confirm that the same text - "Hash is returned as an array of 8-bit unsigned integers" - is correct for all four sections. We ask because of "Hash is returned as a 4-byte vector by the functions above, and the following return a 32-bit unsigned integer" in Section 8.2.1 ("FNV32 Code"). b) Please search for instances of "This structure holds context information for an FNV", and let us know if the data that follows these lines is correct. The first and second instances appear to be OK, but we want to confirm that the data that follows the third, fourth, fifth, and sixth instances are also OK (i.e., should always indicate 64-bit integers; apologies if we are missing a statement that says support for 64-bit integers applies to all FNVs discussed in this document). c) Please search for instances of "version if", and confirm that the text should always be "version if 64-bit ...". --> 30) <!-- [rfced] Sections 8.2.4, 8.2.5, and 8.2.6: As it appeared that "FNV246stgringBasis", "FMNV512filein", and "FMV1024fileBasis" should be "FNV256stringBasis", "FNV512filein", and "FNV1024fileBasis", respectively, we updated accordingly. Please let us know if anything is incorrect. Original: * FNV246stgringBasis: also takes an offset_basis parameter ... * FMNV512filein: hash in the contents of a file ... } /* end FMV1024fileBasis */ Currently: * FNV256stringBasis: also takes an offset_basis parameter ... * FNV512filein: hash in the contents of a file ... } /* end FNV1024fileBasis */ --> 31) <!-- [rfced] Sections 8.2.4 and 8.2.6: Are these two extra lowercase "version for when you only have 32-bit arithmetic" entries still needed in this document? We ask because a "START VERSION FOR WHEN YOU ONLY HAVE 32-BIT ARITHMETIC" entry immediately precedes both of these lowercased entries, and the other three "START VERSION FOR WHEN YOU ONLY HAVE 32-BIT ARITHMETIC" entries (Sections 8.2.2, 8.2.3, and 8.2.5) don't have this extra entry. Original: /* version for when you only have 32-bit arithmetic ... /* version for when you only have 32-bit arithmetic --> 32) <!-- [rfced] Section 8.2.5: Should the two instances of "FNV1024 context" be "FNV512 context" in these lines, and should "128-byte" be "64-byte"? Original: * FNV512init: initializes an FNV1024 context * FNV512initBasis: initializes an FNV1024 context with a * provided 128-byte vector basis --> 33) <!-- [rfced] Section 8.3: a) Should the two instances of "follow by" be "followed by"? If no, are they instructions and some words are missing (e.g., "follow the ______ by size of ...")? We ask because of "case 'f': // followed by name of file to hash" a few lines earlier. Original: case 't': // follow by size of FNV to test, 0->all ... case 'u': // follow by size of FNV to use b) Should the spacing be adjusted here as suggested? Original: FNV32INTfile ( WriteTemp(teststring[i], iLen), &eUint32 ) ); ... FNV64INTfile ( WriteTemp(teststring[i], iLen), &eUint64 ) ); Suggested: FNV32INTfile ( WriteTemp(teststring[i], iLen), &eUint32 ) ); ... FNV64INTfile ( WriteTemp(teststring[i], iLen), &eUint64 ) ); --> 34) <!-- [rfced] Section 8.4: Would you like to order the list of .c files by FNV size (and by their placement in the body of the document), as was done for the "HDR=" line? We have the same question re. the list of .h files in the <TAB> line. Original: SRC=FNV1024.c FNV128.c FNV256.c FNV32.c FNV512.c FNV64.c ... <TAB>FNVErrorCodes.h FNVconfig.h fnv-private.h Possibly: SRC=FNV32.c FNV64.c FNV128.c FNV256.c FNV512.c FNV1024.c ... <TAB>FNVconfig.h FNVErrorCodes.h fnv-private.h --> 35) <!-- [rfced] References: We do not see David Bell mentioned on the page provided for [calc]. Please confirm that this listing is correct. Original: [calc] Bell, D. and L. Noll, "Calc - C-style arbitrary precision calculator", <http://www.isthe.com/chongo/tech/comp/calc/index.html>. --> 36) <!-- [rfced] References: The provided link for [Cohesia] steers to <https://cohesia.com/>, which is a business financing site. We could not find a relationship to the bullet item in Section 1.2. Should a different website be listed here? Original: * [Cohesia] MASS project server collision avoidance, ... [Cohesia] Cohesia, "Cohesia website", <http://www.cohesia.com/>. --> 37) <!-- [rfced] References: We see "NOTICE (2022-10-16): ...", re. a new server, at the top of the provided page for [deliantra]. Should this listing be updated to reflect the notice or was this a temporary situation that no longer applies? Original: [deliantra] The Deliantra Team, "Deliantra MMORPG", 2016, <http://www.deliantra.net/>. Possibly (if the notice is still relevant): [deliantra] The Deliantra Team, "Deliantra MMORPG", 16 October 2022, <http://www.deliantra.net/>. --> 38) <!-- [rfced] References: Would you like us to change "Fowler-Noll-Vo" in the listing for [FNV] to "Fowler, G., Noll, L., and Vo, K." or perhaps "Noll, L."? Is "Fowler-Noll-Vo" considered an organization in this case? Original: [FNV] Fowler-Noll-Vo, "FNV website", <http://www.isthe.com/chongo/tech/comp/fnv/index.html>. --> 39) <!-- [rfced] References: We see "Last modified on: February 21, 2021 by Danilo G. Baio" on the bottom of the provided page for [FreeBSD]. Should this listing be updated to reflect the "Last modified" date and possibly include "Baio, D. G."? Original: [FreeBSD] The Free BSD Project, "FreeBSD 4.3 Release Notes", 2025, <http://www.freebsd.org/releases/4.3R/notes.html>. --> 40) <!-- [rfced] References: The provided URL for [GolfHash] steers to <https://rimstone-lang.com/>, and we see "Golf is now RimStone (2025-10-02)". May we change the citation string to "[RimStone]" and update the URL? Original: * Golf language hash tables [GolfHash], ... [GolfHash] Gliim LLC, "Golf Language Hash Tables", 2025, <https://golf-lang.com/new-hash.html>. Possibly: * Golf language hash tables [RimStone], ... [RimStone] Gliim LLC, "Golf Language Hash Tables", 2025, <https://rimstone-lang.com/>. --> 41) <!-- [rfced] References: Regarding [IEEE8021Qbp]: A Google search for "IEEE Std 802.1Qbp" yields several "hits", but <https://standards.ieee.org/ieee/802.1Qbp/5217/> and <https://ieeexplore.ieee.org/document/6783684> (1) show titles that include "Amendment 22:" and (2) list this standard as "Superseded". Please let us know how, or if, this listing should be updated. Original: [IEEE8021Qbp] "Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks - Equal Cost Multiple Path (ECMP)", IEEE Std 802.1Qbp-2014, 7 April 2014. --> 42) <!-- [rfced] References: The provided URL for [IPv6flow] yields either "Hmm. We're having trouble finding that site. We can't connect to the server at rsnode-app-prod" or "502 Bad Gateway". However, <https://www.cs.auckland.ac.nz/~brian/flowhashRep.pdf> provides what appears to be the same paper. Would this URL be considered stable? If yes, could we update this listing as follows? Original: [IPv6flow] Anderson, L., Brownlee, N., and B. Carpenter, "Comparing Hash Function Algorithms for the IPv6 Flow Label", University of Auckland Department of Computer Science Technical Report 2012-002, ISSN 1173-3500, March 2012, <https://researchspace.auckland.ac.nz/bitstream/ handle/2292/13240/flowhashRep.pdf>. Possibly: [IPv6flow] Anderson, L., Brownlee, N., and B. E. Carpenter, "Comparing Hash Function Algorithms for the IPv6 Flow Label", University of Auckland Department of Computer Science Technical Report 2012-002, ISSN 1173-3500, March 2012, <https://www.cs.auckland.ac.nz/~brian/flowhashRep.pdf>. --> 43) <!-- [rfced] References: On the provided page for [Vely], we see "Steve Emms" near the top of the page and "Website: No longer publicly developed" further down, past the bullet list and just above "Developer: Sergio Mijatovic". Also, on the provided page several commenters have noted that some relevant pages have been taken down. Will this citation still be helpful to readers, or should it be updated? Original: [Vely] Mijatovic, S., "Vely - general purpose framework", <https://www.linuxlinks.com/vely-general-purpose- framework/>. --> 44) <!-- [rfced] References: We could not see how [Vortetty] is related to pseudorandom number generation. Please confirm that the citation and reference listing will be clear to readers. Original: * to help seeding a pseudo random number generator [Vortetty], ... [Vortetty] "Raytracing for the gba", <https://github.com/Vortetty/gba-rtx>. --> 45) <!-- [rfced] Appendix A: We had trouble at first following the "and" relationships in this sentence. We updated per the "Ignoring SHA-1's ..." and "Ignoring SHA-256's" sentences that appear two and three paragraphs below this sentence. Also, as it appears that two items are listed here (the XOR and multiply operations, per 'the "xor" and multiply operations' in Section 2) rather than three items, we updated this sentence accordingly. If anything is incorrect, please clarify. Original: Ignoring transfer of control and conditional tests and equating all logical and arithmetic operations, FNV requires 2 operations per byte, an XOR and a multiply. Currently: Ignoring transfer of control and conditional tests, and equating all logical and arithmetic operations, FNV requires two operations per byte: an XOR operation and a multiply operation. --> 46) <!-- [rfced] Appendix A: We see from Google searches (e.g., a search for "Is SHA-1 broken?") that SHA-1 has apparently been fully broken. Would you like to update this text accordingly? Original (the previous sentence is included for context): SHA-1 is a relatively weak cryptographic hash function producing a 160-bit hash. It has been partially broken [RFC6194]. Possibly: SHA-1 [RFC6194] is a relatively weak cryptographic hash function producing a 160-bit hash. In recent years, it has been broken. --> 47) <!-- [rfced] Appendix B: Because (1) draft-ietf-tls-cached-info-08 did not expire (version -09 had been uploaded to the Datatracker about 3 months after version -08, per <https://datatracker.ietf.org/doc/rfc7924/history/>) and (2) this draft was ultimately published as RFC 7924 (https://www.rfc-editor.org/info/rfc7924) (which we see no longer contains the code in question), we updated this text accordingly. Please review, and let us know if further clarifications are needed. Also, we see that the code in this document is somewhat different than the code provided in draft-ietf-tls-cached-info-08. For example: In this document: static public BigInteger getFNV1aToByte(byte[] inp) { In draft-ietf-tls-cached-info-08: static public BigInteger getFNV1a64Digest (String inpString) { Should this be somehow clarified for readers? If yes, please provide the text. Original: FNV-1a was referenced in draft-ietf-tls-cached-info-08.txt that has since expired. Below is the Java code for FNV64 from that TLS draft included with the kind permission of the author: Currently: FNV-1a was referenced in draft-ietf-tls-cached-info-08 (which was ultimately published as RFC 7924, but RFC 7924 no longer contains the code below). Herein, we provide the Java code for FNV64 from that earlier draft, included with the kind permission of the author: --> 48) <!-- [rfced] Acknowledgements section: As the names were mostly listed in alphabetical order, we moved Paul Hoffman's name so that it is listed between Tony Finch and Charlie Kaufman. Please let us know any concerns. Original: Roman Donchenko, Frank Ellermann, Stephen Farrell, Tony Finch, Charlie Kaufman, Eliot Lear, Bob Moskowitz, Gayle Noble, Stefan Santesson, Mukund Sivaraman, Paul Hoffman, and Paul Wouters. Currently: Roman Donchenko, Frank Ellermann, Stephen Farrell, Tony Finch, Paul Hoffman, Charlie Kaufman, Eliot Lear, Bob Moskowitz, Gayle Noble, Stefan Santesson, Mukund Sivaraman, and Paul Wouters. --> 49) <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide at <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>, and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> 50) <!-- [rfced] Please let us know if any changes are needed for the following: a) The following terms were used inconsistently in this document. We chose to use the latter forms. Please let us know any objections. power of two / power of 2 (We also changed "power-of-two" to "power-of-2".) b) The following terms appear to be used inconsistently in this document. Please let us know which form is preferred. " 256, 512, and 1024\n"); / "256, 512, and 1024\n" ); (spacing in back-to-back printf statements) 64-bit Integers / 64-bit integers (back-to-back printf statements in Section 8.3) (We suggest lowercase "integers", per usage in the rest of this document.) flow ID / Flow ID (text in Section 4) (We asked about this inconsistency earlier, so this might have been resolved already.) FNV Prime(s) / FNV_Prime(s) / FNV_prime (e.g., "Size FNV Prime" and "32-bit FNV_Prime = ..." (Table 1), "32-bit FNV_prime = ..." (Section 8.2.1), and similar ones throughout Section 8.2) little endian (adj.) (e.g., "little endian format", "little endian byte vector") / little-endian (e.g., "big endian or other non-little-endian machines") Suggested: little-endian format, little-endian byte vector, big-endian machines or other non-little-endian machines one bits (noun) / one-bits (noun) (If you wish to use the hyphen, should "one bit" used as a noun in Section 2.1 also be hyphenated?) Extra space after "+" sign (5 instances): ctx->Hash[i] = ( temp<<8 ) + *basis++; ctx->Hash[i] = ( temp<<8 ) + (*basis++); as compared to ctx->Hash[i] = temp + *basis++; printf( (2 instances) / printf ( (33 instances) TestNValue (" (2 instances) / TestNValue ( " (16 instances) TestR ( " (84 instances) / TestR (" (7 instances) Verbose flag (3 instances) / verbose flag (1 instance) XOR folding / xor folding (in running text) (We also see "xor data folding".) "xor" (operations) ("the "xor" and multiply operations") / XOR (operations) ("operations per byte, an XOR and a multiply") --> Thank you. Lynne Bartholomew and Karen Moore RFC Production Center On Dec 15, 2025, at 12:59 PM, RFC Editor via auth48archive <[email protected]> wrote: *****IMPORTANT***** Updated 2025/12/15 RFC Author(s): -------------- Instructions for Completing AUTH48 Your document has now entered AUTH48. Once it has been reviewed and approved by you and all coauthors, it will be published as an RFC. If an author is no longer available, there are several remedies available as listed in the FAQ (https://www.rfc-editor.org/faq/). You and you coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval. Planning your review --------------------- Please review the following aspects of your document: * RFC Editor questions Please review and resolve any questions raised by the RFC Editor that have been included in the XML file as comments marked as follows: <!-- [rfced] ... --> These questions will also be sent in a subsequent email. * Changes submitted by coauthors Please ensure that you review any changes submitted by your coauthors. We assume that if you do not speak up that you agree to changes submitted by your coauthors. * Content Please review the full content of the document, as this cannot change once the RFC is published. Please pay particular attention to: - IANA considerations updates (if applicable) - contact information - references * Copyright notices and legends Please review the copyright notice and legends as defined in RFC 5378 and the Trust Legal Provisions (TLP – https://trustee.ietf.org/license-info). * Semantic markup Please review the markup in the XML file to ensure that elements of content are correctly tagged. For example, ensure that <sourcecode> and <artwork> are set correctly. See details at <https://authors.ietf.org/rfcxml-vocabulary>. * Formatted output Please review the PDF, HTML, and TXT files to ensure that the formatted output, as generated from the markup in the XML file, is reasonable. Please note that the TXT will have formatting limitations compared to the PDF and HTML. Submitting changes ------------------ To submit changes, please reply to this email using ‘REPLY ALL’ as all the parties CCed on this message need to see your changes. The parties include: * your coauthors * [email protected] (the RPC team) * other document participants, depending on the stream (e.g., IETF Stream participants are your working group chairs, the responsible ADs, and the document shepherd). * [email protected], which is a new archival mailing list to preserve AUTH48 conversations; it is not an active discussion list: * More info: https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc * The archive itself: https://mailarchive.ietf.org/arch/browse/auth48archive/ * Note: If only absolutely necessary, you may temporarily opt out of the archiving of messages (e.g., to discuss a sensitive matter). If needed, please add a note at the top of the message that you have dropped the address. When the discussion is concluded, [email protected] will be re-added to the CC list and its addition will be noted at the top of the message. You may submit your changes in one of two ways: An update to the provided XML file — OR — An explicit list of changes in this format Section # (or indicate Global) OLD: old text NEW: new text You do not need to reply with both an updated XML file and an explicit list of changes, as either form is sufficient. We will ask a stream manager to review and approve any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes. Information about stream managers can be found in the FAQ. Editorial changes do not require approval from a stream manager. Approving for publication -------------------------- To approve your RFC for publication, please reply to this email stating that you approve this RFC for publication. Please use ‘REPLY ALL’, as all the parties CCed on this message need to see your approval. Files ----- The files are available here: https://www.rfc-editor.org/authors/rfc9923.xml https://www.rfc-editor.org/authors/rfc9923.html https://www.rfc-editor.org/authors/rfc9923.pdf https://www.rfc-editor.org/authors/rfc9923.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9923-diff.html https://www.rfc-editor.org/authors/rfc9923-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9923-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9923 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9923 (draft-eastlake-fnv-35) Title : The FNV Non-Cryptographic Hash Algorithm Author(s) : G. Fowler, L. Noll, K. Vo, D. Eastlake 3rd, T. Hansen WG Chair(s) : Area Director(s) : -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected] -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
