Re: Call for review of proposed IESG Statement on Examples

[Iljitsch van Beijnum <iljitsch at muada.com>]

On 18 sep 2008, at 19:07, The IESG wrote:

> The document SHOULD use values reserved for examples where such
> assignments exist (e.g. BCP 32, RFC 3330, RFC 4735, and RFC 5156)  
> and when
> the necessary semantic can be communicated clearly enough. If  
> unassigned
> codepoints are desired it is RECOMMENDED that those codepoints be  
> assigned
> or registered.  If assigned codepoints are desired, it is  
> RECOMMENDED that
> the authors get approval from the current codepoint holder.

First of all: note that this issue goes well beyond the traditional  
reach of the IESG. For instance, I've written books and taught  
training courses where obviously examples had to be used.

For domain names I used example.com et al, operating under the idea  
that anyone who registers such a domain can't complain that it's used  
in examples.

However, IP addresses are often a concern. IPv4 only has 192.0.2.0/24  
which is completely insufficient for decent examples. IPv6 has  
2001:db8::/32 which is big, but still not useful in all cases because  
it's often necessary to clearly show that two address ranges are  
different so they must be different prefixes. A common solution is to  
use RFC 1918 addresses for examples but I don't like it in general and  
it's not really workable in certain cases because these addresses  
carry a special meaning. (I.e., an RFC 1918 address in a 6to4 example  
would create the impression that this is a workable combination which  
isn't the case.)

So I suggest reserving three or so additional IPv4 and IPv6 global  
unicast prefixes for documentFrom ietf-bounces at ietf.org  Tue Sep 23 07:01:04 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 67B1A28C207;
	Tue, 23 Sep 2008 07:01:04 -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 527F328C207;
	Tue, 23 Sep 2008 07:01:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
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 3oBMZv4hk38p; Tue, 23 Sep 2008 07:01:02 -0700 (PDT)
Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2])
	by core3.amsl.com (Postfix) with ESMTP id D85223A6C96;
	Tue, 23 Sep 2008 07:01:01 -0700 (PDT)
Received: from [IPv6:2001:720:410:1001:21b:63ff:fe92:9fbb]
	([IPv6:2001:720:410:1001:21b:63ff:fe92:9fbb]) (authenticated bits=0)
	by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m8JCxFo8074944
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Fri, 19 Sep 2008 14:59:16 +0200 (CEST)
	(envelope-from iljitsch at muada.com)
Message-Id: <037A28FB-A9A5-43F8-AC51-54AC29396CE6 at muada.com>
From: Iljitsch van Beijnum <iljitsch at muada.com>
To: ietf at ietf.org
In-Reply-To: <20080918170712.83D173A6A7F at core3.amsl.com>
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: Call for review of proposed IESG Statement on Examples 
Date: Fri, 19 Sep 2008 14:59:32 +0200
References: <20080918170712.83D173A6A7F at core3.amsl.com>
X-Mailer: Apple Mail (2.929.2)
Cc: IETF Announcement list <ietf-announce 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: ietf-bounces at ietf.org
Errors-To: ietf-bounces at ietf.org

On 18 sep 2008, at 19:07, The IESG wrote:

> The document SHOULD use values reserved for examples where such
> assignments exist (e.g. BCP 32, RFC 3330, RFC 4735, and RFC 5156)  
> and when
> the necessary semantic can be communicated clearly enough. If  
> unassigned
> codepoints are desired it is RECOMMENDED that those codepoints be  
> assigned
> or registered.  If assigned codepoints are desired, it is  
> RECOMMENDED that
> the authors get approval from the current codepoint holder.

First of all: note that this issue goes well beyond the traditional  
reach of the IESG. For instance, I've written books and taught  
training courses where obviously examples had to be used.

For domain names I used example.com et al, operating under the idea  
that anyone who registers such a domain can't complain that it's used  
in examples.

However, IP addresses are often a concern. IPv4 only has 192.0.2.0/24  
which is completely insufficient for decent examples. IPv6 has  
2001:db8::/32 which is big, but still not useful in all cases because  
it's often necessary to clearly show that two address ranges are  
different so they must be different prefixes. A common solution is to  
use RFC 1918 addresses for examples but I don't like it in general and  
it's not really workable in certain cases because these addresses  
carry a special meaning. (I.e., an RFC 1918 address in a 6to4 example  
would create the impression that this is a workable combination which  
isn't the case.)

So I suggest reserving three or so additional IPv4 and IPv6 global  
unicast prefixes for documentation purposes, that look sufficiently  
different from each other.

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


ation purposes, that look sufficiently  
different from each other.

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