Re: Restricting participant access to the standards process

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

 



ACK.

Basically, the IETF is a legal construct that was formed under US law but operates internationally and is thus subject to multiple jurisdictions. And given the times in which we live with authoritarian politicians trying to seize power by force and corrupted courts which would do well to note the surprisingly limited scope the constitution actually grants them, etc. etc. there is a high likelihood of a conflict occurring between what IETF members think should be done and the law.

When Ted Hardy got up to the microphone to protest the choice of Singapore as a venue on account of the bar on homosexuality there, I am pretty sure that there wasn't a single attendee who imagined we might be seriously considering the possibility that we might have to cancel plans for a future meeting in Texas on account of that consideration. And yet, here we are.


The only approach the IETF can be reasonably expected to take in such circumstances is to limit activities such that its exposure to adverse jurisdictions is unlikely to seriously impair its operations.

If push comes to shove and it is no longer possible to operate in that fashion, some of us will take whatever actions are necessary to ensure that we can continue our work outside the IETF. The question of the IETF attempting to operate illegally simply does not and will not arise.


At this point, I am putting all my energies into writing code. The achilles heel of our efforts to protect privacy with *public* key infrastructure was that we failed to provide the necessary management tools for the *private* key. I will be announcing the release of the first phase of the Mesh that addresses that issue at HOPE 2022 the weekend before IETF 114.

The second phase builds on the first and provides contact assertions that automatically update and can provide account address information for any Internet application, protocol or service. That should be ready in 12 months time.

In our current environment, end-to-end secure is table stakes. We have to go further and lock down all the control points in the communication infrastructure that may be subject to coercion by authoritarian governments. That includes the means by which contacts are exchanged and validated and the application itself. And we have to do that in an application that is 'zero-effort', we cannot ask anything of the user at all.


Having been through the WebRTC work, I am pretty sure that I can deliver a system that meets the new requirements.


On Thu, Jun 30, 2022 at 10:45 PM Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote:
On 01-Jul-22 01:32, Livingood, Jason wrote:
>> please define the courts with jurisdiction over IETF LLC.
>
> For better or worse the IETF LLC is required to operate within the law. For example, US courts could serve the LLC with legal orders and we must comply with US tax laws (and other US laws and state laws). When we held a meeting in Vienna, we had to comply with local Austrian laws, and so on. When we meet in Philadelphia, US federal laws, Pennsylvania state laws, and Philadelphia local laws will apply - and each have their respective court systems.

Also, the LLC has staff and operations in countries outside the USA, which would certainly be subject to local jurisdiction on employment and tax law etc., completely regardless of the IETF's purpose.

    Brian


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

  Powered by Linux