Re: Proposed Revisions to the IETF Trust Legal Provisions (TLP)

Robert Elz <kre@munnari.OZ.AU> Wed, 24 June 2009 02:25 UTC

Return-Path: <kre@munnari.OZ.AU>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AC1D3A68F2; Tue, 23 Jun 2009 19:25:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4hoEb5O11LH; Tue, 23 Jun 2009 19:25:34 -0700 (PDT)
Received: from jade.coe.psu.ac.th (unknown [IPv6:2001:3c8:9009:181::2]) by core3.amsl.com (Postfix) with ESMTP id A50553A6F07; Tue, 23 Jun 2009 19:25:32 -0700 (PDT)
Received: from epsilon.noi.kre.to (jade.coe.psu.ac.th [202.28.99.196]) by jade.coe.psu.ac.th with ESMTP id n5O2PbBt022161; Wed, 24 Jun 2009 09:25:38 +0700 (ICT)
Received: from epsilon.noi.kre.to (localhost [127.0.0.1]) by epsilon.noi.kre.to (8.14.2/8.14.2) with ESMTP id n5O2NZWS002825; Wed, 24 Jun 2009 09:23:35 +0700 (ICT)
From: Robert Elz <kre@munnari.OZ.AU>
To: Marshall Eubanks <tme@americafree.tv>
Subject: Re: Proposed Revisions to the IETF Trust Legal Provisions (TLP)
In-Reply-To: <B7008260-2BA6-4529-B4F6-1D0D3D9E7AEA@americafree.tv>
References: <B7008260-2BA6-4529-B4F6-1D0D3D9E7AEA@americafree.tv>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 24 Jun 2009 09:23:34 +0700
Message-ID: <3382.1245810214@epsilon.noi.kre.to>
Sender: kre@munnari.OZ.AU
Cc: Trustees <trustees@ietf.org>, IAB IAB <iab@iab.org>, ietf list <ietf@ietf.org>, IESG <iesg@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 24 Jun 2009 02:25:35 -0000

In other organisations, when I see (what has been called here), an
"over the wall" list of changes, I usually expect, and usually receive,
in addition to the list of changes (along with what used to be there)
all of which exists here, some kind of explanation why the changes are
being proposed.  That is, the motivation for the change.

For some of the changes here, I can guess what's up, and some of those
guesses might even be right - in others I have no idea at all what would
be motivating the proposed change.

One such is ...

  | 2.e -- the review period for TLP changes has been changed from 30 to 14
  | days, which is consistent with the last-call period for other IETF
  | documents 

which I can't even begin to guess at a rationale for.   What kind of
change in this area is ever going to be so urgent that even a 30 day
waiting period is a problem?   If a change were going to be made here,
I'd be expecting it to be in the other direction, extending the period
for comments, rather than reducing it.

If the only reason for this change is some desire to be consistent with
the rest of the IETF last call timeline, then that's misguided in the
extreme - first because there is no one last call period (there are
several, for different kinds of documents, and circumstances) and second,
because the 14 day LC period for IETF WG docs is set to match the IESG
meeting timetable, it allows the IESG to approve a last call on a doc at
one meeting, after which in the days that follow, the LC announcement is
actually issued.  Two weeks after that, the responsible AD can summarise
the LC results, and have the results available for the IESG at its next
meeting (that being 2 meetings after the LC approval was made).   There's
a reason for that particular period for most docs - it allows things to
move along without undue delay (after they've often been debated for a
year or more already.)

In general, I'm tempted to summarily reject any request for any change
(even fixing a simple spelling mistake) until I've seen an explicit
explanation for why the change is needed - that way I can evaluate whether
the proposal actually meets the stated objective, whether the objective
might perhaps be realised better via a different change, and even whether
the objective is desirable in the first place.

When all that is provided is "here is this list of changes" I have the
opportunity for none of that, so I can't possibly tell whether they're
reasonable or not, nor whether they are effective or not.

For now, make no changes at all.

kre