Re: [dmarc-ietf] Ben Campbell's Discuss on draft-ietf-dmarc-rfc7601bis-04: (with DISCUSS and COMMENT)

[Scott Kitterman <[e-mail]>]

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 <[e-mail]>
> 
> 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 <[e-mail]>
> > 
> > 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 <[e-mail]>
> > 
> > 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  ([e-mail])
> > > > > http://internetmessagingtechnology.org/