The FNV Non-Cryptographic Hash Algorithm
draft-eastlake-fnv-29

IESG/Authors/WG Chairs:

IANA has completed its review of draft-eastlake-fnv-29, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-10-22):

From: The IESG
To: IETF-Announce
CC: draft-eastlake-fnv@ietf.org, paul.hoffman@icann.org, paul.wouters@aiven.io
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (The FNV Non-Cryptographic Hash Algorithm) to Informational RFC


The IESG has received a request from an individual submitter to consider the
following document: - 'The FNV Non-Cryptographic Hash Algorithm'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-10-29. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  FNV (Fowler/Noll/Vo) is a fast, non-cryptographic hash algorithm with
  good dispersion that is referenced in a number of standards documents
  and widely used.  The purpose of this document is to make information
  on FNV and open source code performing all specified sizes of FNV
  conveniently available to the Internet community.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-eastlake-fnv/



No IPR declarations have been submitted directly on this I-D.

1. Was the document considered in any WG, and if so, why was it not
adopted as a work item there?

  The draft was presented in SECDISPATCH at IETF meeting 114 with the
  conclusion that it should be AD sponsored. The draft has been updated many
  times since then but I see no reason to change that conclusion. That is, I
  don't see anything new in the diff that would make me think that this draft
  would now be adopted by a WG or needs to go to the ISE.

2. Was there controversy about particular points that caused the WG to
not adopt the document?

  No.

3. Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the responsible Area Director.

  No.

4. For protocol documents, are there existing implementations of the
contents of the document? Have a significant number of potential
implementers indicated plans to implement? Are any existing
implementations reported somewhere, either in the document itself (as
RFC 7942 recommends) or elsewhere (where)?

  This is not a protocol document. There are other implementations but
  mostly of the 32 and 64 bit versions of FNV. Implementations of 128,
  256, 512, and 1024 bit versions are rare.

5. Does this document need review from other IETF working groups or
external organizations? Have those reviews occurred?

  No. An IETF-wide review might shake out some interested reviewers.
  This is not a cryptographic hash so a CRFG-specific review might
  in fact confuse things.

6. Describe how the document meets any required formal expert review
criteria, such as the MIB Doctor, YANG Doctor, media type, and URI
type reviews.

  The document contains C code which compiles and runs correctly on
  multiple C compilers and has been passed through multiple "lint"
  like checkers.

7. If the document contains a YANG module, has the final version of
the module been checked with any of the recommended validation tools
for syntax and formatting validation?

  N/A.

8. Describe reviews and automated checks performed to validate
sections of the final version of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL,
etc.

  The document includes C code that compiles without errors or warning
  on multiple C compilers and has been passed through multiple "lint"
  checkers.

9. Based on the shepherd's review of the document, is it their opinion
that this document is needed, clearly written, complete, correctly
designed, and ready to be handed off to the responsible Area Director?

  The "need" for this document is not clear, but it is certainly
  likely to be useful to some implementers. It is clearly written.
  (There is a minor typo of "Exression" that can easily be fixed
  later.)

10. Several IETF Areas have assembled lists of common issues that
their reviewers encounter. Do any such issues remain that would merit
specific attention from subsequent reviews?
https://trac.ietf.org/trac/iesg/wiki/ExpertTopics

  No. No areas appear to have reviewed the draft yet.

11. What type of RFC publication is being requested on the IETF stream
(Best Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental, or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this
intent?

  Informational. This is the correct type since the algorithm was not
  developed in the IETF. There is no good reason to put it on
  standards track, nor is it "experimental".

12. Have reasonable efforts been made to remind all authors of the
intellectual property rights (IPR) disclosure obligations described in
BCP 79? To the best of your knowledge, have all required disclosures
been filed? If not, explain why. If yes, summarize any relevant
discussion, including links to publicly-available messages when
applicable.

  The authors specicially disclaim any IPR. See Section 1 of the
  draft.

13. Has each Author or Contributor confirmed their willingness to be
listed as such? If the number of Authors/Editors on the front page is
greater than 5, please provide a justification.

  The number of authors does not exceed 5. All authors are fine with
  being so listed.

14. Document any remaining I-D nits in this document. Simply running
the idnits tool is not enough; please review the "Content Guidelines"
on authors.ietf.org. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)

  The nit checker has many warnings, but they are all incorrect
  because they are flagging valid C code.

15. Should any informative references be normative or vice-versa?

  No. The only normative reference is for ASCII, which is fine.

16. List any normative references that are not freely available to
anyone. Did the community have sufficient access to review any such
normative references?

  N/A

17. Are there any normative downward references (see RFC 3967 and BCP
97) that are not already listed in the DOWNREF registry? If so, list
them.

  No.

18. Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If they exist, what
is the plan for their completion?

  No.

19. Will publication of this document change the status of any
existing RFCs?

  No.

20. Describe the document shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of
the document.

  This document requires no IANA actions.

21. List any new IANA registries that require Designated Expert Review
for future allocations.

  This document does not create any IANA registries.