Hi Lynne, See below.
On Tue, Dec 23, 2025 at 3:47 PM Lynne Bartholomew <[email protected]> wrote: > > Hi, Donald and *Eliot. > > Donald, thank you for your replies to our questions! We have updated this > document per your notes below. > > *Eliot, we have updated our "Questions for the ISE" item. Currently: > > <!-- [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. > > c) Per the author, we have removed the textual citation and > reference listing for [Vortetty]. We want to confirm with you that > it is OK to remove mention of pseudorandom number generation. > > Original: > * to help seeding a pseudo random number generator [Vortetty], > ... > [Vortetty] "Raytracing for the gba", > <https://github.com/Vortetty/gba-rtx>. --> > > ===================================================== > > Donald, we have some follow-up items for you: > > Regarding our question 4) and your question regarding superscripts in .txt > output: > > >> 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. --> > > > > They do indicate exponents, i.e., superscripts, but what will your > > suggested change do to occurrences in text in the .txt version? > > Superscripts are probably great in the PDF and HTML versions but what > > does it look like in .txt? > > > > The .txt file would not show any changes; these entries would still be "2**". > We are fine with leaving as is but wanted to see if you'd like superscripts > in the PDF and HTML versions. Apologies for not clarifying that earlier. No problem. I guess superscripts in the PDF and HTML versions would be more elegant. > = = = = = > > Regarding our question 8) and your reply: > > >> 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. --> > > > > Later non-FNV recommendations are not important. This later change is > > why our proposed text says "... there was a proposal ..." in the past > > tense. I don't see any problem with your editorial changes re > > [IPv6flow] and [NCHF] but I don't see what's wrong with the [BFDseq] > > reference to a specific old, outdated, draft which used FNV. This > > document is about FNV, not about ISAAC, and I see no reason for it to > > mention/reference ISAAC. > > Please review our updates to this text, and let us know if anything is > incorrect. Looks fine to me. > = = = = = > > Regarding our question 10) and your reply: > > >> 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. > > > > "C" -> "c" is OK. > > > >> 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.) > > > > Yes. "makefile" is a common and quite venerable "sourcecode" type > > originating with early UNIXes and very widely in use every day today. > > It has its own format and should be included in the allowed Sourcecode > > Types. Please request its addition there. > > Thank you for this information. We included it in our email to the > RFC Production Advisory Team (RPAT); we asked them to consider > adding "makefile" to the list of sourcecode types. > > ** Please note: One of the RPAT personnel sent the following: > > > It is indeed a widely used file format, but keep in mind that > > there are at least three popular versions of make, Gnu, BSD, and > > Microsoft, and the makefile formats are similar but not identical. > > > > "I'd be OK with a note to authors asking them to put a comment in > > the makefile saying which flavor of make it's intended for, unless > > they're sure it's so simple that it'll work in all of them. > > Would you like to make such an update in the leading comments for > the makefile (possibly just after the "# Makefile for fnv" line)? > If yes, please specify how best to update. I think the makefile is sufficiently simple that it should work for all of these. > = = = = = > > Regarding our question 12) and your reply: > > >> 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. --> > >> > > The FNV hash function always produces the same output for the same > > input. The null string as input always outputs the offset_basis but > > other inputs almost never produce that output. Your suggestion #1 looks > > good except I do not think there should be a comma after "output". The > > structure of the sentence is "Any entity that can observe A and can > > cause B will thereby be able to C." Does this structure really need > > any commas? I don't actually have a problem with the comma after > > "hashed" but I don't like the comma after "output". > > It should be either two commas or none; we went with none. OK. > = = = = = > > Regarding our question 20) and your reply: > > >> 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. > >> > > That's not how it was in the XML we submitted. As submitted this is a > > <dl> list with the first three lines having a <dd/> with null content and > > the fourth having the descriptive text as the <dd> content. Perhaps > > due to this change, the current .txt for the "paragraphs" in this > > section has the descriptive text peculiarly flowed up. Please look at > > this in the text produced from the original XML submitted. > >> > >> 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? > >> > > The descriptive text applies to all four lines. See comment above. > >> > >> Original: > >> FNVxxxstring, FNVxxxblock, FNVxxxfile: > >> > >> FNVxxxstringBase, FNVxxxblockBase, FNVxxxfileBase: > >> > >> FNVxxxINTstring, FNVxxxINTblock, FNVxxxINTfile: > >> ... > >> FNVxxxinit, FNVxxxinitBasis: --> > > We reverted the formatting (i.e., returned to the <dl> format rather > than <artwork>). OK. > = = = = = > > Regarding our question 22) and your reply: > > >> 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). --> > > > > "available" in this case means available to the compiler and has > > nothing to do with appearance in a section of this document. I suppose > > you could do something like "available." -> "available to the compiler > > while compiling the FNVxxx.c file." > > We weren't sure how best to update here. Please review our update > to the "To build the particular FNVxxx code ..." sentence, and let > us know if anything is incorrect. The current wording reads oddly to me. The parenthetical "... (available to ..." seems jarring and the scope/applicability of "available" seems unclear. Perhaps a minimum fix would be to add the word "all" so it was "... (all available ...". I think better would be to change the sentence to "To build the particular FNVxxx code itself, compile the FNVxxx.c file with the following files available to the compiler: FNVconfig.h, fnv-private.h, FNVErrorCodes.h, and FNVxxx.h. (See Section 8.2.)" > = = = = = > > Regarding your note in reply to our question 25): > > > NOTE: not exactly relevant to your question 25 but there is a > > difference between "hash a ..." and "hash in a ...". In the first > > instance, the function is calculating a hash solely dependent on the one > > parameter. In there second, there is also a context parameter that was > > previously initialized and may have had other data items hashed into > > it and the function is hashing additional data into that context. > > We appreciate this note. We had noticed that "hash in a" is used in > the context of parameters that end with "in" (FNV32blockin, > FNV32stringin, FNV32filein, etc.). Thank you for clarifying! You're welcome. > = = = = = > > Thanks also for your replies regarding our question 29); much appreciated! > > = = = = = > > > Your suggested changes are fine (and will make the document 2 lines > > shorter :-) ) > > Thank you for the humor! > > = = = = = > > Regarding our question 39) and your reply: > > >> 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>. --> > > > > Yes, I think such an update and inclusion would be good. > > Please review our update to this listing, and let us know if you > prefer a different format/style. Looks OK. > = = = = = > > Regarding our question 41) and your reply: > > >> 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. --> > > > > IEEE Std 802.1Qbp-2014 was an amendment to 802.1Q and has been merged > > into IEEE Std 802.1Q-2022 where the reference to FNV occures in Clause > > 44.1.2 entitled "ECMP ECT Algorithm". (IEEE refers to parts of their > > Standards as "Clauses" rather than "Sections" but I don't think anyone > > would be confused if the reference in this RFC was to "Section > > 44.1.2".) In any case, the reference tag should now be [IEEE8021Q] and > > an appropriate URL for IEEE Std 802.1Q-2022 should be used. > > Would you like us to specifically cite Clause 44.1.2 in Section 1.3? > Please note that the other two citations are general and do not > list section numbers. Currently: > > ... It is also referenced in the following > standards documents: [RFC7357], [RFC7873], and [IEEE8021Q-2022]. I do not think you need to reference the Clause. The IEEE Std document is a PDF and the use of FNV can be easily found by searching for "FNV". > = = = = = > > Regarding this part of our question 47): Is it OK that the code in > this document doesn't quite match the referenced code from Stefan > Santesson? > > ... > >> 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. I think the document should be changed to accurately reflect the -08 draft which is what the document claims it is trying to do. (I went back and checked -07 and -06 and they are all the same as -08.) > = = = = = > > Regarding this update: > > >> 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++; > > > > One space so as, in these instances, to make the punctuation to the > > left and right of the plus sign symmetric, is better. > > Apologies for not spotting this earlier: We now have 4 instances of > "ctx->Hash[i] = ( temp<<8 ) + *basis++;" and 1 instance of > "ctx->Hash[i] = ( temp<<8 ) + (*basis++);". Are the parentheses > around "*basis++" needed in this 1 instance? No, the parenthesis around "(*basis++)" can be removed. (In any case, before final approval, I will extract the code from the edited version and we will test it.) Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA [email protected] > = = = = = > > The latest files are posted here. Please refresh your browser: > > https://www.rfc-editor.org/authors/rfc9923.txt > https://www.rfc-editor.org/authors/rfc9923.pdf > https://www.rfc-editor.org/authors/rfc9923.html > https://www.rfc-editor.org/authors/rfc9923.xml > https://www.rfc-editor.org/authors/rfc9923-diff.html > https://www.rfc-editor.org/authors/rfc9923-rfcdiff.html (side by side) > https://www.rfc-editor.org/authors/rfc9923-auth48diff.html > https://www.rfc-editor.org/authors/rfc9923-auth48rfcdiff.html (side by > side) > > https://www.rfc-editor.org/authors/rfc9923-xmldiff1.html > https://www.rfc-editor.org/authors/rfc9923-xmldiff2.html > > Thank you again for your help and patience with this document and our > questions! > > Lynne Bartholomew > RFC Production Center > > > > On Dec 18, 2025, at 6:45 PM, Donald Eastlake <[email protected]> wrote: > > > > Hi, > > > > Thanks for your very thorough review. > > > > I think we did a pretty good job testing and reviewing the actual code > > but I would like to personally apologize for our insufficient review > > of the comments accompanying the code. > > > > See below. > > > > On Mon, Dec 15, 2025 at 4:03 PM <[email protected]> wrote: > >> > >> 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>. --> > > > > None occur to me. Perhaps other authors will come up with some. > > > >> 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. > > > > Good. > > > >> b) For ease of the reader, should the following abbreviations also be > >> defined? If yes, please provide the correct definitions. > >> > >> MASS > > > > Probably a good idea but I don't know what it stands for. > > > >> IDE (We see "IDE" defined as "Integrated Development Environments" > >> in [fasmlab].) > >> > >> BFD (perhaps "Bidirectional Forwarding Detection"?) --> > > > > Yes, expanding IDE and BFD is good. > > > >> 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. > >> --> > > > > Up to the ISE Editor but I think your suggestions above are good. > > > >> 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. --> > > > > They do indicate exponents, i.e., superscripts, but what will your > > suggested change do to occurrences in text in the .txt version? > > Superscripts are probably great in the PDF and HTML versions but what > > does it look like in .txt? > > > >> 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. --> > > > > OK. > > > >> 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], --> > > > > That change seems useful. > > > >> 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>. --> > > > > Your suggested change looks good to me. > > > >> 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. --> > > > > Later non-FNV recommendations are not important. This later change is > > why our proposed text says "... there was a proposal ..." in the past > > tense. I don't see any problem with your editorial changes re > > [IPv6flow] and [NCHF] but I don't see what's wrong with the [BFDseq] > > reference to a specific old, outdated, draft which used FNV. This > > document is about FNV, not about ISAAC, and I see no reason for it to > > mention/reference ISAAC. > > > >> 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. --> > > > > I'll let other authors respond on that. > > > >> 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. > > > > "C" -> "c" is OK. > > > >> 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.) > > > > Yes. "makefile" is a common and quite venerable "sourcecode" type > > originating with early UNIXes and very widely in use every day today. > > It has its own format and should be included in the allowed Sourcecode > > Types. Please request its addition there. > > > >> Also, please let us know whether any artwork elements should be > >> marked as sourcecode; if yes, please provide the sourcecode type. --> > > > > I have reviewed all the artwork elements and I don't think any of them > > should be sourcecode elements. > > > >> 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. --> > > > > I think plural would be more appropriate. Could say "would be more > > complex" instead of "is more complex". > > > >> 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. --> > > > > The FNV hash function always produces the same output for the same > > input. The null string as input always outputs the offset_basis but > > other inputs almost never produce that output. Your suggestion #1 looks > > good except I do not think there should be a comma after "output". The > > structure of the sentence is "Any entity that can observe A and can > > cause B will thereby be able to C." Does this structure really need > > any commas? I don't actually have a problem with the comma after > > "hashed" but I don't like the comma after "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. --> > > > > Sorry, it should be Section 8. > > > >> 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. --> > > > > Your rewording makes what was intended clearer. > > > >> 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. --> > > > > Yes, flow label / Flow Label is what is intended. > > > >> 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. --> > > > > Generally all the routing information at a node is referred to as the > > RIB so I think i.e. is correct. > > > >> 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. --> > > > > Your edited version is correct. > > > >> 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. --> > > > > I have to admit that "[IEEE]" is a very general reference but I don't > > know if the IEEE P1003.2 committee still exists or what a good web > > address for it would be. I think the current text and reference are > > adequate. > > > >> 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. --> > > > > Thanks for spotting that. It is an excellent catch. These should all > > have "Base" -> "Basis" so they will be like FWVxxxinitBasis. > > > >> 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. > > > > That's not how it was in the XML we submitted. As submitted this is a > > <dl> list with the first three lines having a <dd/> with null content and > > the fourth having the descriptive text as the <dd> content. Perhaps > > due to this change, the current .txt for the "paragraphs" in this > > section has the descriptive text peculiarly flowed up. Please look at > > this in the text produced from the original XML submitted. > > > >> 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? > > > > The descriptive text applies to all four lines. See comment above. > > > >> 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. --> > > > > The second, it means "a command line invoking a 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). --> > > > > "available" in this case means available to the compiler and has > > nothing to do with appearance in a section of this document. I suppose > > you could do something like "available." -> "available to the compiler > > while compiling the FNVxxx.c file." > > > >> 23) <!-- [rfced] Sections 8.2 and subsequent: We changed instances of > >> "RFC NNNN" to "RFC 9923". Please let us know of any concerns. --> > > > > Sounds good. That was the intent. > > > >> 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 --> > > > > It means a byte vector of a specified length. > > > >> 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 --> > > > > Putting a colon after FNV32 etc. in these cases is good. I think they > > are all inside comments so such an editorial change should not cause > > any problem. > > > > NOTE: not exactly relevant to your question 25 but there is a > > difference between "hash a ..." and "hash in a ...". In the first > > instance, the function is calculating a hash solely dependent on the one > > parameter. In there second, there is also a context parameter that was > > previously initialized and may have had other data items hashed into > > it and the function is hashing additional data into that context. > > > >> 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. > > > > I reviewed all the changes in the code section of 8.2 in > > https://www.rfc-editor.org/authors/rfc9923-rfcdiff.html and they all > > look OK. > > > >> 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. --> > > > > OK. > > > >> 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 > > > > Thanks for catching that. Your change is correct. > > > >> 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 > > > > Yes, these errors in the source code comment should be fixed replacing > > 128 with 64. > > > >> 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 > > > > Yes, these errors in that source code comment should be fixed > > replacing 32 with 64. > > > >> d) Should "FNV64INTinitBasis: initializes an FNV32 context" be > >> "FNV64INTinitBasis: initializes an FNV64 context"? > >> > >> Original: > >> FNV64INTinitBasis: initializes an FNV32 context with a --> > > > > Yes. > > > >> 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 */ --> > > > > "fnvNull" is an error code returned if the function is called with a > > "null input pointer or null output 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"). > > > > So, it's a little complicated. The FNV32 functions have versions that > > return a 32 bit integer and versions that return a vector of 4 bytes > > each 8 bits. The FNV64 functions have versions that return a vector of > > 8 bytes each 8 bits and, if the code is compiled with 64 bit integers > > supported, versions that return such a 64 bit integer. > > > > Since we assume the there is no direct support for integers larger > > than 64 bits, all of the FNV128, FNV256, FNV512, and FNV1024 functions > > return a vector of 8 bit bytes, the length of that vector being 16, > > 32, 64, and 128 bytes respectively. So I believe the line "Hash is > > returned as an array of 8-bit unsigned integers" is correct for all of > > FNV128 through FNV1024 although it could, perhaps, be clearer and > > information about the length of the vector, which would be different > > for each different size of FNV, could be added. > > > >> 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). > > > > This context is an internal structure. If a the code is compiled for > > a computer that supports 64 bit integers, it is more efficient for > > this internal structure to be composed in one way whereas if the code > > is compiled for a computer that does not support 64 bit integers, this > > internal structure must be composed in a different way. The only case > > where this does not apply is FNV32. In other words, the data following > > all these lines is correct. > > > >> c) Please search for instances of "version if", and confirm that > >> the text should always be "version if 64-bit ...". --> > > > > Yes, there is a version if 64-bit integers are supported and a version > > if 64-bits are not supported for every length of FNV except FNV32. > > > >> 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 */ --> > > > > Yes, thanks for those fixes. > > > >> 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 --> > > > > I agree that these redundant "version for when you only have 32-bit > > arithmetic" lines can be removed. > > > >> 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 --> > > > > Yes. > > > >> 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 > > > > Yes, should be "followed by" > > > >> 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 ) ); --> > > > > Your suggested changes are fine (and will make the document 2 lines > > shorter :-) ). > > > >> 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 --> > > > > OK. > > > >> 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>. --> > > > > Although David Bell is not listed on that page, if you click on the > > "Who wrote calc?" link, he is very prominent as the primary author so > > I think the reference listing is correct. > > > >> 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/>. --> > > > > I don't know what this reference is supposed to be. Maybe another > > author can come up with information as to why we added it. If not, it > > should be deleted. > > > >> 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/>. --> > > > > I'm fine with updating the date re the notice. > > > >> 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>. --> > > > > Listing all three people would probably be good. I do not think > > "Fowler-Noll-Vo" is an organization but is the thing actually > > referenced, Perhaps something like this: > > > > <reference anchor="FNV" > > target="http://www.isthe.com/chongo/tech/comp/fnv/index.html";> > > <front> > > <title>FNV (Fowler/Noll/Vo)</title> > > <author initials="G." surname="Fowler"/> > > <author initials="L." surname="Noll"/> > > <suthor initials="K." surname="Vo"/> > > </front> > > </reference> > > > >> 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>. --> > > > > Yes, I think such an update and inclusion would be good. > > > >> 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/>. --> > > > > OK. > > > >> 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. --> > > > > IEEE Std 802.1Qbp-2014 was an amendment to 802.1Q and has been merged > > into IEEE Std 802.1Q-2022 where the reference to FNV occures in Clause > > 44.1.2 entitled "ECMP ECT Algorithm". (IEEE refers to parts of their > > Standards as "Clauses" rather than "Sections" but I don't think anyone > > would be confused if the reference in this RFC was to "Section > > 44.1.2".) In any case, the reference tag should now be [IEEE8021Q] and > > an appropriate URL for IEEE Std 802.1Q-2022 should be used. > > > >> 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>. --> > > > > Yes, please update to the currently working URL you found. Thanks. > > > >> 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/>. --> > > > > It appears that the only current use of FNV at that site may be the > > "smash" utility by Steven Emms... I suggest the reference be changed > > to something like the following: > > > > [Smash] Emms, S., "Smash - find duplicate files super fast", > > > > https://www.linuxlinks.com/smash-find-duplicate-files-super-fast/ > > > > Then the line in the body of the draft should change as follows > > OLD > > the [Vely] framework for C language, > > NEW > > the [Smash] utility for rapidly finding duplicate files, > > > >> 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>. --> > > > > I am also unable to find FNV there. Maybe it was in a previous version > > and has been delected. Suggest removing this reference and the line > > from which it is referenced. > > > >> 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. --> > > > > Your revised wording is OK. > > > >> 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. --> > > > > Well, attacks have been found that reduce its strength so that it is > > inapporpirate for many uses but I would not say it is completely > > broken. I have no objection to making this stronger by saying > > "substantially broken" instead of "partically 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: --> > > > > Your wording is OK. > > > >> 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. --> > > > > OK, thanks. > > > >> 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. --> > > > > I do not think there is any problem with inclusive language in this > > document. > > > >> 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".) > > > > OK. > > > >> 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) > > > > I suppose the version with the space before the parenthesis is a bit > > more readable. > > > >> 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.) > > > > OK. > > > >> flow ID / Flow ID (text in Section 4) (We asked about this > >> inconsistency earlier, so this might have been resolved already.) > > > > I agreed above it should by flow "lable", not "ID". This is a distinct > > named field so I am inclined to say it should be Flow Label. > > > >> 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) > > > > The underscore is included in the pseudocode and in the text > > explanations so I think it should be included in all cases. > > > >> 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 > > > > OK. > > > >> 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?) > > > > In "one bits" one is an adjective. It means "bits whose value is 1" as > > opposed to bits whose value is 0. Probably should not 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++; > > > > One space so as, in these instances, to make the punctuation to the > > left and right of the plus sign symetric, is better. > > > >> printf( (2 instances) / printf ( (33 instances) > > > > Go with the space as per the more common occurence. > > > >> TestNValue (" (2 instances) / TestNValue ( " (16 instances) > >> > >> TestR ( " (84 instances) / TestR (" (7 instances) > >> > >> Verbose flag (3 instances) / verbose flag (1 instance) > > > > In the three cases above, go with the more common usage. > > > >> 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") --> > > > > I am inclined to make all instances all caps except for the one > > occurrence in Appendix B which must be lower case. > > > > Thanks again for your thorough review. > > > > Donald > > ============================= > > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > > 2386 Panoramic Circle, Apopka, FL 32703 USA > > [email protected] > > > >> 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]
