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