IETF Logo Mail Archive

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

"John R. Levine" <johnl@iecc.com> Tue, 12 March 2019 00:31 UTC

Return-Path: <johnl@iecc.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 095E912797C for <gen-art@ietfa.amsl.com>; Mon, 11 Mar 2019 17:31:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com
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 vKEQEXWRDxUI for <gen-art@ietfa.amsl.com>; Mon, 11 Mar 2019 17:31:15 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF82E1279A5 for <gen-art@ietf.org>; Mon, 11 Mar 2019 17:31:14 -0700 (PDT)
Received: (qmail 40256 invoked from network); 12 Mar 2019 00:31:13 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=9d3e.5c86fdd1.k1903; bh=752cNkSTadU+uXet3sQTx+ZJ1WeNj5W55JysCf+DryY=; b=LKctgIqwzQxnasZh1/pXsOZqrSrXPqXWxcmNONU9jnUkbEPfEKBPx5/XcsoeeZ7PkKr9s3F3KeT90rdRfNdULPizAovPS3qcezcfWJoHpldFxSsX7ZRZ18pj8GBnl572P1gDvicOTRlvdEuHLnnaVrlIijRihn/+dglZq0L3PrfIk542bb/y/V3VuOKf7CiefxfkzdBiC7Mgzp9xOt4e8YqSthopMuQIVaw+D8al6hxOegkFLf2hQs+X1SwFara6
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 12 Mar 2019 00:31:12 -0000
Date: Tue, 12 Mar 2019 09:31:38 +0900
Message-ID: <alpine.OSX.2.21.1903120927080.49371@ary.local>
From: "John R. Levine" <johnl@iecc.com>
To: "Tim Evens (tievens)" <tievens@cisco.com>
Cc: Barry Leiba <barryleiba@computer.org>, Tim Evens via Datatracker <noreply@ietf.org>, "gen-art@ietf.org" <gen-art@ietf.org>, "dmarc@ietf.org" <dmarc@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, Tim Wicinski <tjw.ietf@gmail.com>, Murray Kucherawy <superuser@gmail.com>, alexey.melnikov@isode.com, ben@nostrum.com, adam@nostrum.com, Alexey Melnikov <aamelnikov@fastmail.fm>, Kurt Andersen <kurta@drkurt.com>
In-Reply-To: <53F5AD4A-BCE9-4E00-A982-4365BBD9ACA8@cisco.com>
References: <155234487991.23094.14124317288389045798@ietfa.amsl.com> <CALaySJK9h=xs4ZcmkTKf1ffpCv4ayhQ_NqPWzHGg17oRLrizNQ@mail.gmail.com> <53F5AD4A-BCE9-4E00-A982-4365BBD9ACA8@cisco.com>
User-Agent: Alpine 2.21 (OSX 202 2017-01-01)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="0-2007234127-1552350703=:49371"
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/VA1fuClgcUsKZiuqgjgPJQ4kc_M>
Subject: Re: [Gen-art] [taugh.com-standards] Re: Genart last call review of draft-ietf-dmarc-eaiauth-03
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Mar 2019 00:31:18 -0000

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

v2.23.0 | Report a Bug | By Email