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

Michael StJohns <mstjohns@comcast.net> Thu, 01 July 2010 23:19 UTC

Return-Path: <mstjohns@comcast.net>
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 9C8AC3A6A96 for <ietf@core3.amsl.com>; Thu, 1 Jul 2010 16:19:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.274
X-Spam-Level: *
X-Spam-Status: No, score=1.274 tagged_above=-999 required=5 tests=[AWL=1.273, BAYES_50=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 P+2wwUO5nyc5 for <ietf@core3.amsl.com>; Thu, 1 Jul 2010 16:19:16 -0700 (PDT)
Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id 768AA3A67EC for <ietf@ietf.org>; Thu, 1 Jul 2010 16:19:16 -0700 (PDT)
Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta08.westchester.pa.mail.comcast.net with comcast id cnJv1e0011GhbT858nKVTX; Thu, 01 Jul 2010 23:19:29 +0000
Received: from Mike-PC3.comcast.net ([68.83.217.57]) by omta07.westchester.pa.mail.comcast.net with comcast id cnKU1e00H1EtFYL3TnKU3b; Thu, 01 Jul 2010 23:19:29 +0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 01 Jul 2010 19:19:19 -0400
To: Russ Housley <housley@vigilsec.com>, ietf@ietf.org
From: Michael StJohns <mstjohns@comcast.net>
Subject: Re: Admission Control to the IETF 78 and IETF 79 Networks
In-Reply-To: <4C2CE406.7090600@vigilsec.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>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <20100701231916.768AA3A67EC@core3.amsl.com>
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: Thu, 01 Jul 2010 23:19:17 -0000

At 02:52 PM 7/1/2010, Russ Housley wrote:
>No matter where a meeting is held, we are subject to the laws of that
>location.  Nothing new there.

Hi Russ -

I agree with the above statement, but its really beside the point.  The issue is not that the IETF and IETF attendees are required to obey the laws of the venue, but rather whether or not the IETF chooses to hold a meeting in a venue where the law is sufficiently ... restrictive, draconian, capricious, ?? ... to  require the IETF to change its model of operation.

As SM pointed out, the IAOC made the following determination when considering the Beijing venue:

>Whereas the IAOC heard all arguments made on the list, and
>  made its determination on the ability to hold a successful
>  meeting i.e. run it in a fashion as we always have, using the
>  tools that we always have, with a critical mass of the
>  traditional participants, discussing the usual topics."

This was specific to the "hotel gets to cancel the meeting on a whim" issue, but seems somewhat applicable to this topic.  We're instituting a new set of mechanisms , specific to this venue, not driven by changes requested or suggested by the IETF. So we're not doing this as  "run it in a fashon as we always have".

I would expect this (per user login) to fade away after Beijing - unless and until the IAOC and IETF agrees that its necessary for the longer term.  And I don't believe that discussion has been had.

With respect to this - it's too late to change the venue - and we're at the whim of the venue governments and regulations so we're pretty much stuck.  I'm hoping that further restrictions or changes will not be imposed, but don't know that I'm confident that will be the case.  

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. 

Thanks  - Mike