[art] Re: [Last-Call] Artart last call review of draft-eastlake-fnv-28

[Eric Rescorla <[e-mail]>]

I also share Barry Leiba's concerns about publishing this document on the
IETF stream, especially in light of the technical points raised by Watson
Ladd.

The usual reason to publish documents like this in the RFC series is
to make them available to other IETF protocols. Is there some evidence of
demand from the IETF for this algorithm? In this vein, I would note that
the text in this document on this topic is extremely misleading, as it
gives the impresison that it is used in IETF standards:

  The FNV hash is widely used. For example it is referenced in the
  [RFC7357], [RFC7873], and [IEEE8021Qbp] standards documents.

It's true that it is *referenced* by 7357 and 7873, but in neither
case is it a normative reference; it's simply in the context of
needing some pseudorandom function, with FNV given as an example. If
this is the strongest argument that IETF benefits from the publication
of this document, it's a very weak one. IMO the IESG should decline
to publish this document.

-Ekr

On Sat, Oct 5, 2024 at 1:48 PM Barry Leiba via Datatracker <[e-mail]>
wrote:

> Reviewer: Barry Leiba
> Review result: Not Ready
>
> As this is documenting an existing algorithm that was not developed in the
> IETF, we have no control over the substance of the document, so I am not
> commenting on that: it is what it is.
>
> And that's exactly my issue with this: it's in the wrong stream.  The
> shepherd
> writeup says that it was not developed in the IETF and there's no reason
> to put
> it on Standards Track, but also says that there's no reason it "needs to
> go to
> the ISE".  I disagree: this is *exactly* the sort of document that the
> Independent stream is there for.  There is no meaningful sense of IETF
> consensus on this -- all we can have is consensus to publish it as is.
>
> Ultimately, the IESG, not my review, will decide the right answer here.
> Please
> consider asking the ISE to move this to the Independent stream, where I
> think
> it should have been taken in the first place.  Thanks.
>
>
> --
> last-call mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>