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

Bob Hinden <bob.hinden@gmail.com> Fri, 02 July 2010 18:52 UTC

Return-Path: <bob.hinden@gmail.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 C0DF13A68B6 for <ietf@core3.amsl.com>; Fri, 2 Jul 2010 11:52:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.388
X-Spam-Level:
X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=0.211, 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 oTQ53r76pTn5 for <ietf@core3.amsl.com>; Fri, 2 Jul 2010 11:52:29 -0700 (PDT)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id B15023A67F9 for <ietf@ietf.org>; Fri, 2 Jul 2010 11:52:29 -0700 (PDT)
Received: by pwj2 with SMTP id 2so1762355pwj.31 for <ietf@ietf.org>; Fri, 02 Jul 2010 11:52:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=nWM5qaUk3F/cD1nHVtozotGqdv2phYO5FKHWpNHFcQw=; b=lBKc6gEnsME/cjt0e+Ry9st4aRCL2m7f4O/GwdpzaH6P20276ilUlYtrcZCQhzuHhY FedPsRY075e3nL+lE56JkXBcUFbYRfQDIbZdFKYcCBj/1v4AVDuz9aLvnOZDkOjczFSZ INBBi32RkVjMCo22F+7W8YtZ2IzKeSLDg5eDw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=tf2DWkNo2CQYCFmkc8kqgPh1JeDQiuMyq56qoBZNNhRLxAhxOFoG+FMLp3Uh9R5qCU xhQjDaqPZDEY6OmuhN2rH6DfWu8yU1fqOqn5oQZtrMJeRpXbQvRVKr9S8jLwNpvbRYhT xAgMUqbCwl7w9BAPO67GxsArLJZoKp36f0DBc=
Received: by 10.114.123.20 with SMTP id v20mr1568786wac.93.1278096757454; Fri, 02 Jul 2010 11:52:37 -0700 (PDT)
Received: from [10.0.0.37] (c-67-188-5-28.hsd1.ca.comcast.net [67.188.5.28]) by mx.google.com with ESMTPS id n32sm14579909wag.11.2010.07.02.11.52.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 02 Jul 2010 11:52:36 -0700 (PDT)
Subject: Re: Admission Control to the IETF 78 and IETF 79 Networks
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Bob Hinden <bob.hinden@gmail.com>
In-Reply-To: <20100701231916.768AA3A67EC@core3.amsl.com>
Date: Fri, 02 Jul 2010 11:52:34 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <F82B2716-FF9A-442E-AFA2-F95323E50617@gmail.com>
References: <CFB08C07-DE90-47BE-ADFF-FC72162BBFA1@daedelus.com> <4C2BBD51.2060605@ietf.org> <6.2.5.6.2.20100701070804.0c26b8a0@resistor.net> <6D6E25E2-057B-4591-9288-1283036D0374@cisco.com> <20100701154421.GB43159@shinkuro.com> <4C2CE406.7090600@vigilsec.com> <20100701231916.768AA3A67EC@core3.amsl.com>
To: Michael StJohns <mstjohns@comcast.net>
X-Mailer: Apple Mail (2.1081)
Cc: Bob Hinden <bob.hinden@gmail.com>, ietf@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: Fri, 02 Jul 2010 18:52:30 -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. 

I don't remember exactly when this came up, probably after the previous Beijing discussion.  It came up as part of the discussion with the host that in order to provide a non-filtered Internet connection as required in the MOU, they would need a mechanism to limit network access to only IETF meeting attendees.  Since we were not there to provide a network to non-IETF attendees and doing simple admission control was common in venues like NANOG., I didn't think this was an unreasonable request, nor would it keep us from having a normal IETF meeting.  I would also note the that there is a lot of variance in different IETF venues, such as voltage, food, local languages, etc., etc.  I saw this as something in that class of differences, not as as something that would keep us from having a productive IETF meeting.

The IEFF NOC volunteer team has been working closely with the local host team to develop something that is as light weight as possible and still meet their requirements.

Hope this is helpful.

Bob