Re: [Netrqmts] IETF 105 Minutes

Alessandro Amirante <> Wed, 31 July 2019 13:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B312A120020 for <>; Wed, 31 Jul 2019 06:22:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HOAYcrpWFJyr for <>; Wed, 31 Jul 2019 06:22:11 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 50FC8120018 for <>; Wed, 31 Jul 2019 06:22:11 -0700 (PDT)
Received: from [] ([]) by with bizsmtp id jRN82002K0KiRsV01RN8Lf; Wed, 31 Jul 2019 15:22:10 +0200
To: Toerless Eckert <>
References: <> <19915.1564514403@localhost> <> <27837.1564524525@localhost> <> <2712.1564526544@localhost> <>
From: Alessandro Amirante <>
Message-ID: <>
Date: Wed, 31 Jul 2019 15:22:08 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="iso-8859-15"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=a1; t=1564579330; bh=KJG3lPfS/66ziOCZev6o/OmKRlHZNT4FMvEj/IOheJo=; h=Subject:To:From:Date:MIME-Version:Content-Type; b=Wpg7DMQnuYEK7DGyTHeftFWfUb3ftK1+2N9ALjcvAFQmJftUmITFcsCqOqLjZKQqp ZT3VOyO6OYCgTlnbyiZcA9caA/qikZXAHdOxHw1mtUzZCb7KUTsXztANawG9z1OsMv LCCesZK6Sykqfr7tT6CmSFw3qrEaZybu89LXo7watmpLodcbRvts502WOSrInbgSs4 2LgCBYw3Q5KqpVAN/HDwyjbtSxtmhyVeg8YzoM/Wh3GUmwVSovuPw4kcHD21r7iqdz JwZYXqoqyKisb1B6qUc7urp0JRmHeyQt9S+0/E9nbduS8bvdiFK/i1pTeEM9zM7LjV 9F7vFAVos19wg==
Archived-At: <>
Subject: Re: [Netrqmts] IETF 105 Minutes
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Meeting Network Requirements <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 31 Jul 2019 13:22:15 -0000

Il 31/07/19 00:58, Toerless Eckert ha scritto:
> On Tue, Jul 30, 2019 at 06:42:24PM -0400, Michael Richardson wrote:
>> Toerless Eckert <> wrote:
>>      >> A $22 home router fixes that problem.
>>      > Sure, but why would i have to bring my own WiFi<->WiFi home router to
>>      > the IETF to give me that function for the company notebook.
>> Laptops are regularly attacked at the Coffee Shop from BEHIND the NAT44
>> "firewall".  No firewall the IETF provides will solve that.
> That IMHO today an untypical and recgonizeable bad hotspot setup.
>> As your company IT guy why they gave you an insecure laptop for travel.
>> So seriously, go ask them.  NOT AN IETF PROBLEM.
> Providing access that is less secured than what users can normally
> expect at work/hotspots/home is an explicit IETF choice, and i am
> questioning why people would think its a good idea to only provide that
> choice.
>> Better yet, bring your company IT guy to IETF, so that they learn what's it
>> like to be connected to the actual Internet. As you say, most have never been online.
> Nobody connects endpoint to the actual Internet without firewalls in between.

This can be true for IPv4. It isn't for IPv6. I've had a NAT-ted v4 
address and a public v6 address for quite some time, both at home and at 
the office.


> Yes, a good travel notebook should have that firewall built-in. Many may
> be good. Windows probably a lot better than Linux. But its a kind of
> strange policy to provide such an uncommon type of access without
> communicating it clearly to the whole community and understanding their
> preferences.
>>      > I guess the best thing i could think of would be to have a BCP RFC for
>>      > how hotels should build out their network infrastructure to be best
>>      > prepared for conferences/workshops etc. This could easily proliferate
>> It's a great idea, and I sure wish it would occur.
>> To be effective, they hotel chains would need to solicit this document, and
>> pay a significant figure for the consulting.  Otherwise, they will ignore it.
> If a lot of conferences would refer to it, the hotels would not ignore
> it. Otherwise we might worst case support the business model of useless
> consultants reading our doc, and recommending its points for a lot of
> money to hotels.
> But yes, its work, so the question is whether there is enough critical
> mass to write it.
>> capport WG has been struggling for attention of the same types.
> I think thats a fundamentally different problem space.
> To automate the captive portal problem, you need to be able to tie every
> IoT devices authenticatication to some poor human, who forcefully has to absorb the
> advertisement of the portal and bear legal responsiblity requested by
> the portal. So pretty much you need a mobile phone app and cloud broker
> where iot device manufacturer can hire middle school kids that will then
> continuously watch advertisement clips from those portal operators and
> whose parents will pay the bail when the kid has to go to jail for
> something the IoT device did do wrong.
> Or else the business model of the captive portal has to change.
> Cheers
>      toerless
>> -- 
>> ]               Never tell me the odds!                 | ipv6 mesh networks [
>> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
>> ]        |   ruby on rails    [
>> -- 
>> Netrqmts mailing list

Ing. Alessandro Amirante, Ph.D.

Meetecho S.r.l.

Via Riviera di Chiaia 124
80122 Napoli, Italy

Mobile: +39 329 6178743