Re: [dispatch] Genart last call review of draft-hardie-dispatch-rfc3405-update-03

Barry Leiba <barryleiba@computer.org> Tue, 01 September 2020 15:08 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: expand-draft-hardie-dispatch-rfc3405-update.all@virtual.ietf.org
Delivered-To: dispatch@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id E2E123A0B77; Tue, 1 Sep 2020 08:08:21 -0700 (PDT)
X-Original-To: xfilter-draft-hardie-dispatch-rfc3405-update.all@ietfa.amsl.com
Delivered-To: xfilter-draft-hardie-dispatch-rfc3405-update.all@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8627A3A0B54; Tue, 1 Sep 2020 08:08:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Level:
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHfLGJQaKEcQ; Tue, 1 Sep 2020 08:08:20 -0700 (PDT)
Received: from mail-io1-f44.google.com (mail-io1-f44.google.com [209.85.166.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CCAE3A0B52; Tue, 1 Sep 2020 08:08:20 -0700 (PDT)
Received: by mail-io1-f44.google.com with SMTP id b16so1594136ioj.4; Tue, 01 Sep 2020 08:08:20 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nL9RCUy7/Y/QsZAAOfxjtPz+bqgaZxytfgMg29eyRjc=; b=lx7ZJ1oEd8FTwLKqp5i8buXj5jfexbOT8dIJYJYlcDUNHQOn3eSmwK9F2ztMfLxfIw 3D4MWnETYYCsDfSXqboBZ6jHpB3ARXKkba+1s8IlFJIgI6nXfGZN/+QfXOpCIX3putwo x7BOB6sPsGJE2Az/lQEZIa5Xby69PoHmb4eJvPr/snHl3ILGtj+wAphom8v+Lf1ZnIgA ZYhFEz09EWK72TL0WKzMTk7Th+RnWqRDpKPJjpvvUTgjcJ/GzK6VOTJH4LZgaeMMXJ7V vhAagcULoeYMxbgAWDn9D8ZlItsYeEuzuPxuDS2iBhM5WvrxeBKdoFFy3w52lwQepNE+ F4NA==
X-Gm-Message-State: AOAM531vl7R0goJD4cXIHshWzFZGrMIBZT8MQwVBM3Ywk7RP6uXRmaMu f1M5qK1322yWl4AEO19HK0XjPennSLB1Rs0VgQk=
X-Google-Smtp-Source: ABdhPJz6BjGevfy4XvWsHl8k6HaXEdYuzBupUs1LFVDSJU2RFZ7cy6yqjV6FmZbNEm0Bk9x65Aufgd/SJGa/qpVIF7A=
X-Received: by 2002:a5d:80d2:: with SMTP id h18mr1854862ior.61.1598972899393; Tue, 01 Sep 2020 08:08:19 -0700 (PDT)
MIME-Version: 1.0
References: <159893058662.23844.17177953972396775177@ietfa.amsl.com> <1066090379.166058.1598958286518@email.ionos.com>
In-Reply-To: <1066090379.166058.1598958286518@email.ionos.com>
From: Barry Leiba <barryleiba@computer.org>
Date: Tue, 01 Sep 2020 11:08:08 -0400
Message-ID: <CALaySJJaUDysmd+MFtQY1EfxjhVTq9sxEbQa6tf6Wy8g_3ERiA@mail.gmail.com>
To: Timothy Mcsweeney <tim@dropnumber.com>
Cc: Brian Carpenter <brian.e.carpenter@gmail.com>, draft-hardie-dispatch-rfc3405-update.all@ietf.org, last-call@ietf.org
Content-Type: text/plain; charset="UTF-8"
Resent-From: alias-bounces@ietf.org
Resent-To: ted.ietf@gmail.com, superuser@gmail.com, barryleiba@computer.org, barryleiba@gmail.com, spencerdawkins.ietf@gmail.com, dispatch@ietf.org
Resent-Message-Id: <20200901150821.E2E123A0B77@ietfa.amsl.com>
Resent-Date: Tue, 01 Sep 2020 08:08:21 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/IAYcp5k_NZKTjU2xQlE-ZQmLSTw>
Subject: Re: [dispatch] Genart last call review of draft-hardie-dispatch-rfc3405-update-03
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Sep 2020 15:08:22 -0000

(Removed the GenART list, as this discussion doesn't apply to Brian's
GenART review.)

Tim, thanks for the comments.

> According to BCP26/RFC8126 section 5.3 Designated expert reviews, it says:"
>
>    When a designated expert is used, the documentation should give clear
>    guidance to the designated expert, laying out criteria for performing
>    an evaluation and reasons for rejecting a request.
>
> I don't see the above in this document.  This is going to have to be added to have any kind of
> validity or the IESG should reject to publication of this document.  Especially because this entire
> document will updating the IANA considerations section of rfc3405.

As the person who added that quoted text to BCP 26, I'm clearly in
favour of making sure that guidance to the DEs is available, and I
often push on this in my reviews as Area Director.  So I have a warm
spot for what you say here.  I this case, though, I disagree with the
conclusion that such guidance has to be explicitly added:

1. When my AD reviews push on this point, it is almost always
(possibly completely always) as a non-blocking comment, not a DISCUSS
position.  In other words, I strongly encourage the English sense of
the "should" in the quoted text, but don't insist on it.  It's not a
requirement for publication.

2. RFC 3405 pre-dates RFC 8126, and the version of BCP 26 that was in
effect at the time, RFC 2434 did not include the suggestion above.
While it's certainly possible to add such guidance now, this update is
very narrowly targeted to fix a serious problem, and I would not want
debate about additional text to get in the way of that.  There's
plenty of precedent for these sorts of laser-focused updates that do
not otherwise bring the original documents up to current standards.

3. I believe that 3405 is already clear enough in this regard in
Section 3.1.2 and doesn't require further clarification.  With this
proposed update to Section 3.1.1, we can get back to having a clear
way to register NAPTR records for URI schemes in the URI.ARPA zone.

Barry