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

Phillip Hallam-Baker <hallam@gmail.com> Fri, 02 July 2010 00:29 UTC

Return-Path: <hallam@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 379F13A67CC for <ietf@core3.amsl.com>; Thu, 1 Jul 2010 17:29:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.826
X-Spam-Level:
X-Spam-Status: No, score=-1.826 tagged_above=-999 required=5 tests=[AWL=0.773, 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 unAswRbWkge2 for <ietf@core3.amsl.com>; Thu, 1 Jul 2010 17:29:51 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id E679A3A659C for <ietf@ietf.org>; Thu, 1 Jul 2010 17:29:50 -0700 (PDT)
Received: by iwn10 with SMTP id 10so258900iwn.31 for <ietf@ietf.org>; Thu, 01 Jul 2010 17:30:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BRz0FFEclhYiJmvIiK94fpFqNEFVcDpOOEfer11Evgw=; b=fmt2HEs6NEAdxTmmwGoberxvcNCDxt8cZjPzQNwrifXK1YenFvzSOwR4Ze0QXiOpry tB7eV+Zce9Gc67gF8GwSfEHccd+HPOvMVQLwtpDUH+Pvi3/ZKV6dX54YqZ36/OBw1I+F AW4w2w4aoGnSO5ZdqYC8K4gzoaOQNrr7H5OKU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=SgHm26uLSvwt+2zeUHicUlurV5y2kvqKVuNHoaxQMWoQsu3MkjkWT5IaRRwe6vED6b N1XkNL8QGfCrqTqGravNnQoo84u7ThQiBHCaET19KubK9CqX2pl2KBNsIFfryOYMxiDr 9ImX06ehlwFODke3CjKH/WXNBRa5BvgYpsY+0=
MIME-Version: 1.0
Received: by 10.231.14.200 with SMTP id h8mr231341iba.188.1278030602247; Thu, 01 Jul 2010 17:30:02 -0700 (PDT)
Received: by 10.231.14.73 with HTTP; Thu, 1 Jul 2010 17:30:02 -0700 (PDT)
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>
Date: Thu, 01 Jul 2010 20:30:02 -0400
Message-ID: <AANLkTinMFsrGyIy9bu5kzUiZqNmDbf7lpS-eht8h3hvP@mail.gmail.com>
Subject: Re: Admission Control to the IETF 78 and IETF 79 Networks
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Fred Baker <fred@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Fri, 02 Jul 2010 15:13:38 -0700
Cc: SM <sm@resistor.net>, IETF <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 00:29:52 -0000

Actually, I wish we had done something in this area sooner in the hope
of creating a forcing function to make the authentication mechanisms
in WiFi more appropriate.

It has taken ten years for WiFi to get to a state where an adequate
credential mechanism is supported, and it is still clunky. And they
still don't have a decent mechanism to support the typical coffee shop
type access mode.


On Thu, Jul 1, 2010 at 11:26 AM, Fred Baker <fred@cisco.com> 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.
>
> On Jul 1, 2010, at 8:08 AM, SM wrote:
>
>> Hello,
>> At 14:55 30-06-10, IETF Chair wrote:
>>> I am writing to let you know about a change in the IETF meeting network.
>>> At IETF 79 in Beijing, the IETF network will be connected to the open
>>> Internet with absolutely no filtering.  However, we have agreed with our
>>> hosts that only IETF meeting participants will have access to the
>>> network.  Following sound engineering practices, we will deploy
>>> admission control mechanisms as part of the IETF 78 meeting network in
>>> Maastricht to ensure that they are working properly before they are
>>> mission critical.
>>
>> Most IETF participants probably know that the consensus of the IETF is documented through BCPs and other Standards Track RFCs.  If the text in the RFC isn't clear, there is room for disagreement.  If it is ill-defined, someone will go and find the loophole.  If the above text was in a BCP, we could nit on the definition of IETF meeting participants.  It is clear to people unfamiliar with the IETF that IETF meeting participants means people who have registered for the IETF meeting.
>>
>> I have been told that an IETF meeting does not have security guards at the door to verify who has a badge to determine whether the person is registered for the meeting.  If someone walks into an IETF meeting, the person can enjoy the cookie for free and even provide a contribution at the mic.  The person enjoys the same privileges as people who have paid for meeting attendance fee.
>>
>> I'll take the opportunity to thank Karen O'Donoghue for keeping the IAOC minutes up to date.  The IAB could do with some help in that area.
>>
>> Some of you may recall that the Beijing venue contract was discussed on this mailing list last year.  It resulted in some resolutions as follows:
>>
>> "Whereas the Host has assured the IAOC that 'a normal IETF
>>  meeting can be legally held in China and that no pre-screening
>>  of material or monitoring of session content is required or will
>>  be done,'
>>
>>  Whereas the IAOC, based on the assurances of the Host and a
>>  history of the venue successfully hosting major international
>>  conferences that relate to our industry, believes a normal IETF
>>  meeting can be held at the 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."
>>
>> The fashion in the IETF is to have an open network.  There isn't any admission control and credentials are not required to enjoy the benefit of free and full Internet access.  The IETF may run out of cookies; it never runs out of bandwidth.
>>
>>> I am writing to let you know what to expect in both Maastricht and Beijing.
>>
>> And it is expected that the comments on this thread will follow sound IETF practices when it comes to mailing list discussions. :-)
>>
>> Regards,
>> -sm
>> _______________________________________________
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
>
> http://www.ipinc.net/IPv4.GIF
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>



-- 
Website: http://hallambaker.com/