[art] Artart last call review of draft-eastlake-fnv-28

Barry Leiba via Datatracker <noreply@ietf.org> Sat, 05 October 2024 20:46 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: art@ietf.org
Delivered-To: art@ietfa.amsl.com
Received: from [10.244.8.145] (unknown [104.131.183.230]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD95C14F61F; Sat, 5 Oct 2024 13:46:41 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Barry Leiba via Datatracker <noreply@ietf.org>
To: art@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.25.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <172816120099.282330.5360535206284650774@dt-datatracker-cb674fff7-jr9km>
Date: Sat, 05 Oct 2024 13:46:41 -0700
Message-ID-Hash: EJKDS7ZF4X3UOODMLJRBUH3DLJARZR75
X-Message-ID-Hash: EJKDS7ZF4X3UOODMLJRBUH3DLJARZR75
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-art.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-eastlake-fnv.all@ietf.org, last-call@ietf.org
X-Mailman-Version: 3.3.9rc5
Reply-To: Barry Leiba <barryleiba@computer.org>
Subject: [art] Artart last call review of draft-eastlake-fnv-28
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/TKSe4O3Bg8lXCjvXeUnZlhYiX3Q>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Owner: <mailto:art-owner@ietf.org>
List-Post: <mailto:art@ietf.org>
List-Subscribe: <mailto:art-join@ietf.org>
List-Unsubscribe: <mailto:art-leave@ietf.org>

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.