Re: [dmarc-ietf] New diff rfc7601 vs rfc7601bis, was Ben Campbell's Discuss...

Scott Kitterman <sklist@kitterman.com> Mon, 14 January 2019 18:43 UTC

Return-Path: <sklist@kitterman.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 AA14613120B for <dmarc@ietfa.amsl.com>; Mon, 14 Jan 2019 10:43:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=SqmToPNG; dkim=pass (2048-bit key) header.d=kitterman.com header.b=UYox2nyp
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 rGbPJU5lTK6v for <dmarc@ietfa.amsl.com>; Mon, 14 Jan 2019 10:43:03 -0800 (PST)
Received: from softlayer.kitterman.com (softlayer.kitterman.com [169.62.11.132]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CF91131209 for <dmarc@ietf.org>; Mon, 14 Jan 2019 10:43:03 -0800 (PST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812e; t=1547491382; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=KagiZTm+owJy/56xPIiwu5d9RpG9x6DnFlDQ+0zJKnU=; b=SqmToPNGCo8ESc0clpooursQDRxugRbk5L33KxKqWJuhtuF05v9eKye2 yGvZY3xKmkrMZ4WRrzIvSSPvfRvAAA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812r; t=1547491382; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=KagiZTm+owJy/56xPIiwu5d9RpG9x6DnFlDQ+0zJKnU=; b=UYox2nyp+OyMPuGaGtRnRcIov6OiTXize9gYJkfHHduImqHL+YCQHVnY fVx3uGBTSI93gvCHD68L8Zm1uLRh5dVlppA8EyVXcttc8PSXiL9Pg3r5MC XWl8w9V8RsfaHJlBwl2CEysg2QRsmMB10Xhq4wxOrzKCm4hOU7vgMQAw4m K0cDUQJjaLQge3Xvi5WZN/uWKdUVvNjOkn98P7CdMaKSzAhFPG4RQ5teuh uOKgTp4Euy/sUN7ma1VFMj8aL5LdDCfYWs2CbntXJPBsmwegeU+H0iokfI ySccgDVkiXaekcxGT/Gi9+66lFLetQnrIvvsamrZIC9JU87bzQcU7w==
Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by softlayer.kitterman.com (Postfix) with ESMTPSA id 541FF2D408C5 for <dmarc@ietf.org>; Mon, 14 Jan 2019 12:43:02 -0600 (CST)
From: Scott Kitterman <sklist@kitterman.com>
To: dmarc@ietf.org
Date: Mon, 14 Jan 2019 13:43:01 -0500
Message-ID: <1798090.dmMY03Hzt3@kitterma-e6430>
User-Agent: KMail/4.13.3 (Linux/3.13.0-164-generic; KDE/4.13.3; x86_64; ; )
In-Reply-To: <1547491209.3002084.1634374944.4B4105A9@webmail.messagingengine.com>
References: <154275534023.29886.12970892679231398383.idtracker@ietfa.amsl.com> <3900818.4E7hUKDgJz@kitterma-e6430> <1547491209.3002084.1634374944.4B4105A9@webmail.messagingengine.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/1nSET-UyuDacTM41BpgQeE9oXl0>
Subject: Re: [dmarc-ietf] New diff rfc7601 vs rfc7601bis, was Ben Campbell's Discuss...
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: Mon, 14 Jan 2019 18:43:06 -0000

On Monday, January 14, 2019 06:40:09 PM Alexey Melnikov wrote:
> On Mon, Jan 14, 2019, at 6:32 PM, Scott Kitterman wrote:
> > On Monday, January 14, 2019 10:06:02 AM Kurt Andersen wrote:
> > > On Mon, Jan 14, 2019 at 9:39 AM Scott Kitterman <sklist@kitterman.com>
> > > 
> > > wrote:
> > > > On January 14, 2019 3:02:01 PM UTC, "Kurt Andersen (b)"
> > > > <kboth@drkurt.com>
> > > > 
> > > > wrote:
> > > > >On Mon, Jan 14, 2019 at 6:16 AM Murray S. Kucherawy
> > > > ><superuser@gmail.com>
> > > > >
> > > > >wrote:
> > > > >> On Mon, Jan 14, 2019 at 5:03 AM Scott Kitterman
> > > > >
> > > > ><sklist@kitterman.com>
> > > > >
> > > > >> wrote:
> > > > >>> > I see sender-id still has full citizenship.  Now I'm not clear
> > > > >
> > > > >which
> > > > >
> > > > >>> will be
> > > > >>> 
> > > > >>> > first, but my feeling is that rfc7601bis and
> > > > >>> > status-change-change-sender-id-to-historic are going to be
> > > > >
> > > > >published
> > > > >
> > > > >>> more or
> > > > >>> 
> > > > >>> > less at the same time.
> > > > >>> > 
> > > > >>> > When a method is moved to historic, are the corresponding
> > > > >
> > > > >parameters in
> > > > >
> > > > >>> the
> > > > >>> 
> > > > >>> > IANA registry moved to deprecated?  If yes, should the move be
> > > > >
> > > > >stated by
> > > > >
> > > > >>> > which document?
> > > > >>> 
> > > > >>> A quick look at Domainkeys in the registry and RFC 7601 will
> > > > >>> answer
> > > > >
> > > > >that
> > > > >
> > > > >>> question for you.  Let's not hold this up.
> > > > >> 
> > > > >> +1.  This was not identified in IESG Review as something that needs
> > > > >
> > > > >fixing
> > > > >
> > > > >> so I'd just as soon not make more changes now.  If we keep changing
> > > > >
> > > > >it,
> > > > >
> > > > >> it's going to need another cycle through the working group.
> > > > >
> > > > >I had flagged the lack of deprecating Sender ID in my notes to
> > > > >Murray.
> > > > >Since he did not comment back on that, I had assumed he was good with
> > > > >ripping it all out (or marking it as obsolete).
> > > > 
> > > > The registry update policy is expert review.  We won't need another
> > > > RFC to
> > > > deprecate Sender ID when the time comes.
> > > 
> > > Understood, but I was thinking that cutting Sender ID mostly out of
> > > 7601bis
> > > would be appropriate.
> 
> I think removing them from 7601bis != removing them from the IANA registry.
> 
> > So far we have not removed any registry entries, only marked them
> > deprecated (domainkeys for example).  I don't think there's any
> > particular rush to start now.
> 
> Entries should never be removed from an IANA registry, as this would defeat
> one purpose of having a registry. They can only be marked
> historic/deprecated/obsolete, as appropriate for the registry.

Right, but taking it out of 7601bis would leave the problem then of what's the 
appropriate reference in the registry, which, more generally, is how we got to 
the full text replacement of 7601.  Leaving it out of 7601bis would just 
replicate the problem that the latest update was created to fix.

Scott K