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/