Re: [dmarc-ietf] [Gen-art] [] Re: Genart last call review of draft-ietf-dmarc-eaiauth-03

Alissa Cooper <> Wed, 10 April 2019 16:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8CEDF1200CD; Wed, 10 Apr 2019 09:01:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=FE1ZRHw6; dkim=pass (2048-bit key) header.b=uCeZgEv/
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id f64pRP1qaaQg; Wed, 10 Apr 2019 09:01:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2C19D1202FA; Wed, 10 Apr 2019 09:01:19 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal []) by mailnew.nyi.internal (Postfix) with ESMTP id BE754D825; Wed, 10 Apr 2019 12:01:17 -0400 (EDT)
Received: from mailfrontend1 ([]) by compute7.internal (MEProxy); Wed, 10 Apr 2019 12:01:17 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=Q TQB+iFAoD8qzy5TnA9QII/4znlaCuf5D/uWFkxOCmY=; b=FE1ZRHw6+aTt2tUSJ M+kVF9Jl1tQEJDM35DU6ejqKgNNv2oAw2JwU2dpK8MKe2GzP8GtyUf8mM2MYMeAB LsH5uQZOVx3FcxyASeqD6gbuDnh5R0fAqtR5FNLZu5WAPssczKJFWT/M1eJjP/Mb seaFLmYwNggkAgIh4zoZQVt7qp7xdWPKMs4Tzvv6hV8hVe9PHhWK0j0oyzAWB2zS glzmKKJ/PnkBHwn2tJQraIkBkJE4QGed8YvQjDSG8b0LpyYh+EXQjJusXqwSXiWZ y83FZK2qOimgq7ew8Gw3IZ85Ld73+kdzBwBe5Xhg7itlqmcnilQQgijwvoC6IZDW jEWNw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=QTQB+iFAoD8qzy5TnA9QII/4znlaCuf5D/uWFkxOC mY=; b=uCeZgEv/g8+/yFUj9vHxBvHOXhh5usuAiAfw/HKUMWVeEO/Mu8j9rpQGH Pwy+AxvwI8VP05nTYPzRNlDcrvptSk9ST5fP/UqtcumIDMoax/k5W8X47AdyDPxr q8HpFe5sHNQT1helIEi2t+Y7zTo6QPPJNC8XChSzC/CSIlBtEhE5VfnZ34FrlqAV 7Kqiji5hgWf4SBxAilXbYiXZBveMZWx49zRWYdMWrK8XgMFTVGKU42h1Y64gEz39 bS9wyAytGSkGzohF0Glleh/wVQm9Cf6jlNaNSuQrflofkdgi9f754y9IHf5NaVcl 6sVfTTBrOjuu/bTbqR1Bch9vaLI3A==
X-ME-Sender: <xms:TROuXOashKcgDWAeUF57p0L0F1DW71o7g6Fs63GDFExcpoVA9mHS3A>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudejgdelkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrih hnpehivghtfhdrohhrghdpthgruhhghhdrtghomhenucfkphepudejfedrfeekrdduudej rdekjeenucfrrghrrghmpehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrd hinhenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:TROuXNUAIahUQe_veUOlE_DRcwpkMnuQ8o0_1RAE7WOWhtmvuydEjw> <xmx:TROuXPFUCnpoExfxPwv2kNaSfQ9lYg9nNIT7Yt8KIKJU2a1iWtobmQ> <xmx:TROuXHCJiK0-KvcSvqXrwIS5EgLKkFdyIgCnmDcEOVUTfvGgKKiVUw> <xmx:TROuXKJYcgxOVlZ7W67DZpFqNGvLLjEvxOKQndAyEGZxpVCMPVN8QA>
Received: from (unknown []) by (Postfix) with ESMTPA id CE4AFE41C3; Wed, 10 Apr 2019 12:01:14 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Alissa Cooper <>
In-Reply-To: <alpine.OSX.2.21.1903120927080.49371@ary.local>
Date: Wed, 10 Apr 2019 12:01:11 -0400
Cc: Tim Wicinski <>, Ben Campbell <>, Adam Roach <>, "" <>, Alexey Melnikov <>, Tim Evens via Datatracker <>, "" <>, "" <>, Murray Kucherawy <>, Barry Leiba <>, Kurt Andersen <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <alpine.OSX.2.21.1903120927080.49371@ary.local>
To: "John R. Levine" <>, "Tim Evens (tievens)" <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
X-Mailman-Approved-At: Sat, 13 Apr 2019 05:47:37 -0700
Subject: Re: [dmarc-ietf] [Gen-art] [] Re: Genart last call review of draft-ietf-dmarc-eaiauth-03
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 10 Apr 2019 16:01:22 -0000

Tim, thanks for your review. John, thanks for your response. I can see how the section references could be a little confusing, but given the context of the surrounding text, I think leaving them as-is is ok. I entered a No Objection ballot.


> On Mar 11, 2019, at 8:31 PM, John R. Levine <> wrote:
> On Mon, 11 Mar 2019, Tim Evens (tievens) wrote:
>> 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…
> 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_______________________________________________
> Gen-art mailing list