Re: Admission Control to the IETF 78 and IETF 79 Networks
SM <sm@resistor.net> Fri, 02 July 2010 18:09 UTC
Return-Path: <sm@resistor.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 DC2F73A681F for <ietf@core3.amsl.com>; Fri, 2 Jul 2010 11:09:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.869
X-Spam-Level:
X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[AWL=-0.914, BAYES_50=0.001, DATE_IN_PAST_03_06=0.044]
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 bd2UDUtJ9v74 for <ietf@core3.amsl.com>; Fri, 2 Jul 2010 11:09:48 -0700 (PDT)
Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 1F86A3A6832 for <ietf@ietf.org>; Fri, 2 Jul 2010 11:09:47 -0700 (PDT)
Received: from sm-PC.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.5.Alpha0/8.14.5.Alpha0) with ESMTP id o62I9Dvx001133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf@ietf.org>; Fri, 2 Jul 2010 11:09:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1278094199; x=1278180599; bh=mPlvqQpDtQETGKBczZO3JFO3FBsWvOk7EP7ZFpHwnBw=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=sxvxF47gCBS0PWX49aNynJDRc+ZoY33tWF3QaJkBCVVUrcWYda1j9E3lJiVvWFXVp GOjPJfcelVS7uSeFw4m0Z163vNlUe8qe8ZgHlNnpRLzWs2piDWpBojvFF0xY6ourAo YTTLEFF3uqlZCuvFKPF1X2wLFtX2GCmWbycMGs1w=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1278094199; x=1278180599; bh=mPlvqQpDtQETGKBczZO3JFO3FBsWvOk7EP7ZFpHwnBw=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=JBkImmiBIPXYeaD2K2IGuNwIR9hhbcAEj55VW+/PGcd1DkoD3H5Mj32504h4uXqr3 iA8NWiDBP0nHip3CWNXySzhL9/6RGKn2VoLLHxRNxMq9TOjU+8i2ZuqUeSRt1NlpAj aCQSfFcqeW+9yVWDmayOz5mYQuksEa6wzRuYqt+w=
DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=m6y7D7q2x7GbA9g2+ev2VveJGwSIWO0NvaM7i+eA5xHAeFTm1omGWeVz6VkDf8dMK mLXRYAQFYyyONpcjgLWhL8F0n6GgAmJyDmC7mHWooRk1nwxIa2+xTUqiBiK/8iHIAxi htDAn/Wja8NAByrYxe+JpBbCgY5mkzjx5qbI/ag=
Message-Id: <6.2.5.6.2.20100701210616.0b95a600@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Fri, 02 Jul 2010 07:36:05 -0700
To: IETF <ietf@ietf.org>
From: SM <sm@resistor.net>
Subject: Re: Admission Control to the IETF 78 and IETF 79 Networks
In-Reply-To: <6D6E25E2-057B-4591-9288-1283036D0374@cisco.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>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
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:09:50 -0000
At 08:26 01-07-10, Fred Baker wrote: >While it is new in IETF meetings, it is far from unusual in WiFi >networks to find some form of authentication. This happens at coffee >shops, college campuses, corporate campuses, and people's >apartments. I think I would need some more data before I concluded >this was unreasonable. I didn't conclude that it was unreasonable for reasons that are not mentioned above. At 08:41 01-07-10, Dave CROCKER wrote: >attendance includes many local folk. Once upon a time, IETF >meetings constituted an extremely collegial environment among folks >who knew each other. Today, attendance is much more diverse. Yes. At 08:50 01-07-10, Ole Jacobsen wrote: > I would have to disagree. You were probably not even born when we > had real terminal rooms with real terminals and computers and mean > looking security guards who very much did check badges. As stewards No comment. > of the IETF meeting resources, I would say that it is perfectly > reasonable for the IAOC (or the local host) to control access to > <insert resource> to only meeting participants. There is no principal > difference between cookies and network here as far as I am concerned. > And as others have pointed out, access control to WiFi networks is > the norm rather than the exception, even when they are "free". Two points: 1. Resources are finite 2. There can be abuse Having an open IETF network should not be read as an encouragement for abuse or to make abusive use of the resources. Some people may read it as an encouragement to do that. As long as that number is insignificant, it's not a problem. These people should not read this as meaning that they will get away with abuse. In my initial message I mentioned that "the person enjoyed the same privileges as those who have paid". Strictly speaking, that's a side effect of not enforcing access control. My message should also not be read as an encouragement not to pay to attend the meeting. The IETF might not be sustainable without the revenue from attendance fees. At 12:05 01-07-10, Russ Housley wrote: >Not totally right. The person with a badge can get one or more slips >with anonymous registration ID/passwords. The badge-holder can then >share the slip with accompanying persons (such as spouse or kids or < >let's not go there ;-) > ). The paragraph about that in the announcement did not go unnoticed. At 12:38 01-07-10, Martin Rex wrote: >Is there no more Terminal room on IETF these days with LAN access, >where access to the area is monitored but access to the network >is not de-anonymized? There were such access at some point. The IAOC may be able to confirm whether it will still be available. At 16:19 01-07-10, Michael StJohns wrote: >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. There was a long discussion about that because the venue was selected. My previous message was not to focus on that. >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". Yes. >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. Yes. >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. That's the reason why I didn't consider it as reasonable to argue about this change. This does not mean that I would consider it as unreasonable if you or someone else was to raise such an argument. >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? These questions came to mind. I preferred not to ask them. >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. Agreed. At 20:27 01-07-10, Health wrote: >ietf internet access is only for ietfers for free. What is your definition of "ietfers"? My initial message was more about social distance. I don't know whether the admission control requirement is a sign that the gap cannot be bridged. Regards, -sm
- Re: Admission Control to the IETF 78 and IETF 79 … Martin Rex
- Admission Control to the IETF 78 and IETF 79 Netw… IETF Chair
- Re: Admission Control to the IETF 78 and IETF 79 … SM
- Re: Admission Control to the IETF 78 and IETF 79 … Fred Baker
- Re: Admission Control to the IETF 78 and IETF 79 … Olivier MJ Crepin-Leblond
- Re: Admission Control to the IETF 78 and IETF 79 … Dave CROCKER
- Re: Admission Control to the IETF 78 and IETF 79 … Andrew Sullivan
- Re: Admission Control to the IETF 78 and IETF 79 … Richard L. Barnes
- Re: Admission Control to the IETF 78 and IETF 79 … Ole Jacobsen
- Re: Admission Control to the IETF 78 and IETF 79 … Joel Jaeggli
- Re: Admission Control to the IETF 78 and IETF 79 … Marshall Eubanks
- Re: Admission Control to the IETF 78 and IETF 79 … Andrew Sullivan
- Re: Admission Control to the IETF 78 and IETF 79 … Iljitsch van Beijnum
- Re: Admission Control to the IETF 78 and IETF 79 … Ted Hardie
- Re: Admission Control to the IETF 78 and IETF 79 … Russ Housley
- Re: Admission Control to the IETF 78 and IETF 79 … Richard L. Barnes
- Re: Admission Control to the IETF 78 and IETF 79 … Russ Housley
- Re: Admission Control to the IETF 78 and IETF 79 … Russ Housley
- Re: Admission Control to the IETF 78 and IETF 79 … Russ Housley
- Re: Admission Control to the IETF 78 and IETF 79 … Richard L. Barnes
- Re: Admission Control to the IETF 78 and IETF 79 … Iljitsch van Beijnum
- Re: Admission Control to the IETF 78 and IETF 79 … Russ Housley
- Re: Admission Control to the IETF 78 and IETF 79 … David Conrad
- Re: Admission Control to the IETF 78 and IETF 79 … Joel Jaeggli
- Re: Admission Control to the IETF 78 and IETF 79 … Randy Bush
- Re: Admission Control to the IETF 78 and IETF 79 … Randy Bush
- Re: Admission Control to the IETF 78 and IETF 79 … Randy Bush
- Re: Admission Control to the IETF 78 and IETF 79 … Martin Rex
- Re: Admission Control to the IETF 78 and IETF 79 … Randy Bush
- Re: Admission Control to the IETF 78 and IETF 79 … John C Klensin
- Re: Admission Control to the IETF 78 and IETF 79 … Ole Jacobsen
- Re: Admission Control to the IETF 78 and IETF 79 … Russ Housley
- Re: Admission Control to the IETF 78 and IETF 79 … Michael StJohns
- Re: Admission Control to the IETF 78 and IETF 79 … Randy Bush
- Re: Admission Control to the IETF 78 and IETF 79 … Russ Housley
- Re: Admission Control to the IETF 78 and IETF 79 … Russ Housley
- free internet for ieters only Health
- Re: Admission Control to the IETF 78 and IETF 79 … Robert Moskowitz
- Re: Admission Control to the IETF 78 and IETF 79 … Douglas Otis
- Re: Admission Control to the IETF 78 and IETF 79 … SM
- Re: Admission Control to the IETF 78 and IETF 79 … Ole Jacobsen
- Re: Admission Control to the IETF 78 and IETF 79 … Bob Hinden
- Re: Admission Control to the IETF 78 and IETF 79 … Phillip Hallam-Baker
- Re: Admission Control to the IETF 78 and IETF 79 … SM
- Re: Admission Control to the IETF 78 and IETF 79 … Iljitsch van Beijnum
- Re: Admission Control to the IETF 78 and IETF 79 … Andrew G. Malis
- Re: Admission Control to the IETF 78 and IETF 79 … Marocco Enrico
- Re: Admission Control to the IETF 78 and IETF 79 … Ole Jacobsen
- Re: Admission Control to the IETF 78 and IETF 79 … Marocco Enrico
- Re: Admission Control to the IETF 78 and IETF 79 … Joel Jaeggli
- Re: Admission Control to the IETF 78 and IETF 79 … Phillip Hallam-Baker
- Re: Admission Control to the IETF 78 and IETF 79 … Chris Elliott
- Re: Admission Control to the IETF 78 and IETF 79 … tytso
- Re: Admission Control to the IETF 78 and IETF 79 … Mark Atwood
- Re: Admission Control to the IETF 78 and IETF 79 … Chris Elliott
- Re: Admission Control to the IETF 78 and IETF 79 … joel jaeggli
- Re: Admission Control to the IETF 78 and IETF 79 … Phillip Hallam-Baker
- Re: Admission Control to the IETF 78 and IETF 79 … Chris Elliott
- Re: Admission Control to the IETF 78 and IETF 79 … Chris Elliott
- Re: Admission Control to the IETF 78 and IETF 79 … Martin Rex
- Re: Admission Control to the IETF 78 and IETF 79 … Chris Elliott
- Re: Admission Control to the IETF 78 and IETF 79 … Douglas Otis
- Re: Admission Control to the IETF 78 and IETF 79 … Donald Eastlake
- Re: Admission Control to the IETF 78 and IETF 79 … Phillip Hallam-Baker
- Re: Admission Control to the IETF 78 and IETF 79 … Phillip Hallam-Baker
- Re: Admission Control to the IETF 78 and IETF 79 … Phillip Hallam-Baker
- Re: Admission Control to the IETF 78 and IETF 79 … Phillip Hallam-Baker
- Re: Admission Control to the IETF 78 and IETF 79 … Iljitsch van Beijnum
- Re: Admission Control to the IETF 78 and IETF 79 … Iljitsch van Beijnum
- Re: Admission Control to the IETF 78 and IETF 79 … IETF Chair
- RE: Admission Control to the IETF 78 and IETF 79 … Josh Howlett
- Re: Admission Control to the IETF 78 and IETF 79 … Phillip Hallam-Baker