Re: Remote participation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




--On Tuesday, November 03, 2015 08:35 +1300 Brian E Carpenter
<brian.e.carpenter@xxxxxxxxx> wrote:

>> If the corporate firewall can't be bothered to behave
>> decently, the answer may be to .... pick up the phone.
> 
> Harald is onto something. But the real point is to test in
> advance and if it doesn't work, find a work-around.

And then test the workaround and, if that doesn't work, try
something else or give up.

> I hate to suggest more work for our Meetecho friends, but
> maybe the testing needs to be a bit more organised and 24
> hours in advance (or maybe 12 hours in advance for Monday
> sessions). And if it fails, no compromise: don't try.

Given my limited understanding of TCP/IP, there are three
possible areas of problems that would affect some remote users
and not others:

(i) Close to the user site, i.e., between the user's location
and the Internet.

(ii) Close to the IETF site, i.e., in the connectivity between
the IETF LAN(s) and the WAN connection(s)

(iii) Routing or source-related filtering problems across the
Internet (and past any user-site-associated firewalls or other
filters) and the IETF site.

If Meetecho isn't working (at all or on the IETF LAN), that is a
different problem and would affect everyone, as would the IETF
network being down or completely disconnected.

Now, at least in my experience, the first of these is by far the
most likely.  To the extent that it is application-specific, it
should be possible to test to Italy, California, or any other
convenient location and to do so weeks in advance -- early
enough to affect WG agendas without a meeting week fire drill.
The second should require fairly easy tests as soon as the IETF
network come up and should be easy to perform because they are
not participant-specific.   For the third, some of the possible
issues will not exist as long as we are consistent about
requiring a non-filtered environment as the price of selecting a
site.  For the rest --an actual network or routing outage
somewhere "in the middle", -- advanced testing won't help.   

So, while I'd be happier with confirmation between participant
location and the actual meeting Meetecho setup 12 or 24 hours in
advance, I think the vast majority of cases --especially those
for which "restrictive corporate firewall" is a special case--
can be checked out a week, or even a month, in advance and
should be.

    john






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]