IETF Logo Mail Archive

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

Scott Kitterman <sklist@kitterman.com> Mon, 14 January 2019 17:39 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 96F701311DC for <dmarc@ietfa.amsl.com>; Mon, 14 Jan 2019 09:39:08 -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=tkcSkdHj; dkim=pass (2048-bit key) header.d=kitterman.com header.b=eDVTIoT0
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 B6gxYM_IYg5E for <dmarc@ietfa.amsl.com>; Mon, 14 Jan 2019 09:39:06 -0800 (PST)
Received: from softlayer.kitterman.com (softlayer.kitterman.com [IPv6:2607:f0d0:3a01:a3::9]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9953B1311DB for <dmarc@ietf.org>; Mon, 14 Jan 2019 09:39:06 -0800 (PST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812e; t=1547487541; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=p/MWIXJALdiCpJtV4jbNOVfN8D0UWPM2Lce9KJPlGzA=; b=tkcSkdHjlNdRLIcNDvHpMWW8wyjbeOXShBZx1At5tzHR/T6eEj91b6Ot 85ZwKick1EeRQ4nXHZICHqyZ4P7bDQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812r; t=1547487541; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=p/MWIXJALdiCpJtV4jbNOVfN8D0UWPM2Lce9KJPlGzA=; b=eDVTIoT0thik9EsG99WnUJSHmy4RL8QfBmZwvw8cK27PNXhzgcKujoB/ SOZ2LGnZFXtGl4FQQCL1MOdi0AE/93s2tO+Jnznve4p2SOmt1hYyS3Ubok Tq31Y5/88o7AVK+osQSMkVa8fm3kIKj23UWR7SCetOSX/oHRxsFNslCiRI v/smif3JoklN6wqpNXzjfBeK0aqmPw3++gxi0a/ApJ/7KU/r1qvk+BpjS4 zmM1vcwJxqI+oGKo5a8rmQZjHe+N3BbT+Pv2WaFMBzQqZm+V8Yne2W+4rb iXEc9TMQHeiVVya8mGf4mX+mbfR9h/CfzHL64vp364Kccc4ZhCR1Ug==
Received: from [192.168.1.148] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by softlayer.kitterman.com (Postfix) with ESMTPSA id C05932D4081D; Mon, 14 Jan 2019 11:39:01 -0600 (CST)
Date: Mon, 14 Jan 2019 17:38:59 +0000
In-Reply-To: <CABuGu1qtj6bz81225CjE9kbQfaTA80X18obkb8tvTwZNO8i5fA@mail.gmail.com>
References: <154275534023.29886.12970892679231398383.idtracker@ietfa.amsl.com> <CAL0qLwbhjz+SRtjTqVht32z-y8XxzVikvRDo2D=ZZKcoTNiL3w@mail.gmail.com> <2272f6d5-6c80-b80d-4aff-bdcc69449cf8@tana.it> <1927558.aO5YKDjPkr@kitterma-e6430> <CAL0qLwYpExvrBh2tRUoFNRqkUBefqr2S-F5jh6xVR=fyRTjhBg@mail.gmail.com> <CABuGu1qtj6bz81225CjE9kbQfaTA80X18obkb8tvTwZNO8i5fA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
To: dmarc@ietf.org
From: Scott Kitterman <sklist@kitterman.com>
Message-ID: <9223F7C0-4412-4123-9DBA-7E0BDC822C32@kitterman.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/xLwUQqwIpMy97EwubN6Tflq7R9c>
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 17:39:09 -0000


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.

Scott K

v2.23.0 | Report a Bug | By Email