Hi, Donald, Eliot, and Paul. Thank you for the emails. We have removed the last paragraph of Section 1.3 (the pointer to the "fnvhash-mail" email address) as well as the citation and listing for [Cohesia]. (Removing mention of [Cohesia] provides the side benefit of also removing any question of what "MASS" stands for.)
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 Side note: Good news -- "makefile" has been added as an approved sourcecode type on <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>. Thanks again! Lynne Bartholomew RFC Production Center > From: Paul Wouters <[email protected]> > Subject: Re: *LANDON, PAY ATTENTION* Re: [ISE] AUTH48: RFC-to-be 9923 > <draft-eastlake-fnv-35> for your review > Date: January 7, 2026 at 5:14:00 AM PST > To: "Independent Submissions Editor (Eliot Lear)" <[email protected]> > Cc: Donald Eastlake <[email protected]>, Lynne Bartholomew > <[email protected]>, [email protected], > "[email protected]" <[email protected]>, > [email protected], [email protected], [email protected], > [email protected] > > > > On Wed, Jan 7, 2026 at 3:57 AM Independent Submissions Editor (Eliot Lear) > <[email protected]> wrote: > Hi everyone and happy new year! > Two points: > On 07.01.2026 05:01, Donald Eastlake wrote: >>> = = = = = >>> >>> Also, these two questions are still pending. We are fine with leaving the >>> email address "as is" if it still works, but we believe that the question >>> regarding the [Cohesia] reference needs to be resolved (perhaps, as Donald >>> noted earlier, it can be deleted?). Please advise: >>> >>> <!-- [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. >>> >>> Donald Eastlake: I'll let other authors respond on that. --> >>> >> I believe that is OK but Landon Knoll would know best. > I prefer that the reference to an email address for a private concern be > dropped. These RFCs are mean to be timeless, and people are not. That > having been said, I won't stand on my head on this point. > > I agree. > >> >> >>> <!-- [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/>. >>> >>> Donald Eastlake: 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. --> >>> >> Given that multiple attempts to find an FNV reference in the current >> Cohesia site, I am increasingly convinced it should just be dropped. >> > +1. > > And I agree here too. > > Paul > > From: "Independent Submissions Editor (Eliot Lear)" <[email protected]> > Subject: *LANDON, PAY ATTENTION* Re: [ISE] AUTH48: RFC-to-be 9923 > <draft-eastlake-fnv-35> for your review > Date: January 7, 2026 at 12:57:45 AM PST > To: Donald Eastlake <[email protected]>, Lynne Bartholomew > <[email protected]> > Cc: [email protected], [email protected], "[email protected]" > <[email protected]>, [email protected], > [email protected], [email protected], [email protected] > > Hi everyone and happy new year! > Two points: > On 07.01.2026 05:01, Donald Eastlake wrote: >>> = = = = = >>> >>> Also, these two questions are still pending. We are fine with leaving the >>> email address "as is" if it still works, but we believe that the question >>> regarding the [Cohesia] reference needs to be resolved (perhaps, as Donald >>> noted earlier, it can be deleted?). Please advise: >>> >>> <!-- [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. >>> >>> Donald Eastlake: I'll let other authors respond on that. --> >>> >> I believe that is OK but Landon Knoll would know best. > I prefer that the reference to an email address for a private concern be > dropped. These RFCs are mean to be timeless, and people are not. That > having been said, I won't stand on my head on this point. > >> >>> <!-- [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/>. >>> >>> Donald Eastlake: 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. --> >>> >> Given that multiple attempts to find an FNV reference in the current >> Cohesia site, I am increasingly convinced it should just be dropped. >> > +1. > Best regards, > Eliot > On Jan 6, 2026, at 8:01 PM, Donald Eastlake <[email protected]> wrote: > > Hi Lynne, > > On Tue, Jan 6, 2026 at 12:49 PM Lynne Bartholomew > <[email protected]> wrote: >> >> Hi, Donald and Tony. >> >> Thank you for the emails. Tony, Happy New Year to you as well! >> >> Donald, we've further updated this document per your notes below. Apologies >> for missing the parentheses around "digest" in the "return" call in Stefan's >> code; we added them. >> >> Please let us know if you have any concerns regarding the following: >> >> * Implementing HTML- and PDF-output superscripts in text and in Table 1 >> resulted in the caret character ("^") in the text file, instead of the >> original double asterisks ("**"). We also see the caret used in code >> comments in Section 8 (e.g., "/* 32-bit FNV_prime = 2^24 + 2^8 + 0x93 */"), >> so this seems fine to us, but we want to make sure that it's fine with you >> as well. >> >> * We changed "the 2**9 bit" to "the 2^9 bit" (superscripted in the HTML- and >> PDF-output files). Please let us know if this is incorrect. > > I think that's all OK. > >> = = = = = >> >> Also, these two questions are still pending. We are fine with leaving the >> email address "as is" if it still works, but we believe that the question >> regarding the [Cohesia] reference needs to be resolved (perhaps, as Donald >> noted earlier, it can be deleted?). Please advise: >> >> <!-- [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. >> >> Donald Eastlake: I'll let other authors respond on that. --> > > I believe that is OK but Landon Knoll would know best. > >> <!-- [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/>. >> >> Donald Eastlake: 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. --> > > Given that multiple attempts to find an FNV reference in the current > Cohesia site, I am increasingly convinced it should just be dropped. > > 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-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 >> >> Thanks again! >> >> Lynne Bartholomew >> RFC Production Center >> >> >>> On Jan 5, 2026, at 2:01 PM, HANSEN, TONY L <[email protected]> >>> wrote: >>> >>> I reviewed all of Donald’s comments. I agree with everything he’s written. >>> >>> Regarding MASS, it appears that the company Cohesia had a trademark at one >>> point for something called MASS, and it appears that it was for something >>> that included an algorithm that must have used FNV. However I have been >>> unable to confirm what MASS stood for. >>> >>> Happy New Year everyone. >>> >>> Tony >> >>> On Jan 5, 2026, at 11:13 AM, Donald Eastlake <[email protected]> wrote: >>> >>> Hi Lynne, >>> >>> Happy New Year! >>> >>> See below. >>> >>> On Mon, Jan 5, 2026 at 1:03 PM Lynne Bartholomew >>> <[email protected]> wrote: >>>> >>>> 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. >>> >>> Yes, go ahead and use actual superscripts in the PDF and HTML versions. >>> >>>> = = = = = >>>> >>>> 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 code you have now looks OK. However, I note that the original >>> draft -08 text has "return (digest);". The parenthesis there are not >>> necessary and have no effect but it seems a bit better to more >>> precisely follow the code we are copying here by leaving in the >>> parenthesis. >>> >>> 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-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]
