Re: [dmarc-ietf] Ben Campbell's Discuss on draft-ietf-dmarc-rfc7601bis-04: (with DISCUSS and COMMENT)
Scott Kitterman <sklist@kitterman.com> Sun, 06 January 2019 07:27 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 A0F15129B88 for <dmarc@ietfa.amsl.com>; Sat, 5 Jan 2019 23:27:31 -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=fkAF6Yf4; dkim=pass (2048-bit key) header.d=kitterman.com header.b=dqQRzRJG
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 PVEljtGu6gei for <dmarc@ietfa.amsl.com>; Sat, 5 Jan 2019 23:27:29 -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 13EF31200D7 for <dmarc@ietf.org>; Sat, 5 Jan 2019 23:27:28 -0800 (PST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812e; t=1546759645; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=RsfhnEzdBEUelE32oujcpKtVaWAJuUv2VyArlJ4zD8s=; b=fkAF6Yf4pME7qlp2armP2TNjSY/67k0cgOK6TgZVsqG0bcwd1K0zgybg wQfyEaqIjXzD81I8wJljqsn4iUWMDQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812r; t=1546759645; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=RsfhnEzdBEUelE32oujcpKtVaWAJuUv2VyArlJ4zD8s=; b=dqQRzRJGFHDYfvA+UPbxG+zV1k4xKlTOaDRN5PUIeD7rfsGDZ5dTndyJ K442M1fVEzCEC/sh9D1EoUiOU177EWUTdryW5Mb/GVVt6liNEyRgF4pP42 0qD9nuRXNjRTk8GgtJEzrGuOY5zk9o1SPSmrbryyUqvYS0D94SbOn+c0BT 2eb691HkLSFtdrAk7bWadbEJc+73dOyOeeAb4eeHBJc8qbfDIW5K8gs/ba HsVbu8ba4IQg9SjTGIMcSDhhE02oIerXZzx3yNtHMhich5xs3S9SSBGaEE txHBCP2zXsKEyfFf2jg/gS/vp8GV85477iVYIHKMOkjMcS9WLR4DcQ==
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 098A82D40834 for <dmarc@ietf.org>; Sun, 6 Jan 2019 01:27:25 -0600 (CST)
From: Scott Kitterman <sklist@kitterman.com>
To: IETF DMARC WG <dmarc@ietf.org>
Date: Sun, 06 Jan 2019 02:27:24 -0500
Message-ID: <12578706.O8KzW9sDEf@kitterma-e6430>
User-Agent: KMail/4.13.3 (Linux/3.13.0-163-generic; KDE/4.13.3; x86_64; ; )
In-Reply-To: <CAL0qLwbhjz+SRtjTqVht32z-y8XxzVikvRDo2D=ZZKcoTNiL3w@mail.gmail.com>
References: <154275534023.29886.12970892679231398383.idtracker@ietfa.amsl.com> <1543613485.3765543.1594837224.1E64FAB8@webmail.messagingengine.com> <CAL0qLwbhjz+SRtjTqVht32z-y8XxzVikvRDo2D=ZZKcoTNiL3w@mail.gmail.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/6MR0j7IM8bdoryrd1y-46NRMggQ>
Subject: Re: [dmarc-ietf] Ben Campbell's Discuss on draft-ietf-dmarc-rfc7601bis-04: (with DISCUSS and COMMENT)
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: Sun, 06 Jan 2019 07:27:31 -0000
I think this is generally good. I, of course, have a few comments. Hunk at "page 17, line 44": Perhaps another sentence (more for completeness than anything) at the end of the new paragraph. Something like, "Additionally, [RFC8463] added a new signing algorithm in DKIM, ed25519-sha256 and it is also useful to be able to distinguish such signatures to identify cryptographic algorithm specific failures." That would also need a new informative reference to RFC 8463. Hunk at "page 18, line 32": "Note that in an EAI-formatted message, the "mailfrom" value can be expressed in UTF-8." Isn't it more correct to say that the local part of the "mailfrom" value can be expressed in UTF-8? The domain part is still a U-label as I understand it. The text as written is literally correct since the entire mailfrom is valid UTF-8, but I'm afraid it may be misleading. As written, I could see it causing confusion relative to the guidance in Section 5. Hunk at "page 21, line 21": Same comment re UTF-8. Hunk at "page 22, line 4": Someone who has read the VBR RFC recently enough to remember should check and see if my UTF-8 comment applies here nor not. I'm not sure either way. Scott K On Saturday, January 05, 2019 09:45:57 PM Murray S. Kucherawy wrote: > Here's what I've come up with. This is a diff between RFC7601 as published > and what I propose as RFC7601bis to resolve all of the DISCUSSes and most > of the COMMENTs from IESG review. Please let me know if I've missed > anything. I'll post it at the end of the coming week if there are no > issues raised. > > http://www.blackops.org/~msk/draft-kucherawy-dmarc-rfc7601bis-from-rfc7601.d > iff.html > > -MSK > > On Fri, Nov 30, 2018 at 1:31 PM Alexey Melnikov <aamelnikov@fastmail.fm> > > wrote: > > On Fri, Nov 30, 2018, at 8:54 PM, Barry Leiba wrote: > > > Murray, would you please copy the relevant IANA Considerations > > > sections from RFC 7601 into 7601bis and change the tenses > > > appropriately (perhaps just with a sentence in each subsection that > > > says, "The following was done in the previous edition of this > > > document, RFC 7601:", or some such > > > > Even better if you say something like "the following is unchanged from RFC > > 7601:". > > > > >), and then let's have a quick > > > > > > working group review of the result? (And, of course, change it back > > > to "obsoletes" rather than "updates".) > > > > > > As it's editorial, I'm sure we don't need to go back through any > > > approval process, and we can get the DISCUSS cleared and move forward. > > > > I agree. I think this is purely editorial, albeit an important issue for > > the final document. > > > > > Thanks, > > > Barry > > > On Fri, Nov 30, 2018 at 2:00 PM Alexey Melnikov <aamelnikov@fastmail.fm> > > > > wrote: > > > > Hi all, > > > > > > > > On Wed, Nov 21, 2018, at 9:39 PM, Barry Leiba wrote: > > > > > I actually agree with this: I think the better answer is to go back > > > > to > > > > > > > "obsoletes" and to have this document include the details of what > > > > > was > > > > > put in the registries before. But the working group decided to do > > > > > it > > > > > the other way, and there's been criticism in the past of ADs (and, > > > > so, > > > > > > > by extension, chairs) picking on this sort of stuff, so I decided to > > > > > let it go. I'll let the IESG sort this one out, but I'll go on > > > > record > > > > > > > as saying what I think the better way to handle it is. > > > > > > > > I think incorporating older registrations is the cleaner way of > > > > dealing with Ben's & Benjamin's DISCUSSes, as then the document is self > > contained and there is no need for readers to see obsoleted RFCs. So this > > would be my preference. > > > > > > If the WG doesn't want to do this, then the document needs editing to > > > > be correct as per Benjamin's DISCUSS. > > > > > > Best Regards, > > > > Alexey > > > > > > > > > That said, I don't think it's a huge deal either way. > > > > > > > > > > Barry > > > > > > > > > > On Tue, Nov 20, 2018 at 6:09 PM Ben Campbell <ben@nostrum.com> > > > > wrote: > > > > > > Ben Campbell has entered the following ballot position for > > > > > > draft-ietf-dmarc-rfc7601bis-04: Discuss > > > > > > > > > > > > When responding, please keep the subject line intact and reply to > > > > all > > > > > > > > email addresses included in the To and CC lines. (Feel free to cut > > > > this > > > > > > > > introductory paragraph, however.) > > > > > > > > > > > > > > > > > > Please refer to > > > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > > > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > > > > > > > The document, along with other ballot positions, can be found > > > > > > here: > > > > > > https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/ > > > > ---------------------------------------------------------------------- > > > > > > > > DISCUSS: > > ---------------------------------------------------------------------- > > > > > > > > This is mainly a process discuss. I share Alvaro's concern about > > > > this being > > > > > > > > marked as "updating" RFC7601, when it seem like a full > > > > replacement. I'm > > > > > > > > promoting it to a DISCUSS because I think this needs to be > > > > resolved before > > > > > > > > publication. > > > > > > > > > > > > The current structure will make it very difficult for readers to > > > > figure out > > > > > > > > which parts of each doc they need to worry about. I think it needs > > > > to either go > > > > > > > > back to "obsoleting" 7601, or it needs to be recast to just talk > > > > about the > > > > > > > > changes. Note that if the former path is chosen, the IANA > > > > considerations in > > > > > > > > 7601 will need to be copied forward. > > > > ---------------------------------------------------------------------- > > > > > > > > COMMENT: > > ---------------------------------------------------------------------- > > > > > > > > I mostly just reviewed the diff. Thank you for mostly avoiding > > > > unnecessary > > > > > > > > changes. That makes the diff tools much more useful than they are > > > > for bis > > > > > > > > drafts that make wholesale organization and stylistic changes. > > > > > > > > > > -- > > > > > Barry > > > > > -- > > > > > Barry Leiba (barryleiba@computer.org) > > > > > http://internetmessagingtechnology.org/
- [dmarc-ietf] Ben Campbell's Discuss on draft-ietf… Ben Campbell
- Re: [dmarc-ietf] Ben Campbell's Discuss on draft-… Barry Leiba
- Re: [dmarc-ietf] Ben Campbell's Discuss on draft-… Alexey Melnikov
- Re: [dmarc-ietf] Ben Campbell's Discuss on draft-… Kurt Andersen (b)
- Re: [dmarc-ietf] Ben Campbell's Discuss on draft-… Barry Leiba
- Re: [dmarc-ietf] Ben Campbell's Discuss on draft-… Ben Campbell
- Re: [dmarc-ietf] Ben Campbell's Discuss on draft-… Alexey Melnikov
- Re: [dmarc-ietf] Ben Campbell's Discuss on draft-… Murray S. Kucherawy
- Re: [dmarc-ietf] Ben Campbell's Discuss on draft-… Scott Kitterman
- Re: [dmarc-ietf] Ben Campbell's Discuss on draft-… Alexey Melnikov
- [dmarc-ietf] New diff rfc7601 vs rfc7601bis, was … Alessandro Vesely
- Re: [dmarc-ietf] New diff rfc7601 vs rfc7601bis, … Scott Kitterman
- Re: [dmarc-ietf] New diff rfc7601 vs rfc7601bis, … Murray S. Kucherawy
- Re: [dmarc-ietf] New diff rfc7601 vs rfc7601bis, … Kurt Andersen (b)
- Re: [dmarc-ietf] New diff rfc7601 vs rfc7601bis, … Scott Kitterman
- Re: [dmarc-ietf] New diff rfc7601 vs rfc7601bis, … Kurt Andersen (b)
- Re: [dmarc-ietf] New diff rfc7601 vs rfc7601bis, … Scott Kitterman
- Re: [dmarc-ietf] New diff rfc7601 vs rfc7601bis, … Alexey Melnikov
- Re: [dmarc-ietf] New diff rfc7601 vs rfc7601bis, … Scott Kitterman
- Re: [dmarc-ietf] New diff rfc7601 vs rfc7601bis, … Kurt Andersen (b)
- Re: [dmarc-ietf] Ben Campbell's Discuss on draft-… Ben Campbell
- Re: [dmarc-ietf] Ben Campbell's Discuss on draft-… Alexey Melnikov
- Re: [dmarc-ietf] Ben Campbell's Discuss on draft-… Murray S. Kucherawy
- Re: [dmarc-ietf] Ben Campbell's Discuss on draft-… Scott Kitterman