Re: Observations on (non-technical) changes affecting IETF operations

Melinda Shore <> Sun, 27 March 2016 18:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A979912D508 for <>; Sun, 27 Mar 2016 11:25:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yPzPrt4C_cr7 for <>; Sun, 27 Mar 2016 11:25:02 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 87FF712D0C3 for <>; Sun, 27 Mar 2016 11:25:01 -0700 (PDT)
Received: by with SMTP id x3so120243461pfb.1 for <>; Sun, 27 Mar 2016 11:25:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=MmvB1vPmcUI7PHn+M+Rf2ZpVy5MGWPZ9j2VxkJcy4gE=; b=UoHYPK+hcz2AETx/R912ldFNwRfHkq6EktUZnFJl86IyIyAdqWK/B0+ht+tk1+8woO yfTfNDiZkP7Rl8XgFl5mkJDk8+j2ublAVEFmPrevCOpNEwqmIAKaBzWcFHjtNdHA/X8G huug4OezKBbkHiNkk6n/gsDrtW2MUPEUDF+qh7s7lbodzOzICK5AqXldCqce/xvotWrR VsweJpH74VmEESvEKBZ7SSENkUUOB3JJxCG+rQcNyFVllVLqMb/cqPtu37efXwIRgWpy vPmUC3Bwh3ubhe4iSU0yyLbaXLnPL3lcMsQ/01tY2we3xDuPUpY8Bn8UfEkMY47SbCNi 10FA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=MmvB1vPmcUI7PHn+M+Rf2ZpVy5MGWPZ9j2VxkJcy4gE=; b=UvxzDCklCTbmZzFVDHhDm0K25BgG0kQFlAVRApk6AzQihAEYAx/4VLixRpzn7TR0cH KhgGreAC2M46Z0AoftkzOa9KPDY/qnOjpGxYL6Btswmb6OFwooigBOcHYbvRTOdXCC/B d6PaoRL01x7Q2a6494D+8jrggpqsEWDKa5GpaPkVnzndDqPOWfpeI1N9leU7Cgk0Mcg+ SgqFsHhOjMqBIvv/QjrSqo5rd6Exg7uZgTUXgZRl2v2Ll7M/eor4BbHZ/QGhCVT99COY 36wqcHuuuI+/BmBCturoG4yzSdBUXoe2hHncynlZnaqukxLJoPYn/gQoyEG+tTTZrx8Y 7EFw==
X-Gm-Message-State: AD7BkJJeQho4gxpMD+ZQbtoDPhwNSHQ+p7ouz8pwYUQOxoDw9wC2KU2fA8vPexy4PcAd/A==
X-Received: by with SMTP id g72mr37214135pfd.138.1459103101080; Sun, 27 Mar 2016 11:25:01 -0700 (PDT)
Received: from Melindas-MacBook-Pro.local ( []) by with ESMTPSA id y7sm29935667pfa.82.2016. (version=TLSv1/SSLv3 cipher=OTHER); Sun, 27 Mar 2016 11:25:00 -0700 (PDT)
Subject: Re: Observations on (non-technical) changes affecting IETF operations
To: Russ White <>,,
References: <> <4A95BA014132FF49AE685FAB4B9F17F657DF2330@dfweml701-chm> <> <> <> <> <038a01d1881c$747a50d0$5d6ef270$>
From: Melinda Shore <>
Message-ID: <>
Date: Sun, 27 Mar 2016 10:27:34 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <038a01d1881c$747a50d0$5d6ef270$>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 27 Mar 2016 18:25:03 -0000

On 3/27/16 3:33 AM, Russ White wrote:
> We've lost the art of base spec -- leave other stuff to later. Maybe I'm
> just being nostalgic, but I seem to remember a time when we would pass
> through a base protocol with extensibility, and then start talking about
> extensions on a case by case basis. Now we seem to see 15-20 drafts proposed
> in a few months, all with interlocking bits and pieces, totaling hundreds of
> pages of text, and sounding more like a bill being presented before some
> legislative body rather than a technical specification.

Yes, this is definitely a problem.  Sometimes it's
necessary to grind out metadocuments, when participants
refuse to come to agreement.  But more often this seems
related to a bigger problem, which is that we've got a
bunch of participants who are being given incentives to
publish documents rather than to produce technology.

Someone once told me that he'd implemented an important
piece of IETF technology and that while there were five
or six documents in the core set, he really only needed
two of them to produce a full implementation.

We're running into this issue (completeness before core spec
publication) in a working group I chair and we really don't
have mechanisms to push on past someone really determined
to do this.  In fairness, it's produced a better core
specification, but in honesty it hasn't produced a core
specification that's sufficiently better to justify the
consequent delay (over a year, I'd guess).

As with so many things this can be a chairing issue -
maybe we need to come up with a clearer shared understanding
of what "ready" is, and make sure the IESG shares it as well.
And, be prepared to deal with appeals from participants who
are bound and determined to make perfection be the enemy of
the good enough.