Re: PS Characterization Clarified

Olaf Kolkman <olaf@NLnetLabs.nl> Wed, 18 September 2013 09:00 UTC

Return-Path: <olaf@NLnetLabs.nl>
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 308E011E80EC for <ietf@ietfa.amsl.com>; Wed, 18 Sep 2013 02:00:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 tKZgBfDdNkU2 for <ietf@ietfa.amsl.com>; Wed, 18 Sep 2013 02:00:11 -0700 (PDT)
Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD5211E81F0 for <ietf@ietf.org>; Wed, 18 Sep 2013 02:00:10 -0700 (PDT)
Received: from [IPv6:2001:7b8:206:1:7211:24ff:fe8c:627a] ([IPv6:2001:7b8:206:1:7211:24ff:fe8c:627a]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.7/8.14.4) with ESMTP id r8I8xsLj028751 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Sep 2013 10:59:55 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl)
Authentication-Results: open.nlnetlabs.nl; dmarc=none header.from=NLnetLabs.nl
DKIM-Filter: OpenDKIM Filter v2.8.3 open.nlnetlabs.nl r8I8xsLj028751
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1379494804; bh=3X3iaCzDDRdDXHxKTHqo3UVQJOo6IgnWWv1L4dsY474=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=rEN5Fp3oQRrv0Kdr7jwmiJBNGRjZdSADprFqg7PrtAB8DghxS3XtC/8KR14MSNrSw Lo29fuXZKYDutKWyo9M5H2TZwbdolf3hnfgsV2l2yfthut4lN9SzseLR5hi90qbyMz DBnX4Ok55S1js1yWpYuqJOKb0feTvyyTLnP5cPFo=
Content-Type: multipart/signed; boundary="Apple-Mail=_EF231F96-394F-42F0-A6D7-3CE144261ABB"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
Subject: Re: PS Characterization Clarified
From: Olaf Kolkman <olaf@NLnetLabs.nl>
In-Reply-To: <4B8D6DBC8CF8EB1BB76A3601@JcK-HP8200.jck.com>
Date: Wed, 18 Sep 2013 10:59:55 +0200
Message-Id: <C24A4EC4-CD9A-48AE-AAD4-F259E91F435D@NLnetLabs.nl>
References: <B8F661D1-1C45-4A4B-9EFE-C7E32A7654E7@NLnetLabs.nl> <FDF0E85C-83C1-4AC2-A6EA-FA0E2E3DD34C@NLnetLabs.nl> <5238DC29.6050409@qti.qualcomm.com> <4F37B49B-315C-4A63-BD80-E95F9A7969FE@sobco.com> <5238E174.4020109@qti.qualcomm.com> <4B8D6DBC8CF8EB1BB76A3601@JcK-HP8200.jck.com>
To: John C Klensin <john-ietf@jck.com>
X-Mailer: Apple Mail (2.1508)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Wed, 18 Sep 2013 11:00:01 +0200 (CEST)
Cc: Pete Resnick <presnick@qti.qualcomm.com>, IETF list <ietf@ietf.org>, "Scott O. Bradner" <sob@sobco.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: Wed, 18 Sep 2013 09:00:12 -0000

On 18 sep. 2013, at 01:54, John C Klensin <john-ietf@jck.com> wrote:

> Pete,
> 
> I generally agree with your changes and consider them important
> -- the IESG should be seen in our procedural documents as
> evaluating and reflecting the consensus of the IETF, not acting
> independently of it.
> 

Agreed….

> Of the various places in the document in which "IESG" now
> appears, only one of them should, IMO, even be controversial.
> It is tied up with what I think is going on in your exchange
> with Scott:
> 
> --On Tuesday, September 17, 2013 18:10 -0500 Pete Resnick
> <presnick@qti.qualcomm.com> wrote:
> 
>>>> Section 2:
>> ...
>>>> "the IESG strengthened its review"
>> ...
>>>> The IETF as a whole, through directorate reviews, area
>>>> reviews, doctor reviews, *and* IESG reviews, has evolved,
>>>> strengthened, ensured, etc., its reviews.
>>>> 
>>> I believe that change would be factually incorrect
>> 
>> Which part of the above do you think is factually incorrect?
> 
> The issue here --about which I mostly agree with Scott but still
> believe your fix is worth making-- is that the impetus for the
> increased and more intense review, including imposing a number
> of requirements that go well beyond those of 2026, did not
> originate in the community but entirely within the IESG.  It
> didn't necessarily originate with explicit decisions.  In many
> cases, it started with an AD taking the position that, unless
> certain changes were made or things explained to his (or
> occasionally her) satisfaction, the document would rot in the
> approval process.  Later IESG moves to enable overrides and
> clarify conditions for "discuss" positions can be seen as
> attempts to remedy those abuses but, by then, it was too late
> for Proposed Standard.  And, fwiw, those changes originated
> within the IESG and were not really subject to a community
> consensus process either.
> 
> However, because the document will be read externally, I prefer
> that it be "IETF" in all of the places you identify.  If we have
> to hold our noses and claim that the community authorized the
> IESG actions by failing to appeal or to recall the entire IESG,
> that would be true if unfortunate.  I would not like to see
> anything in this document that appears to authorize IESG actions
> or process changes in the future that are not clearly authorized
> by community consensus regardless of how we interpret what
> happened in the past.
> 



But one of the things that we should try to maintain in making that change is the notion that the IESG does  have a almost key-role in doing technical review. You made the point that that is an important distinction between 'us' and formal SDOs. 


Therefore I propose that that last occurrence reads:

> cross-area technical review performed by the IETF, exemplified by technical review by the full IESG at last stage of specification development.


I think that this language doesn't set precedence and doesn't prescribe how the review is done, only that the IESG does do review.


In full context:

    In fact, the IETF review is more extensive than that done in other
    SDOs owing to the cross-area technical review performed by the
    IETF,exemplified by technical review by the full IESG  at last stage of
    specification development. That position is further strengthened
    by the common presence of interoperable running code and
    implementation before publication as a Proposed Standard.


Does that work?

--Olaf