Re: [Netrqmts] IETF 105 Minutes

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 30 July 2019 19:20 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: netrqmts@ietfa.amsl.com
Delivered-To: netrqmts@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 763EC12010F for <netrqmts@ietfa.amsl.com>; Tue, 30 Jul 2019 12:20:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bholv9v0Pcvv for <netrqmts@ietfa.amsl.com>; Tue, 30 Jul 2019 12:20:05 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 238B012001E for <netrqmts@ietf.org>; Tue, 30 Jul 2019 12:20:04 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 192613808A for <netrqmts@ietf.org>; Tue, 30 Jul 2019 15:19:39 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9BAB814 for <netrqmts@ietf.org>; Tue, 30 Jul 2019 15:20:03 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: netrqmts@ietf.org
In-Reply-To: <DF3803B7-C05B-4A31-B873-73A86B1416CE@vigilsec.com>
References: <DF3803B7-C05B-4A31-B873-73A86B1416CE@vigilsec.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Tue, 30 Jul 2019 15:20:03 -0400
Message-ID: <19915.1564514403@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netrqmts/2xzcoSl8u02p5t9sPU2O3xgWAi0>
Subject: Re: [Netrqmts] IETF 105 Minutes
X-BeenThere: netrqmts@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Meeting Network Requirements <netrqmts.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netrqmts>, <mailto:netrqmts-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netrqmts/>
List-Post: <mailto:netrqmts@ietf.org>
List-Help: <mailto:netrqmts-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netrqmts>, <mailto:netrqmts-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Jul 2019 19:20:08 -0000

I didn't go to this BOF at the last minute due to a conflict.
thanks for the notes.  I haven't seen the slides or watched the video yet.

>   ???: To get my job done without a real network, I'd be three levels
>    deep in SSH tunnels. The question is how much this gets in the way.

+5.
I find that the most important thing that the IETF meeting (network) does for
people, is that it gives them an idea what a real end-to-end transparent
network *can* be like.  Suddenly things that never worked for them work.

>   Lars: We can overengineer the network.  We could provide less and we
>     would still have less.  The network is awesome.  We could scale
>     back a little.  Our bar is so high we exclude venues that might be
>     cheaper.  I can run certbot on a laptop and renew a cert.  Do I
>     need that?  Not really.

Until IPv6 is ubiquitously available in the guest rooms, I don't know how we
can do less.  I agree that we shouldn't have to do so much... but Bob Hinden is right!

If we are going to continue to make such investments, can we somehow do so in
a useful way?   Can we collaborate with the hotel to make changes that persist?  
This goes into returning to the same hotels regularly, and *is* a mtgvenue
discussion, not a netrqmts discussion.

I think that we should split up the discussion into perhaps four areas.

1) the L2/WiFi coverage of the meeting rooms for IETF participants

2) the availability of IPv6 in the guest rooms [I don't mind captive portals,
   *if* they follow our WG's specification...]
   
3) the availability and flexibility of the bandwidth in/out of the conference
   hotel(s).

4) the architectural requirements for good IPv6 and good meetecho experience
   within the venue.

I think that the document tries to do this, but I don't get the impression
the discussion split things up.

One could imagine a situation where the Meetecho network was a different
network from the Participant network.  I'm not saying that's a good plan, but
I'm saying that I think that we should think about whether we are expending
a lot of effort in one area for reasons that are relating to another area.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [