Re: [DNSOP] Client Validation - filtering validation?

Paul Vixie <paul@redbarn.org> Tue, 28 April 2020 22:12 UTC

Return-Path: <paul@redbarn.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1BA3A0A66 for <dnsop@ietfa.amsl.com>; Tue, 28 Apr 2020 15:12:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 U_UCU7Xt2o2o for <dnsop@ietfa.amsl.com>; Tue, 28 Apr 2020 15:12:21 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B3D83A0A60 for <dnsop@ietf.org>; Tue, 28 Apr 2020 15:12:21 -0700 (PDT)
Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id C5B0BB074A; Tue, 28 Apr 2020 22:12:20 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: dnsop@ietf.org
Cc: sm+ietf@elandsys.com, John Levine <johnl@taugh.com>
Date: Tue, 28 Apr 2020 22:12:20 +0000
Message-ID: <1697536.NgtNXLPDoW@linux-9daj>
Organization: none
In-Reply-To: <20200428215717.6ED0B18837AC@ary.qy>
References: <20200428215717.6ED0B18837AC@ary.qy>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/pv4oLzbeIcJP_YySjQxnazIXlyk>
Subject: Re: [DNSOP] Client Validation - filtering validation?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Apr 2020 22:12:24 -0000

On Tuesday, 28 April 2020 21:57:16 UTC John Levine wrote:
> In article <6.2.5.6.2.20200428121847.081a29e8@elandnews.com> you write:
> >I found a WG draft (expired) from 2017 about RPZ.  I am not sure why
> >it stalled in DNSOP.  There is also a 2018 draft (expired).  I
> >vaguely recall looking at a draft.  However, proposed changes were
> >not accepted.
> 
> One problem is that the last time I looked at it, the draft needed a
> great deal of editing and reorganization to be accessible to people
> who don't already know all about RPZ.  The other is the question of
> documenting something that definitely exists and is implemented but
> has some arguable technical flaws.

the situation at present is, i got way more feedback from reviewers than i 
anticipated, lost heart, and got stuck. it's in the independent editor queue, 
having been determined as non-competitive to any WG's current activity. i'm 
home for the pandemic, so let me pump out an updated draft which will 
hopefully get quick review by the rest of you home for the pandemic.

whatever technical flaws it may have can be enumerated (if there's consensus) 
but not fixed in this draft. we're going to document what exists, so that the 
community can then take it in hand and determine what it becomes.

-- 
Paul