Subject: [dmarc-ietf] Genart last call review of draft-ietf-dmarc-eaiauth-03

From: Tim Evens via Datatracker <[email-masked]>
Date: Mon, 11 Mar 2019 15:54:40 -0700

Reviewer: Tim Evens
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-dmarc-eaiauth-??
Reviewer: Tim Evens
Review Date: 2019-03-11
IETF LC End Date: 2019-03-14
IESG Telechat date: Not scheduled for a telechat

Summary:
Ready with nits.

Major issues: None

Minor issues: None

Nits/editorial comments:

Throughout the draft, section references (html rendering) does not correctly
HREF the RFC and section.  For example, page-5 Section 6 has a reference to
section 6.6.1 of RFC7489, but the HTML rendering HREF links to this draft
instead of correctly linking to RFC7489 Section 6.6.1. Ideally the references
should link correctly, for example on page-3 Section 4 with "Section 3 of
[RFC7208]."

---

From: Barry Leiba <[email-masked]>
Date: Tue, 12 Mar 2019 08:01:17 +0900

Thanks for the review, Tim.

The html rendering issues are for the RFC editor to deal with, and not in
the scope of the draft editors.

Barry

---

From: "Tim Evens (tievens)" <[email-masked]>
Date: Mon, 11 Mar 2019 23:43:30 +0000

I should have been more clear.  This is NOT specific to HTML/HREF rendering.   Section references to an RFC without the RFC mentioned is misleading.   For example:

" DMARC [RFC7489] defines a policy language that domain owners can

 specify for the domain of the address in a RFC5322.From header.

 Section 6.6.1 specifies, somewhat imprecisely, how IDNs in the

 RFC5322.From address domain are to be handled.  That section is

 updated to say that all U-labels in the domain are converted to

 A-labels before further processing.  Sections 6.7 and 7.1 are

 similarly updated to say that all U-labels in domains being handled

 are converted to A-labels before further processing."

The above references Section 6.6.1 (and Sections 6.7 and 7.1), but from which RFC(s)? Are these from RFC5322, RFC7489, this draft?   This would be somewhat more clear if this had mentioned the intended referenced RFC (7489) in the same paragraph that the reference is made.  For example, In RFC7849, Section…

Natural language interpolation is challenging.  I agree that there are different ways to reference something that may or may not work with the current renderings. For example:

"In RFC7489, Section 6.6.1 …  "  is equivalent to "Section 6.6.1 [RFC7489]."  IMO, authors (in general) should put effort into checking that the various renderings meet expectations.  If there are incorrect hyperlinks, fix them or remove them.  The rendering issue is not just HTML, it also effects the PDF rendering.

I believe the author is putting in effort to correctly reference the sections, but it's not consistent.  The draft does have many references to sections that correctly link.

Take for example:

"Section 4.3 of [RFC7208] states
   that all IDNs in an SPF DNS record MUST be A-labels; this rule is
   unchanged since any SPF record can be used to authorize either EAI or
   conventional mail.
"

Thanks,
Tim

On 3/11/19, 4:02 PM, "Gen-art on behalf of Barry Leiba" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

The html rendering issues are for the RFC editor to deal with, and not in the scope of the draft editors.

Barry

On Tue, Mar 12, 2019 at 7:54 AM Tim Evens via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:
Reviewer: Tim Evens
Review result: Ready with Nits

Summary:
Ready with nits.

Major issues: None

Minor issues: None

Nits/editorial comments:

---

From: "John R. Levine" <[email-masked]>
Date: 12 Mar 2019 09:31:38 +0900

> The above references Section 6.6.1 (and Sections 6.7 and 7.1), but from which RFC(s)? Are these from RFC5322, RFC7489, this draft?   This would be somewhat more clear if this had mentioned the inte…

All of sectioh 6 is about DMARC and the only RFC mentioned in section 6 is 
7489 so I assumed it was clear enough that's what the references are for. 
I suppose I could add "of RFC 7489" after each section reference but it 
seems awfully pedantic.

> "In RFC7489, Section 6.6.1 … "  is equivalent to "Section 6.6.1 
> [RFC7489]."  IMO, authors (in general) should put effort into checking 
> that the various renderings meet expectations.  If there are incorrect 
> hyperlinks, fix them or remove them.  The rendering issue is not just 
> HTML, it also effects the PDF rendering.

That really seems like something for the tools team or the RFC editor. 
The xref links in the XML are all there, and the stuff you're worried 
about is all mechanically created by xml2rfc.

R's,
John