Re: [Netrqmts] IETF 105 Minutes

[Toerless Eckert <[e-mail]>]

On Tue, Jul 30, 2019 at 03:20:03PM -0400, Michael Richardson wrote:
> +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.

As i said in my prior mail to this list (which went without any reply),
most people nowadays wouldn't even know what it means to be directly on
the internet without any firewall, and i really question whether it is
prudent to ONLY have this option and NOT document it very clearly to all
those users not working at the network level. I also think that folks
who want to test if their applications work well and invested into
ICE/STUN and other firewall traversal mechanisms (like RTCweb and other
app groups), would maybe like to have something more reflective of
relevant end-user access (with firewall).

As much as we network layer nerds may like it, we should understand and
acknowledge that it doesn't represent a reasonable end-user-device
access method to not have any firewall. And i am mostly concerned about 
all those company notebooks used in IETF which too would expect even at starbucks
to have some degree of protection against scanning attacks. At leat on
one SSID.

> 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 am already surprised how much the IETF noc team has been able to work
with hotels existing AP and access-LAN infrastructure and make it work
as good as possible. I do not always like the results (like in
montreal), but lets not underestimate the complexity of the job of the
noc doing this. 

> 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.

Where would the discussion about what type of security options to offer/
document fit ?

> 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.

Not sure what other think to be meetecho problems. I only thoght the
video quality from remote participants sucked but didn't get an answer
whether thats because of unavoidable remote participant upstream limits
or application level enforced uper bandwidth/quality limits.

Cheers
     Toerless