Hi, Eliot. Thanks for this email as well! Per <https://trustee.ietf.org/documents/trust-legal-provisions/>, I sent email to <[email protected]> asking about this. I also talked to Jean Mahoney, who said that this list doesn't have much activity.... Hoping all the same to get a reply soon -- maybe in early January if not sooner.
Happy Holidays to everyone! I'll be signing off in a couple hours and will be back online Monday, January 5, 2026. Lynne Bartholomew RFC Production Center > On Dec 23, 2025, at 7:13 PM, Independent Submissions Editor (Eliot Lear) > <[email protected]> wrote: > > Hi Lynne > On 23.12.2025 16:44, Lynne Bartholomew wrote: >> Hi, Eliot. Thank you for the quick reply! >> >> We have updated the "Copyright (c) 2016 ..." entries per your note below. >> >> Quick side question: If this document is published in January or later >> (which seems likely), should "2016-2025" be changed to "2016-2026" next >> month, or will it be fine to leave the range as is? > I'd check with the lawyer, but my intuition tells me that the year should be > the based the last date the work was edited. > Eliot > >> >> 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-lastdiff.html >> https://www.rfc-editor.org/authors/rfc9923-lastrfcdiff.html (side by side) >> >> https://www.rfc-editor.org/authors/rfc9923-xmldiff1.html >> https://www.rfc-editor.org/authors/rfc9923-xmldiff2.html >> >> We have also noted your approval on the AUTH48 status page: >> >> https://www.rfc-editor.org/auth48/rfc9923 >> >> Thanks again! >> >> Lynne Bartholomew >> RFC Production Center >> >> >>> On Dec 23, 2025, at 1:12 PM, Independent Submissions Editor (Eliot Lear) >>> <[email protected]> wrote: >>> >>> Hi Lynne >>> On 23.12.2025 15:47, Lynne Bartholomew 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. >>>> >>> No 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? >>>> >>> Yes >>> >>> >>>> 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. >>>> >>> That's fine. >>> >>> Eliot >>> >>> >>>> 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. >>>> >>>> = = = = = >>>> >>>> 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. >>>> >>>> = = = = = >>>> >>>> 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. >>>> >>>> = = = = = >>>> >>>> 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. >>>> >>>> = = = = = >>>> >>>> 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>). >>>> >>>> = = = = = >>>> >>>> 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. >>>> >>>> = = = = = >>>> >>>> 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! >>>> >>>> = = = = = >>>> >>>> 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. >>>> >>>> = = = = = >>>> >>>> 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]. >>>> >>>> = = = = = >>>> >>>> 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. >>>>>> >>>>>> >>>> = = = = = >>>> >>>> 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 symetric, 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? >>>> >>>> = = = = = >>>> >>>> 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]
