Re: [Netrqmts] IETF 105 Minutes

[Michael Richardson <[e-mail]>]

Toerless Eckert <[e-mail]> wrote:
    > 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

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.

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

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

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

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

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

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