Re: Blue Sheet Change Proposal

Dave Crocker <dhc2@dcrocker.net> Fri, 04 April 2008 16:14 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19F163A6CEB; Fri, 4 Apr 2008 09:14:12 -0700 (PDT)
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 178793A6C4C for <ietf@core3.amsl.com>; Fri, 4 Apr 2008 09:14:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.923
X-Spam-Level:
X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[AWL=0.676, 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 GAmRxA4NBkP8 for <ietf@core3.amsl.com>; Fri, 4 Apr 2008 09:14:02 -0700 (PDT)
Received: from sbh17.songbird.com (unknown [IPv6:2001:470:1:76:0:ffff:4834:7146]) by core3.amsl.com (Postfix) with ESMTP id E3CF53A6B0F for <ietf@ietf.org>; Fri, 4 Apr 2008 09:14:01 -0700 (PDT)
Received: from [192.168.0.4] (adsl-67-127-190-96.dsl.pltn13.pacbell.net [67.127.190.96]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id m34GDwEH006060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf@ietf.org>; Fri, 4 Apr 2008 09:14:06 -0700
Message-ID: <47F653C6.5060700@dcrocker.net>
Date: Fri, 04 Apr 2008 09:13:58 -0700
From: Dave Crocker <dhc2@dcrocker.net>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: IETF Discussion <ietf@ietf.org>
Subject: Re: Blue Sheet Change Proposal
References: <47F56545.4020603@isoc.org> <C652E6EF-0E8E-4770-BE30-251A3562C412@NLnetLabs.nl> <E7CB49418CF43269B3D9FD5D@Uranus.local> <47F64DD5.6000003@att.com>
In-Reply-To: <47F64DD5.6000003@att.com>
X-Virus-Scanned: ClamAV 0.92/6586/Fri Apr 4 07:26:59 2008 on sbh17.songbird.com
X-Virus-Status: Clean
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 04 Apr 2008 09:14:06 -0700 (PDT)
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-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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


Tony Hansen wrote:
> I like Olaf's suggestion of adding a level of indirection.


While yes, it's an appealing suggestion, it is probably not as useful as it sounds.

1. A layer of indirection for a human mechanism is another opportunity for human 
error.  A new, unfamiliar string is more likely not to be recorded properly.  If 
we really want to be able to use the identification information, this will make 
it less likely, not more.

2. Folks can find anything to be afraid of.  If there is a valid concern -- and 
skimming published versions of the lists does seem like a valid concern -- then 
we should make sure the system is designed properly, to protect against real 
threats of information misuse.

The goal of an indirect identifier is to ensure that the address is retained in 
a safe place and not circulated.  We can accomplish that just as well by not 
circulating the sign-up sheets, and instead making them available only for 
specific, authorized uses.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf