[apps-discuss] On "supporting the publication of this document" (was: Re: We have no lambs (was: Applicability Statements))

John C Klensin <john-ietf@jck.com> Thu, 12 May 2011 14:20 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC7EE0680 for <apps-discuss@ietfa.amsl.com>; Thu, 12 May 2011 07:20:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uL3dIb1+zxKo for <apps-discuss@ietfa.amsl.com>; Thu, 12 May 2011 07:20:29 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 78360E06A1 for <apps-discuss@ietf.org>; Thu, 12 May 2011 07:20:29 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QKWkD-0007lc-7X; Thu, 12 May 2011 10:20:01 -0400
Date: Thu, 12 May 2011 10:20:00 -0400
From: John C Klensin <john-ietf@jck.com>
To: SM <sm@resistor.net>, Pete Resnick <presnick@qualcomm.com>
Message-ID: <35CAD4FD66C1EDA5E82D49F8@PST.JCK.COM>
In-Reply-To: <6.2.5.6.2.20110511141027.032dd408@resistor.net>
References: <4DCAC1CB.3050905@qualcomm.com> <6.2.5.6.2.20110511115259.051cd3f8@resistor.net> <4DCAF61F.10000@qualcomm.com> <6.2.5.6.2.20110511141027.032dd408@resistor.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: Apps Discuss <apps-discuss@ietf.org>
Subject: [apps-discuss] On "supporting the publication of this document" (was: Re: We have no lambs (was: Applicability Statements))
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 May 2011 14:20:30 -0000

(I think these last few messages slipped into the wrong thread.
Restoring...)

--On Wednesday, May 11, 2011 14:39 -0700 SM <sm@resistor.net>
wrote:

>...
> At 13:37 11-05-2011, John C Klensin wrote:
>> So, I wouldn't have said "useless".  I might have said "of
>> very limited value in helping the IESG with its determination
>> of consensus about technical quality and adequacy of review".
> 
> That is the politically correct way of stating it.  It may
> help some people understand what the IESG would like.
> However, sentences like that are against IETF best practices.
> :-)

I think you may have missed my point, although the style I adopt
in the IETF rarely results in my being accused of saying things
to be politically correct.  :-)

The determination the IESG needs to make is multidimensional.
There is no agreed-upon statement of the dimensions, but I would
try the following as components.  They should require different
levels of certainty at different maturity levels, e.g., for
Proposed Standard, "no known technical defects" is supposed to
be adequate while, for higher levels, there should be some
conviction that no such defects exist, not merely that no one
has noticed.

(1) Is the document technically adequate?

(2) Is the document clear enough to be implemented in a
consistent and interoperable way?

(3) Are there interactions between the protocol specified in the
document that would have negative effects on the Internet or on
specific existing protocols?

(4) Do enough people in the community care about this spec that
the IETF should put its stamp of approval on it?

A "I think this is ok and should be published" statement may be
very useful for (4), especially for non-WG documents.   One
important characteristic of (4) is that the IESG actually does
have to count, even if the counting process doesn't correspond
to normal arithmetic.  For (1)-(3) high-information-content
technical arguments are important, especially if they take a
"don't publish" or "don't publish without..." position.  And, at
least in theory, there is no counting at all -- it doesn't make
any difference if a particular technical position is stated by
one person or by five (whether explicitly or by "+1"
endorsement): the issue should be the contents of that position.


Of course, it would reasonable for the IESG to take the position
that one reported problem is a bug that needs fixing but that
two dozen independent reported problems suggest that the spec
needs more fundamental work, but that ought to mean two dozen
comments of the type that I think Pete was asking for, not two
dozen endorsements of one such comment.

> Pete has taken a rather unusual approach.  I would qualify it
> as open.  It is to encourage discussion on an equal footing.

I think the only thing that is unusual about Pete's approach is
that he is trying to be explicit about the criteria he is going
to use to evaluate and weight comments.  I think that is A Good
Thing, but I don't think the criteria he suggests are in any way
new or unusual.

    john