Re: [dmarc-ietf] [dbound] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt
Jothan Frakes <jothan@jothan.com> Wed, 03 April 2019 18:53 UTC
Return-Path: <jothan@jothan.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACF712016D for <dmarc@ietfa.amsl.com>; Wed, 3 Apr 2019 11:53:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jothan-com.20150623.gappssmtp.com
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 bCAewJTZaczL for <dmarc@ietfa.amsl.com>; Wed, 3 Apr 2019 11:53:02 -0700 (PDT)
Received: from mail-vs1-xe41.google.com (mail-vs1-xe41.google.com [IPv6:2607:f8b0:4864:20::e41]) (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 016A212017C for <dmarc@ietf.org>; Wed, 3 Apr 2019 11:53:00 -0700 (PDT)
Received: by mail-vs1-xe41.google.com with SMTP id i207so10611509vsd.10 for <dmarc@ietf.org>; Wed, 03 Apr 2019 11:53:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jothan-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TmN/qrPhRhV1GHX/Sn1HgNa+l66ldBWUCuTHxO6PdO4=; b=EGg3/sVfEi4QVDsYs3oojakuwOArbJQj8diDQu8pcfWE5uJATlHUTNtk9PFwcc3Jdg IsqD26gDAUtVNysBDDCKUvZqBsZ3ECPkZ1xdcA8bQqRGPZaNHaxwPie7x+a5RuZl0+eo x6AB7h4/lWV7fRpx+ocw9SVXQM6mVUfQEnWeDbk4W1UrRYlPrmlx8o/c37Fv2SG5YSdz 8+OowI0KcN1Uh6Gdh/CrAQffjSzDcIe+PVL33ZDcRRtbaS5HjdSYkqUBXAX+T3Gfo2pA GlKLY5hfWSd1LEF/1Ka1OWvXFkE/hYAOzI9hX9q6FP7WQo/TvJxcdBsoni6w6t5ITEFH BjCQ==
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=TmN/qrPhRhV1GHX/Sn1HgNa+l66ldBWUCuTHxO6PdO4=; b=QscFUU24FkO8pvLWgJwco6LDK9krm2yojrWSaxMJCsocz1C9c7dwS8LXZg/4ueHGOO 1P3DMlhx+PPt0cKU9nSaZRdgKJXRk5pF6WjZHsy/e1I91WYCw+rDxPPBbUsj1McNF5rs kRPLOw9PpnfDUHBetCbtOxbzyTWZXE+nbJD22ZkU/mvfPlY91dLVaBYanxe1obTO9XoV 8deLaaT95gHeTjkeeKYvPDhRxIA7eTmJRYorWiEL+P+oMIyvHV2gOummbqBOt6U3J7Ws OlL1V1uj/yy0+odB792gPuV058KGoXRkKjJYp4Ueu9B/UBOElam3e3C6T1PL8GrmPjr5 z5+g==
X-Gm-Message-State: APjAAAVhKSECFzd2Gfe9Xoyhh9i1Z31+hnQejAtTg24B9wf+TXEnt6bH aYGrMnTXen9c8kJ773OjclwQg+MavyfxP4YRDgFyew==
X-Google-Smtp-Source: APXvYqyQd7Vo9aU1pH11vPWKShBswFBM+sGGCwIh1q8z2jRniO0mvlb4C+Xz2cugK15Fb+gGK6v9fpmezmiIX6jFYpE=
X-Received: by 2002:a67:eb41:: with SMTP id x1mr1449705vso.84.1554317579930; Wed, 03 Apr 2019 11:52:59 -0700 (PDT)
MIME-Version: 1.0
References: <3bebe973-0536-96cd-983e-240ba43463c4@dcrocker.net> <20190403175820.8391420115F376@ary.qy>
In-Reply-To: <20190403175820.8391420115F376@ary.qy>
From: Jothan Frakes <jothan@jothan.com>
Date: Wed, 03 Apr 2019 11:52:31 -0700
Message-ID: <CAGrS0FJNg63mevyXpcY_2m30Vt4ZPXVFu+0jLYcLbm-WvD=L+g@mail.gmail.com>
To: John Levine <johnl@taugh.com>
Cc: dmarc@ietf.org, Dave Crocker <dcrocker@bbiw.net>, dbound@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/pS0XOn81XWT98emGmizw9BUNzPs>
Subject: Re: [dmarc-ietf] [dbound] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Apr 2019 18:53:04 -0000
I appreciate the time you invested in this Dave. I definitely like that we're thinking in terms of how to leverage DNS and its distributed model vs emulating the hosts.txt situation, and PSL is essentially a hosts.txt situation. Some assert there is a benefit to being able to contain some form of static list locally for speed. This happens at the trade-off of potentially stale data, which we experience as maintainers receiving energy from expressive TLD admins describing their grief over their domains being directed at search instead of resolving in DNS because their pc, tablet or mobile device runs a browser software that did not contain their TLD. So in those cases (and potentially others) getting things into DNS _might_ be better. I think that a TLD administrator being able to make direct updates in their own zones is vastly better because it would both alleviate the arduous process of validating authority of requests, and streamline the requesting process to near zero on their updates, and enable more direct and exacting control by the registry operators. That said, we fail the community unless the potential replacements take into consideration the many constituent / subjective uses of PSL that have evolved across the years before we tick the box next to any particular solution meeting the diverse needs. We have to tread carefully here. I have great respect for the IETF and the many wise and noble experts that have donated their experience, time and wisdom towards solutions and standards. It is a process that requires patience and I have been told by many in the developer community that it is not always one that is inclusive or able to meet the pace of some development cycles and product or service evolution. The PSL basically came into existence outside of the IETF process, borne of real practical needs, and those needs have forked and matured. There is a 'lenticular' / perspective issue in how different stakeholders are using the PSL. PSL is included in software libraries, which incorporate it without prescribing how a developer might use it. Some care only about the private section of the list, some only about the "ICANN" section. Some integrators of the PSL omit certain elements, or even maintain their own supplementary sections for their project or service needs. Think it is safe to assert variety is present - each have an entirely different need and application of some or all of the PSL's contents than a browser program, search engine, security professional, anti-spam, reporting, SSL Cert, or other use. We (maintainers) don't prescribe specifically how it gets used as volunteer community maintainers, we just try to guide community entries and validate them (and focus on ICP-3 or other I* integrity). PSL is expanding - which grows the file size each time. As potential solutions are presented from web developers or even the IETF (or both) that might help to organize or better architect solutions that could help PSL from heading towards something that emulates the transition from the SRI hosts.txt challenges, I fear that unless we can ensure that some of the dependencies are met by those proposals, the proposals will not endure, and we'll remain using the PSL in a status quo manner. -Jothan Jothan Frakes On Wed, Apr 3, 2019 at 10:58 AM John Levine <johnl@taugh.com> wrote: > > In article <3bebe973-0536-96cd-983e-240ba43463c4@dcrocker.net> you write: > >Comments eagerly sought, of course. > > This seems sorta kinda like my dbound draft, only with _tagged TXT > records rather than a new rrtype, and (unless I missed something) a > hope that somehow you can use a yet to be invented cache to avoid > walking up the tree, where mine used wildcards to do one lookup per > boundary regardless of the tree depth. > > I can see that the tradeoffs are different but I don't see why they're better. > > R's, > John > > >A new version of I-D, draft-dcrocker-dns-perimeter-00.txt > >has been successfully submitted by D. Crocker and posted to the > >IETF repository. > > > >Name: draft-dcrocker-dns-perimeter > >Revision: 00 > >Title: DNS Perimeter Overlay > >Document date: 2019-04-02 > >Group: Individual Submission > >Pages: 20 > >URL: > >https://www.ietf.org/internet-drafts/draft-dcrocker-dns-perimeter-00.txt > > _______________________________________________ > dbound mailing list > dbound@ietf.org > https://www.ietf.org/mailman/listinfo/dbound
- [dmarc-ietf] Fwd: New Version Notification for dr… Dave Crocker
- Re: [dmarc-ietf] Fwd: New Version Notification fo… John Levine
- Re: [dmarc-ietf] [dbound] Fwd: New Version Notifi… Dave Crocker
- Re: [dmarc-ietf] [dbound] Fwd: New Version Notifi… Dave Crocker
- Re: [dmarc-ietf] [dbound] Fwd: New Version Notifi… John R Levine
- Re: [dmarc-ietf] [dbound] Fwd: New Version Notifi… Dave Crocker
- Re: [dmarc-ietf] [dbound] Fwd: New Version Notifi… Jothan Frakes
- Re: [dmarc-ietf] [dbound] Fwd: New Version Notifi… John R Levine
- Re: [dmarc-ietf] [dbound] Fwd: New Version Notifi… tjw ietf
- Re: [dmarc-ietf] [dbound] Fwd: New Version Notifi… Stephen Farrell
- Re: [dmarc-ietf] [dbound] Fwd: New Version Notifi… Jothan Frakes
- Re: [dmarc-ietf] [dbound] Fwd: New Version Notifi… Stephen Farrell
- Re: [dmarc-ietf] [dbound] Fwd: New Version Notifi… Dave Crocker
- [dmarc-ietf] cross-posting (was Re: [dbound] Fwd:… Dave Crocker