Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

John C Klensin <john-ietf@jck.com> Thu, 29 August 2013 20:11 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4917E21F8EB2 for <ietf@ietfa.amsl.com>; Thu, 29 Aug 2013 13:11:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.546
X-Spam-Level:
X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bov-5ow2Pvl6 for <ietf@ietfa.amsl.com>; Thu, 29 Aug 2013 13:11:54 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6C18A11E8151 for <ietf@ietf.org>; Thu, 29 Aug 2013 13:11:54 -0700 (PDT)
Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1VF8ZN-000IDR-Uf; Thu, 29 Aug 2013 16:11:53 -0400
Date: Thu, 29 Aug 2013 16:11:48 -0400
From: John C Klensin <john-ietf@jck.com>
To: dcrocker@bbiw.net
Subject: Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
Message-ID: <4F19B9606B70F70C255C0DDB@JcK-HP8200.jck.com>
In-Reply-To: <521FA0F9.6000107@dcrocker.net>
References: <9884B9CD-0ED3-4D89-A100-58D05EA4BC98@gmail.com> <6.2.5.6.2.20130823234808.0b7cfed0@elandnews.com> <C5D75C5C-D468-4104-A478-0A055F43AED9@gmail.com> <6.2.5.6.2.20130826182352.0cac3298@elandnews.com> <330A924C-17DA-4082-92AD-FDB6EF09192A@hopcount.ca> <6.2.5.6.2.20130827090837.0d7b3e18@elandnews.com> <6.2.5.6.2.20130828044224.06ee3980@resistor.net> <521E0759.7090504@dcrocker.net> <33BAD063A63D81764705AC33@JcK-HP8200.jck.com> <521FA0F9.6000107@dcrocker.net>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Aug 2013 20:11:59 -0000

--On Thursday, August 29, 2013 12:28 -0700 Dave Crocker
<dhc@dcrocker.net> wrote:

> On 8/29/2013 9:31 AM, John C Klensin wrote:
>> I may be violating my promise to myself to stay out of
>> SPF-specific issues,
> 
> 
> Probably not, since your note has little to do with the
> realities of the SPFbis draft, which is a chartered working
> group product.  You might want to review its charter:
> 
>       http://datatracker.ietf.org/wg/spfbis/charter/
 
> Note the specified goal of standards track and the /very/
> severe constraints on work to be done.  Please remember that
> this is a charter that was approved by the IESG.  The working
> group produced was it was chartered to produce, for the
> purpose that was chartered.

I have reviewed the charter, Dave.  THe reasons I've wanted to
stay out of this discussion made me afraid to make a posting
without doing so.   But the last I checked, WG charters are
approved by the IESG after reviewing whatever comments they
decide to solicit.  They are not IETF Consensus documents.  Even
if this one was, the WG co-chair and document shepherd have made
it quite clear that the WG carefully considered the design issue
and alternatives at hand.  I applaud that but, unless you are
going to argue that the charter somehow allows the WG to
consider some issues that cannot be reviewed on IETF Last Call,
either the design issue is legitimate or the WG violated its
charter.  I, at least, can't read the charter that way.

> More broadly, you (and others) might want to review that
> actual criteria the IETF has specified for Proposed in
> RFC2026.  Most of us like to cite all manner of personal
> criteria we consider important.  Though appealing, none of
> them is assigned formal status by the IETF, with respect to
> the Proposed Standards label; I believe in fact that there is
> nothing that we can point to, for such other criteria,
> represents IETF consensus for them.  The claim that we can't
> really document our criteria mostly means that we think it's
> ok to be subjective and whimsical.

The statement to which I objected was one in which you claimed
(at least as I understood it) that it was inappropriate to raise
a design consideration because the protocol was already widely
deployed.  Your paragraph above makes an entirely different
argument.  As I understand it, your argument above is that it
_never_ appropriate to object during IETF Last Call on the basis
of design considerations (whether it is desirable to evaluate
design considerations in a WG or not).  I believe that design
issues and architectural considerations can sometimes be
legitimate examples of "known technical defects".  If they were
not, then I don't know why the community is willing to spend
time on such documents (or even on having an IAB).

Again, it think it is perfectly reasonable to argue that a
particular design or architectural consideration should not be
applied to a particular specification.  My problem arises only
when it is claimed that such considerations or discussions are a
priori inappropriate.
 
> Also for the broader topic, you also might want to reevaluate
> much of what your note does say, in light of the realities of
> Individual Submission (on the IETF track) which essentially
> never conforms to the criteria and concerns you seem to be
> asserting.

If that were the case, either you are massively misunderstanding
what I am asserting or I don't see your point.   I believe that
my prior note, and this one, assert only one thing, which is
that it is inappropriate to bar any discussion --especially
architectural or design considerations-- from IETF Last Call
unless it addresses a principle that has already been
established for the particular protocol by IETF Consensus.  I
remain completely comfortable, modulo the various "rude
language" topics, with a discussion of why some architectural
principle is irrelevant to a particular specification or even
that trying to apply that principle would be stupid.  But a
discussion along those lines is still a discussion, not an
attempt to prevent a discussion.

And, yes, I believe that Individual Submissions should generally
be subject to a much higher degree of scrutiny on IETF Last Call
than WG documents.  I also believe that, if there appears to be
no community consensus one way or the other, that the IESG
should generally defer to the WG on WG documents but default to
non-approval of Individual Submissions.  But, unless I'm
completely misunderstanding the point you are trying to make, I
don't see what that has to do with this topic.

Dave, we had these sorts of discussions before.  If there are a
common patterns about them, they are that neither of us is
likely to convince the other and that both of us soon get to the
point of either muttering "he just doesn't get it" (or worse)
into our beards or getting really short-tempered.  I suggest
that we not subject the community to that.  By all means respond
to this note if you feel a need to do (I'm not trying to get the
last word and, if I have misunderstood you, I'd like to be
better informed), but then I suggest that we leave the
discussion to others if they believe it to be of value.

best,
    john