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.
= = = = =
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]
