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
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 <noreply@xxxxxxxx> 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 -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
