Re: [DNSOP] Client Validation - filtering validation?

John Levine <johnl@taugh.com> Tue, 28 April 2020 21:57 UTC

Return-Path: <johnl@iecc.com>
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 8632C3A09DA for <dnsop@ietfa.amsl.com>; Tue, 28 Apr 2020 14:57:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.85
X-Spam-Level:
X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=qQqlFs2w; dkim=pass (1536-bit key) header.d=taugh.com header.b=DYSxNyCu
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 pJJCiBSGt0sL for <dnsop@ietfa.amsl.com>; Tue, 28 Apr 2020 14:57:19 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C3CA3A0946 for <dnsop@ietf.org>; Tue, 28 Apr 2020 14:57:18 -0700 (PDT)
Received: (qmail 39305 invoked from network); 28 Apr 2020 21:57:17 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=9985.5ea8a6bd.k2004; bh=aKdvKOR1mdQgAcCVTmjDyRMRizOotfrNUBNKxbLwU68=; b=qQqlFs2w5mR2P+3Yanh3OYIahPtLRJ7hmZVMi46Q9vHV2QPDZqe2+sHY9XM6SyxAsrUk822TqeBAB64vM7WD7eCO/6Zdgvvvs744nP82J93P3p8bmCgGA9JlXucP0yxHew7vj3DALq3OzcI/MuLSvNsmZSSwwL9huGgx4MvoWqoeKihkbOlpeMHaH+Lzv3FxdmzLbiigyMlf9aczr0DW7V4KzepL0ncXBr5nJ8vmcEuSzyTlwm4bi7sR352ZO3t8
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=9985.5ea8a6bd.k2004; bh=aKdvKOR1mdQgAcCVTmjDyRMRizOotfrNUBNKxbLwU68=; b=DYSxNyCuB2Hatlb734MpgZ4U/afLHoBgqCnswjwR4gHkqmwwQ9gelz9sz5wcae716mtId58APQ2xk5pUsQfr91VMLaQzNfSkFUM7xDtQ6+j53U+b8tf2A6+h7biuzwQIOwSpAH9fvsg2gSPQL6G/ZX5m3KXpffji9x+3YuqVWuNkUpD0+nFCRN8qUCkQ/9eAEvn+m6udW8Vg8K53CGSknORX35HjTj3dg/s1geoXbNo/QOfLkOZWl/v1wi/DyB5B
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 28 Apr 2020 21:57:17 -0000
Received: by ary.qy (Postfix, from userid 501) id 6ED0B18837AC; Tue, 28 Apr 2020 17:57:16 -0400 (EDT)
Date: Tue, 28 Apr 2020 17:57:16 -0400
Message-Id: <20200428215717.6ED0B18837AC@ary.qy>
From: John Levine <johnl@taugh.com>
To: dnsop@ietf.org
Cc: sm+ietf@elandsys.com
In-Reply-To: <6.2.5.6.2.20200428121847.081a29e8@elandnews.com>
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/1MvHrBByQxh9wpvjthOq8vlf4RE>
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 21:57:25 -0000

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.

R's,
John