Re: Call for review of proposed IESG Statement on Examples

[John C Klensin <john-ietf at jck.com>]

--On Monday, 22 September, 2008 11:40 +0200 Magnus Westerlund
<magnus.westerlund at ericsson.com> wrote:

> Hi John,
> 
> I have tried to write a statement that allows the IESG to use
> common sense. However, the problem I have seen several times
> when the IESG tries to use common sense in issues that comes
> up regularly is that some people complains about not knowing
> about this and that we can't enforce it because there are no
> written rules. 

Magnus, Spencer's note does a fairly good job of summarizing
most of my concerns.  Let me address a few things that he does
not, but please read his note along with this one.

First of all, I see a huge difference among three categories
that your note, and the draft statement, seem to roll together:

	(i) The class of things that the IPR WG might think of
	as "code", here including MIBs, configuration files,
	tables, and code excerpts that implementers are expected
	to copy, either verbatim or with simple, template-like,
	modifications.
	
	(ii) Test scripts and similar things, written in a form
	in which they will obviously be copied, perhaps modified
	slightly, and then executed repeatedly (with fairly high
	multiples of "repeatedly").
	
	(iii) Simple, illustrative examples that, even if
	executed, are not likely to be executed more than once
	by a given implementer.

One might draw the boundaries in other ways, but they are
different enough that saying "the cases in the first group are
harmful, therefore the cases in the third are harmful enough to
require extensive rules" is just bogus.

> Thus the draft statemenFrom ietf-bounces at ietf.org  Mon Sep 22 04:43:36 2008
Return-Path: <ietf-bounces at ietf.org>
X-Original-To: ietf-archive at megatron.ietf.org
Delivered-To: ietfarch-ietf-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 64D4F3A69B8;
	Mon, 22 Sep 2008 04:43:36 -0700 (PDT)
X-Original-To: ietf at core3.amsl.com
Delivered-To: ietf at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 5AB5B3A6912
	for <ietf at core3.amsl.com>; Mon, 22 Sep 2008 04:43: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 bSlx9y-Lzxk8 for <ietf at core3.amsl.com>;
	Mon, 22 Sep 2008 04:43:34 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211])
	by core3.amsl.com (Postfix) with ESMTP id DD5E23A69CC
	for <ietf at ietf.org>; Mon, 22 Sep 2008 04:43:33 -0700 (PDT)
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1Khjp0-0003YH-E8; Mon, 22 Sep 2008 07:43:18 -0400
Date: Mon, 22 Sep 2008 07:43:17 -0400
From: John C Klensin <john-ietf at jck.com>
To: Magnus Westerlund <magnus.westerlund at ericsson.com>
Subject: Re: Call for review of proposed IESG Statement on
 Examples
Message-ID: <6435DCB48AF6B861E2C01AD2 at p3.int.jck.com>
In-Reply-To: <48D76806.8080003 at ericsson.com>
References: <20080918170712.83D173A6A7F at core3.amsl.com>
	<90DF2902DD415710EEFF5699 at p3.int.jck.com>
	<1696498986EFEC4D9153717DA325CB7201A873B7 at vaebe104.NOE.Nokia.com>
	<AE10A2DFF6DACD6BDF76EFA9 at p3.int.jck.com>
	<48D76806.8080003 at ericsson.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Pasi.Eronen at nokia.com, ietf at ietf.org
X-BeenThere: ietf at 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 at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces at ietf.org
Errors-To: ietf-bounces at ietf.org



--On Monday, 22 September, 2008 11:40 +0200 Magnus Westerlund
<magnus.westerlund at ericsson.com> wrote:

> Hi John,
> 
> I have tried to write a statement that allows the IESG to use
> common sense. However, the problem I have seen several times
> when the IESG tries to use common sense in issues that comes
> up regularly is that some people complains about not knowing
> about this and that we can't enforce it because there are no
> written rules. 

Magnus, Spencer's note does a fairly good job of summarizing
most of my concerns.  Let me address a few things that he does
not, but please read his note along with this one.

First of all, I see a huge difference among three categories
that your note, and the draft statement, seem to roll together:

	(i) The class of things that the IPR WG might think of
	as "code", here including MIBs, configuration files,
	tables, and code excerpts that implementers are expected
	to copy, either verbatim or with simple, template-like,
	modifications.
	
	(ii) Test scripts and similar things, written in a form
	in which they will obviously be copied, perhaps modified
	slightly, and then executed repeatedly (with fairly high
	multiples of "repeatedly").
	
	(iii) Simple, illustrative examples that, even if
	executed, are not likely to be executed more than once
	by a given implementer.

One might draw the boundaries in other ways, but they are
different enough that saying "the cases in the first group are
harmful, therefore the cases in the third are harmful enough to
require extensive rules" is just bogus.

> Thus the draft statement is an t is an attempt to
> satisfy several different requirements:
> 
> - Provide motivation why there are issues with examples
> - Provide some guidance on how to handle situations which
> aren't clear cut
> - Be clear that this is something IESG do look at and authors
> need to think about.
> - Prevent complaints about late surprise and heavy hands when
> we are applying what we think are common sense.

One can make extensive rules or one can apply common sense.  The
pushback when this came up was because of a perception that
common sense was _not_ being applied.   This document does not
somehow instantiate common sense, what it does it to transform
the rigid rule that was undocumented into the rigid rule that
is.  And, while "undocumented" makes things much worse, the real
objection is to the rigid rule, especially against the backdrop
of a concern that it will take far too much time and energy to
get such a rule right and that there will _still_ be exception
cases.

In general, any time you write a page of rules and case analysis
when a sentence of guidance would do, I (and perhaps others) are
going to object.  Keeping things simple is of significant and
substantive importance.

> If you have a suggestion on how this better can be written up
> I am interested.

Yes.  I've made that suggestion several times.  It was actually
in my previous note (see Pasi's comment).  Don't try to
delineate every case and build a rule on that basis.  Just
indicate that you expect safe/protected/reserved names (or
codepoints or other identifiers), to be used, especially when
they occur in situations in which copying and repeated execution
are likely and that, if the author believes otherwise, that must
be explained in a comment (in the document or wherever else you
would like it) that is clear enough that the community can
comment on the justification during Last Call.  If you want to
say something about the difference between new and revised
documents, I would, based on recent experience, appreciate it,
but I don't think even that is necessary.

> When it comes to harm, I think we clearly have some cases
> where examples can have really serious effects, configurations
> being what comes to mind. When it comes to email addresses
> they are primarily an annoyance, but I think any one of us
> would be might irritated to learn that the suddenly started
> receive spam in large quantities because someone published
> their address in example in an internet draft or RFC. I think
> that this is as far as this goes and something any contributor
> to the IETF unfortunately have to pay for their contribution
> in an open organization with open access to its documents.

See Spencer's note about spam and the comment above about
conflating "configurations" with "email addresses in a purely
illustrative example".

regards,
   john

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf


attempt to
> satisfy several different requirements:
> 
> - Provide motivation why there are issues with examples
> - Provide some guidance on how to handle situations which
> aren't clear cut
> - Be clear that this is something IESG do look at and authors
> need to think about.
> - Prevent complaints about late surprise and heavy hands when
> we are applying what we think are common sense.

One can make extensive rules or one can apply common sense.  The
pushback when this came up was because of a perception that
common sense was _not_ being applied.   This document does not
somehow instantiate common sense, what it does it to transform
the rigid rule that was undocumented into the rigid rule that
is.  And, while "undocumented" makes things much worse, the real
objection is to the rigid rule, especially against the backdrop
of a concern that it will take far too much time and energy to
get such a rule right and that there will _still_ be exception
cases.

In general, any time you write a page of rules and case analysis
when a sentence of guidance would do, I (and perhaps others) are
going to object.  Keeping things simple is of significant and
substantive importance.

> If you have a suggestion on how this better can be written up
> I am interested.

Yes.  I've made that suggestion several times.  It was actually
in my previous note (see Pasi's comment).  Don't try to
delineate every case and build a rule on that basis.  Just
indicate that you expect safe/protected/reserved names (or
codepoints or other identifiers), to be used, especially when
they occur in situations in which copying and repeated execution
are likely and that, if the author believes otherwise, that must
be explained in a comment (in the document or wherever else you
would like it) that is clear enough that the community can
comment on the justification during Last Call.  If you want to
say something about the difference between new and revised
documents, I would, based on recent experience, appreciate it,
but I don't think even that is necessary.

> When it comes to harm, I think we clearly have some cases
> where examples can have really serious effects, configurations
> being what comes to mind. When it comes to email addresses
> they are primarily an annoyance, but I think any one of us
> would be might irritated to learn that the suddenly started
> receive spam in large quantities because someone published
> their address in example in an internet draft or RFC. I think
> that this is as far as this goes and something any contributor
> to the IETF unfortunately have to pay for their contribution
> in an open organization with open access to its documents.

See Spencer's note about spam and the comment above about
conflating "configurations" with "email addresses in a purely
illustrative example".

regards,
   john

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf