draft-farrell-ft-01.txt -- what signal are we attempting to sense?
Ted Hardie <ted.ietf@gmail.com> Wed, 05 December 2012 17:22 UTC
Return-Path: <ted.ietf@gmail.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 DF19721F8C05 for <ietf@ietfa.amsl.com>; Wed, 5 Dec 2012 09:22:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.352
X-Spam-Level:
X-Spam-Status: No, score=-3.352 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 B7qoDPKFJaM3 for <ietf@ietfa.amsl.com>; Wed, 5 Dec 2012 09:22:13 -0800 (PST)
Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9C34521F8A85 for <ietf@ietf.org>; Wed, 5 Dec 2012 09:22:13 -0800 (PST)
Received: by mail-qa0-f51.google.com with SMTP id i20so1933043qad.10 for <ietf@ietf.org>; Wed, 05 Dec 2012 09:22:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=v+51ECtvqANFOUzGJQPMtQpht1N+mZ9vevsABknURLk=; b=sPvY3jdZRjsr1sVhy8KrJoPFG0zOyLjhAULZyWM8nFDZ0qPUGBtdqzMVzAtbBT6dFp VUHWULcAIClt9fFY+79lSRBllmq7HUuNy0vz0186Q1CGkRxTTQQ3veQJe+WSJMj+O0Jy 5vWmXWAaHU4wN3zoR90CHf7vkqhtey0vfE6Gzqk7A8jnR/261kW8PY4QDrM13/hgorD0 oGw3LoCzrYwv2rS3Tv7uyBFbsY81QSjkXWaFgfTxBk91kOTuIXTUuM+az2EWa5D1rqiW O9FuPMR3OG0kCCiUb9C7sA0XCnlSkO6mcJrVYYWZku9PqGFa+PqgDe2wLAhfYXDGzkMc ibRA==
MIME-Version: 1.0
Received: by 10.229.196.96 with SMTP id ef32mr6896449qcb.101.1354728131030; Wed, 05 Dec 2012 09:22:11 -0800 (PST)
Received: by 10.49.121.100 with HTTP; Wed, 5 Dec 2012 09:22:10 -0800 (PST)
Date: Wed, 05 Dec 2012 09:22:10 -0800
Message-ID: <CA+9kkMAGqeOzFHeGmmK6TvGctwO-heVrW5xoBseZ528goXJyOA@mail.gmail.com>
Subject: draft-farrell-ft-01.txt -- what signal are we attempting to sense?
From: Ted Hardie <ted.ietf@gmail.com>
To: IETF <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="0016e6d375a3046dcc04d01e3944"
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, 05 Dec 2012 17:22:19 -0000
Reading through Stephen's draft and the discussion to date, I think there is some confusion/disagreement about what it is having an implementation at this stage signals. One way to break up the work of the IETF is: Engineering--making decisions about the trade-offs related to different approaches to solving a problem. Specification--producing text that describes how to inter-operate with others. Standardization--describing the applicability of a specification or its suitability as the basis of other work (Since we reflect all of these in the same document production, it's really muddier than this, but bear with me) My experience is that people implementing during the working group discussion phase generate really useful data about the engineering; they can tell you the real impact of different trade-offs, so that this isn't based on general experience. But it's not such a great signal about the specification itself, since the spec is designed to be usable by folks who were not part of the working group process. Stephen's draft says: Note also that this experiment just needs an implementation that makes it possible for the WG chairs and responsible AD to verify (to the extent they chose) that the implementation matches the draft. and later: An implementation of the draft (ideally open-source) is required for fast-track last-call. If there is no implementation or if the implementation is unavailable or does not implement the draft sufficiently closely then the document needs to be returned to the WG. This only requires one implementation, not two and the WG chairs and responsible AD decide themselves how much validation is required for this. Given the "sufficiently closely" and the timing of production, I assume that the signal we're looking for here is confirmation of the engineering choices. I think that's fine (though I'm not sure this needs formal experiment status). But I believe we need to be really careful that it isn't mistaken for signal about the specification's quality. It can happen that a working group has "lore" about what to do that gets folded into the implementations done by those participating, but which never quite makes it into the spec "because everyone knows it". An implementation written during the working group process is potentially subject to this effect. An interoperating implementation written to the spec by a non-working group participant would be great signal about the specification quality, but it is not likely to be available at the stage of the process this draft targets. Again, not objecting to the experiment; I just want to be clear about what signal we believe we're getting from the implementation. Just my two cents, Ted
- draft-farrell-ft-01.txt -- what signal are we att… Ted Hardie
- Re: draft-farrell-ft-01.txt -- what signal are we… Stephen Farrell
- Re: draft-farrell-ft-01.txt -- what signal are we… Ted Hardie
- Re: draft-farrell-ft-01.txt -- what signal are we… Stephen Farrell