Re: [Netrqmts] IETF 105 Minutes

[Toerless Eckert <[e-mail]>]

On Tue, Jul 30, 2019 at 06:08:45PM -0400, Michael Richardson wrote:
> We used to see those people, they were in the terminal room re-installing
> windows 98.   Those days are over.  Firewalls have not prevents 14B a year of
> damage from trojans, and they never will as long as the MIME Security
> Considerations continues to be ignored.

Be that as it may. Whats the point of presenting an access thats
different from 99.999% of what users are experienced 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).
> 
> 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.

> I have been a NOC volunteer in decades past, and I've been involved in
> pulling "Long Range Ethernet" into places... at 4m vertical/floor, and 100m
> total for GbE over copper,  the 30th floor of some hotels was a problem.
> (Atlanta...)
> We aren't having to do this anymore.

Sure, but in return you're presented with all type of crappy
pre-existing L2 WiFi/LAN setup from the hotel, right ? Thats at least
what i was told when i asked about the Montreal setup. Sure, its
replacing real physcial labor with solving likely often proprietary
vendor configuration riddles. But impressive either way.

>     > Where would the discussion about what type of security options to
>     > offer/ document fit ?
> 
> I'd put them in /dev/null.
> I think that IETF participants are adults, and don't need this, and
> I don't think the IETF should take on the liability of offering anything that
> probably won't really help anyway.

Well, i think it does need at least to be documented better. And
actually asking the complete set of IETF attendents more formally via
something like a SurveyMoneky, would give more insight what they are
thinking after they have been educated.

>     > 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.
> 
> Meetecho gets wired infrastructure into each meeting room.  
> If not for that, if the hotel had decent Access Points, then we might not
> have to wire the meeting rooms at all.  If the hotel had large enough
> capacity Internet, but perhaps too poor (bufferbloated) latency, we might be
> able to get by providing an appropriate network for Meetecho only via other
> means.

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 to
all the big hotel chain network people if many of us would just continue
to ask other conferences to check that document and discuss with the
hotel they are using. The Meetecho example would be excellent to justify
a better buildout. Likewise the need to easily be able to set up
multiple SSID, have easily accessible policies for multicast/broadcast
policing (the issue we had in Montreal), IMHO also private-VLAN style
security, and so on and so forth. But if we only pick to mention one
particular narrow and very IETF centric security model, i don't think
such a document would be seen as too useful.

> I know that Meetecho is used at other conferences, and I assume that those
> conferences do not bring the same kit that IETF brings, so I wonder what they
> do there, and what problems we are avoiding.

Right.

Toerless

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