Re: [dmarc-ietf] [taugh.com-standards] Benjamin Kaduk's Discuss on draft-ietf-dmarc-eaiauth-04: (with DISCUSS and COMMENT)

Barry Leiba <barryleiba@computer.org> Fri, 05 April 2019 19:54 UTC

Return-Path: <barryleiba@gmail.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 DFBDE120602; Fri, 5 Apr 2019 12:54:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 3XIsvYKCVlaj; Fri, 5 Apr 2019 12:54:40 -0700 (PDT)
Received: from mail-it1-f181.google.com (mail-it1-f181.google.com [209.85.166.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 217B31205FB; Fri, 5 Apr 2019 12:54:40 -0700 (PDT)
Received: by mail-it1-f181.google.com with SMTP id y204so11411473itf.3; Fri, 05 Apr 2019 12:54:40 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pPIVBrNiRhwH2X3X1fI01sCjoBCDlhsGfr4ubEQrRY4=; b=GMLg3dbbdHqCNeAjoDO6RvcR/WzHFlbxt0FaoZTkl/47ATj80HT638QPkTIFyuTcxW MaaGndti/QeuYZtY7Zmya8yanSeqEqj/tRA2r4zPxbZIS6dqub1v5gwYNi2iQkBKbMgi oRGzf+RF9oeTZBRG8r/nd87w2KgW0cJiAyUXbHfRavrN5lsDSkv1NVKiZlX81rW4IS9t 7bix+Z448bBMV/v1x588++iMBpwLlfbiU8zmgHiLWWMvJvT+zQwXMs6j5GJyZ6d9kk9l oHfokBWRecQIlgYjVysxf9AnfkjvkHlx7jS9d7mKqnEMf+W/S3FSQq30OksWEPiysI5X XErA==
X-Gm-Message-State: APjAAAUl0cApeHAqP1m9uZMDBzzVZCxdWkMlO8DCa1ypxadPzNsFuinS pd7fyROgOdKSLJcf4PYN01in7+4JaVuZxBCF3JQ=
X-Google-Smtp-Source: APXvYqwu+ihMQy7wHXsa+0NTuID0tgGP6XISL7UDJIail/9FBXWZYuPhO9RtPTyoBNi7eWeSwgvBRF6MmIC2DNcTLtM=
X-Received: by 2002:a02:1384:: with SMTP id 126mr11702495jaz.72.1554494079069; Fri, 05 Apr 2019 12:54:39 -0700 (PDT)
MIME-Version: 1.0
References: <155448515761.10017.3964878632140323988.idtracker@ietfa.amsl.com> <alpine.OSX.2.21.1904051336300.4382@ary.qy> <20190405180945.GF70202@kduck.mit.edu> <alpine.OSX.2.21.1904051437500.4382@ary.qy>
In-Reply-To: <alpine.OSX.2.21.1904051437500.4382@ary.qy>
From: Barry Leiba <barryleiba@computer.org>
Date: Fri, 5 Apr 2019 15:54:28 -0400
Message-ID: <CALaySJL6k_=kd2Z=LKwb7K+wFRpAQAJSkowW=9mVQ41Bvw0Kfg@mail.gmail.com>
To: John R Levine <johnl@taugh.com>
Cc: Benjamin Kaduk <kaduk@mit.edu>, dmarc@ietf.org, Kurt Andersen <kurta@drkurt.com>, The IESG <iesg@ietf.org>, dmarc-chairs@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/NWYvSwBUDuh-fANlD18xRqpQSVU>
Subject: Re: [dmarc-ietf] [taugh.com-standards] Benjamin Kaduk's Discuss on draft-ietf-dmarc-eaiauth-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: Fri, 05 Apr 2019 19:54:42 -0000

I had this discussion many times in my previous time as AD.  The
bottom line is that we can't explicitly specify everything, and need
to strike a reasonable balance between making things clear to *anyone*
and making things clear only to experts, or those who were around when
the document was written.  The balance is usually to aim the text to
someone reasonably well versed in the area we're talking about --
short of an expert, but farther along than a beginner.

Ben, I really do think the text you're talking about is fine, given
that balance.  One can't implement this without implementing the other
related technology first: SPF, DKIM, DMARC, SMTP....  If this text is
beyond one, one would never have gotten this far anyway, because one
would have been stumped by knottier questions one doesn't have the
background to deal with.

So, yeah, we can insist on tweaking that text to make a few things
more explicit, but it would not actually improve the document in a
meaningful way.

(One thing I'll pick at that I missed before, John:  The phrasing
"SHOULD do X but MAY do Y" doesn't really work: taken strictly, the
MAY weakens the SHOULD.  I would take the second key word out, and say
"SHOULD do X but Y is permitted <some brief explanation of what
circumstances>.")

Barry

On Fri, Apr 5, 2019 at 2:45 PM John R Levine <johnl@taugh.com> wrote:
>
> On Fri, 5 Apr 2019, Benjamin Kaduk wrote:
> > The whole premise of rigorous specifications is that anyone can jump in to
> > the ecosystem and implement something that interoperates, and in my opinion
> > the current presentation is not very accomodating to such a participant.
>
> We seem to have a fairly basic disagreement of who "anyone" would be.
> I'm assuming, and I think the WG is assuming, that the audience for this
> document is people who are already somewhat familiar with SPF or DKIM or
> DMARC.  It appears that you believe it is possible to add enough
> mechanical detail that even someone who knows nothing about them could
> make these changes.  That seems awfully optimistic.
>
> I don't fault you for not being an SPF or DKIM expert but I really don't
> think it is useful to add a lot of stuff that any plausible reader already
> knows.
>
> Regards,
> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
>