[Mtgvenue] Re: is identification of individuals already covered by BCP 226

[Toerless Eckert <[e-mail]>]

On Sat, Mar 28, 2026 at 12:13:20AM +0000, Stephen Farrell wrote:
> > Because the current rules per-eric-draft are not about desirability of the
> > network based on secret reasons you do not have to explain or "no technical
> > necessity" (as Eric puts it) but on feasibility to do IETF work or even (non-IETF) work at IETF
> > across the network.
> 
> I'm finding it hard to parse the above.
> 
> If you mean to assert that the only criterion for a good IETF meeting
> n/w is whether people can get IETF work done, then please accept that
> at least I, and I expect others, do not agree with that.

Those are just summarized are the current IETF mtgvenue requirements for network access.

> > And the other networks to compare to are quite relevant to those original goals
> > because they are the networks where IETF participants would also attempt
> > to achieve the same goals.
> 
> No, that's bogus. One could "do IETF work" purely in cleartext, as we
> mostly did 30 years ago. Going back to that would be just silly.

That is a bogus suggestion. We do have end-to-end encryption, we have VPNs.

Why do you need to expect less logging of IP-address/user from the IETF network
then when instead you would attend IETF remotely using your home network for example ?

> You may disagree, which is fine, but IMO an IETF meeting n/w that leaks
> participant activity to the local authorities as happened at ietf-125
> is just as bad, or maybe worse.

Your local network operator will equally log your IP address to your subscriber name.

If you are saying that you perfectly trust your home countries law enforcements
to do the right thing with that data when they need it, but not the law enforcements
of other countries - "and hereis a list of countries you trust and those you don't" - that
would be a perfectly defendable position. But without putting requirements against the
IETF network into context of what IETF participants normally accept for their
network access to do IETF work - and not providing any explicit descriptions of
what problems the network logging has when happening at the IETF network as opposed
to the other networks they are using - then i think you're not making a sound argument.

> Honestly, ISTM attempts to deny the problem here (which is how I
> interpret your mails on this) are not just unconvincing but likely to
> be counterproductive - I think you'd be better off accepting that the
> ietf-125 meeting n/w situation was exceptional and undesirable and
> engaging more on the "what to do about that" discussion.

Before IETF125, the absence of user IP address "logging" made the IETF network
the 0,0001% exception from all the other networks IETF users predominantly use
nowadays, and now that the IETF125 network is effectively using user IP addresses,
we get an outcry that the world has changed and that we must fight to stay an
exception from something we otherwise accept as unavoidable in our daily lives.
Without even giving any concrete problem (attack vector) descriptions other than

"Law enforcement - no technical necessity"

We really need that as IETF126 badge stickers.

Cheers
    Toerless

"IETF network: law enforcement is futile, you must be anonymous"

We really need those badge stickers when Eric draft becomes RFC unchanged.

Cheers
    Toerless