Re: PS Characterization Clarified

John C Klensin <john-ietf@jck.com> Tue, 17 September 2013 12:37 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 2F13011E842A for <ietf@ietfa.amsl.com>; Tue, 17 Sep 2013 05:37:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.528
X-Spam-Level:
X-Spam-Status: No, score=-103.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 Zybpzf3+KXPw for <ietf@ietfa.amsl.com>; Tue, 17 Sep 2013 05:36:57 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0923821F9CBF for <ietf@ietf.org>; Tue, 17 Sep 2013 05:36:48 -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 1VLuWJ-000AVs-5K; Tue, 17 Sep 2013 08:36:43 -0400
Date: Tue, 17 Sep 2013 08:36:38 -0400
From: John C Klensin <john-ietf@jck.com>
To: Dave Cridland <dave@cridland.net>, Olaf Kolkman <olaf@nlnetlabs.nl>
Subject: Re: PS Characterization Clarified
Message-ID: <6C96C79FC4110105AA046B55@JcK-HP8200.jck.com>
In-Reply-To: <CAKHUCzwHk4xR0fZ_EgBPFmtRUEP_QbS2X+Uk3=ibnX2dk59Ajg@mail.gmail.com>
References: <B8F661D1-1C45-4A4B-9EFE-C7E32A7654E7@NLnetLabs.nl> <9B5010D3-EA47-49AD-B9D0-08148B7428FC@piuha.net> <CAC4RtVDXVqZkCi1stmuoxawUVDi6+uG-bXWp36CM6-bsqNjiew@mail.gmail.com> <EC75AB54-8B11-42B9-8049-F70D09DB1775@NLnetLabs.nl> <CAC4RtVDj3tBChrJBiBiD6uwOtGRJHLDYeh62XbERrHp0i1Fmfg@mail.gmail.com> <522761EB.2000002@gmail.com> <13BBB594-4510-4903-917B-67D39F60E2BD@NLnetLabs.nl> <A87B7462DC459B3D64373984@JcK-HP8200.jck.com> <6A29D567-0C5A-4CB4-ABDF-450D52D2C642@NLnetLabs.nl> <CALaySJK5f+ozCMUnVRXHDq9Vdx699LJXKGvkR40BxkgYCv9KwA@mail.gmail.com> <75F53956E64249D2F2321E5E@JcK-HP8200.jck.com> <394950A2-1F83-4D0B-9B26-B4A064B65031@NLnetLabs.nl> <CAKHUCzwHk4xR0fZ_EgBPFmtRUEP_QbS2X+Uk3=ibnX2dk59Ajg@mail.gmail.com>
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: Barry Leiba <barryleiba@computer.org>, IETF list <ietf@ietf.org>, Scott O Bradner <sob@sobco.com>, SM Moonesamy <sm+ietf@elandsys.com>
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: Tue, 17 Sep 2013 12:37:03 -0000

--On Tuesday, September 17, 2013 11:32 +0100 Dave Cridland
<dave@cridland.net> wrote:

> I read John's message as being against the use of the phrase
> "in exceptional cases". I would also like to avoid that; it
> suggests that some exceptional argument may have to be made,
> and has the implication that it essentially operates outside
> the process.

Exactly.

> I would prefer the less formidable-sounding "on occasion",
> which still implies relative rarity.

And "on occasion" is at least as good or better than my
suggestions of "usually", "commonly", or "normally" although I
think any of the four would be satisfactory.


--On Tuesday, September 17, 2013 07:06 -0400 Scott Brim
<scott.brim@gmail.com> wrote:

>...
> Exceptions and arguments for and against are part of the
> process. Having a process with no consideration for exceptions
> would be exceptional.

Scott, it an IETF technical context, I'd completely agree,
although some words like "consideration for edge cases" would be
much more precise if that is actually what you are alluding to.
But part of the intent of this revision to 2026 is to make what
we are doing more clear to outsiders who are making a good-faith
effort to understand us and our standards.  In that context,
what you say above, when combined with Olaf's text, is likely to
be read as:

	"We regularly, and as a matter of course, consider
	waiving our requirements for Proposed Standard entirely
	and adopt specifications using entirely different (and
	undocumented) criteria."  

That is misleading at best.  In the interest of clarity, I don't
think we should open the door that sort of interpretation if we
can avoid it.

I don't think it belongs in this document (it is adequately
covered by Olaf's new text about other sections), but it is
worth remembering that we do have a procedure for making
precisely the type of exceptions my interpretation above
implies: the Variance Procedure of Section 9.1 of 2026.   I
cannot remember that provision being invoked since 2026 was
published -- it really is "exceptional" in that sense.  Its
existence may be another reason for removing "exceptional" from
the proposed new text because it could be read as implying that
we have to use the Section 9.1 procedure for precisely the cases
of a well-documented, but slightly incomplete, that most of us
consider normal.  In particular, it would make the approval of
the specs that Barry cited in his examples invalid without
invoking the rather complex procedure of Section 9.1.  I'd
certainly not like to have text in this update that encourages
that interpretation and the corresponding appeals -- it would
create a different path to the restriction Barry is concerned
about.

    john