Re: Admission Control to the IETF 78 and IETF 79 Networks

Russ Housley <housley@vigilsec.com> Fri, 02 July 2010 01:41 UTC

Return-Path: <housley@vigilsec.com>
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 268503A6859 for <ietf@core3.amsl.com>; Thu, 1 Jul 2010 18:41:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.445
X-Spam-Level:
X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 NnVi1Fpf1U1W for <ietf@core3.amsl.com>; Thu, 1 Jul 2010 18:41:07 -0700 (PDT)
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id 1C91E3A6805 for <ietf@ietf.org>; Thu, 1 Jul 2010 18:41:07 -0700 (PDT)
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id BFCE69A473C for <ietf@ietf.org>; Thu, 1 Jul 2010 21:41:29 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id sj6mucpC3nJU for <ietf@ietf.org>; Thu, 1 Jul 2010 21:41:14 -0400 (EDT)
Received: from [192.168.2.108] (pool-96-241-163-123.washdc.fios.verizon.net [96.241.163.123]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 0855C9A4724 for <ietf@ietf.org>; Thu, 1 Jul 2010 21:41:29 -0400 (EDT)
Message-ID: <4C2D43BF.6020902@vigilsec.com>
Date: Thu, 01 Jul 2010 21:41:19 -0400
From: Russ Housley <housley@vigilsec.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5
MIME-Version: 1.0
To: IETF <ietf@ietf.org>
Subject: Re: Admission Control to the IETF 78 and IETF 79 Networks
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
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: Fri, 02 Jul 2010 01:41:08 -0000

Mike:

> Going back to the IAOC, I would ask whether this requirement
> was known at the time of the previous Beijing discussion?  If so,
> why wasn't it brought up at that point in time and as part of the
> discussion on venue acceptability.  If it was added later, when
> was it added, and why wasn't the requirement made known to the
> broader IETF prior to announcing the solution? Finally, I know
> this is a hypothetical, but would this requirement have tipped
> the IAOC decision the other way had it been known at the same
> time of the previous discussion?
>
> I don't mean to pick on either you or the IAOC - you both are doing
> a reasonable job steering among the shoals of the needs of the
> various constituencies - just consider this an inquiry into how the
> IETF should decide on how to decide whether a venue is acceptable.

In short, no, this was not known at the time the previous discussion
took place.  I could have raised this sooner, but I chose to wait until
a proposed solution was in hand so that everyone could understand the
impact.  Raising it earlier would have prompted questions that could not
be answered without a strawman for the solution.

In my view, the host is working diligently to ensure that the IETF
meeting participants have unfiltered access to the open Internet.

Russ