Re: [dmarc-ietf] Mention ICANN/operational limitations was: Re: Working Group Last Call: draft-ietf-dmarc-psd

Alessandro Vesely <vesely@tana.it> Sat, 13 July 2019 17:21 UTC

Return-Path: <vesely@tana.it>
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 206D41200E6 for <dmarc@ietfa.amsl.com>; Sat, 13 Jul 2019 10:21:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 dTn96ZUeexDr for <dmarc@ietfa.amsl.com>; Sat, 13 Jul 2019 10:21:49 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C41A120115 for <dmarc@ietf.org>; Sat, 13 Jul 2019 10:21:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1563038502; bh=motTds9Ih2iwl7XOOMyVRHDz94IEhn2IGKMGwmP8KKA=; l=850; h=To:References:From:Date:In-Reply-To; b=AgIGNBuX+qitMBod9bYlYZvnc49cRGf5K8PujLL2fNcyeFkPqYF4F1G4AOATpyQBj NUhinYSobFkIbRlxTRI+r0nm+TtK4AHjkekajW/jeuNIgKCPP2GPUoo81tP+h/QviC dbEzHsep3qSVC3NQ5jtfys7MQESPbPCANLkdrEkk/cLO8GDfMtO9/85oSaCHS
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [192.168.1.100] ([5.170.9.203]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1.2, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC050.000000005D2A1326.00003CD8; Sat, 13 Jul 2019 19:21:40 +0200
To: dmarc@ietf.org
References: <CAL0qLwbbz_UhBLsURg=eXhRBC2g9OghiN==T9Uq9pFuLtd=b7w@mail.gmail.com> <CAOZAAfN0+nxpN1P_nk3y5f8MTQ=c7DYNvYic2iDMuCK_bNa=qg@mail.gmail.com> <1783751.gHVjF1RMII@l5580>
From: Alessandro Vesely <vesely@tana.it>
Openpgp: preference=signencrypt
Message-ID: <0c52a75d-1a67-d095-f5f6-e74a8a4ff958@tana.it>
Date: Sat, 13 Jul 2019 19:21:31 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2
MIME-Version: 1.0
In-Reply-To: <1783751.gHVjF1RMII@l5580>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/N8PtfvirXqH_SgYaQ_YwRLXnVxE>
Subject: Re: [dmarc-ietf] Mention ICANN/operational limitations was: Re: Working Group Last Call: draft-ietf-dmarc-psd
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: Sat, 13 Jul 2019 17:21:52 -0000

On Fri 12/Jul/2019 19:41:17 +0200 Scott Kitterman wrote:
> How about this instead:
> 
> "As of the writing of this document operational and policy constraints prevent 
> this experiment from being deployed globally.  If the experiment shows that 
> PSD solves a real problem and can be used at a large scale, the results could 
> prove to be useful in the development of policies outside of the IETF that 
> would permit broader deployment".


I'm not familiar with operating a TLD.  The above text seems to imply
that TLD operators cannot just edit their zone files as they like.  In
that case, couldn't that statement be more explicit?  In particular,
what does allow the experiment to be deployed locally?


> Also, since this is about ephemera and not protocol, I think it should go in 
> Appendix A.


Makes sense.


Best
Ale
--