[discuss] discuss Digest, Vol 4, Issue 145

[Adiel Akplogan]

On Mar 17, 2014, at 01:37 AM, Steve Crocker <steve at shinkuro.com> wrote:

>>> The question has already been asked and I’ll ask again.  What is the
>>> specific problem about being subject to US law?  As a general matter,
>>> rule of law is usually considered one of the U.S.’s very strongest
>>> qualities.
>> 
>> This has been answered many times by many people, but I will answer yet again.  US law on occasion restricts who a company does business with. Losing NTIA oversight does not change that.  IANA should not be subject to such vagaries of national law.
> 
> If you’re referring to OFAC, there are similar mechanisms in every jurisdiction.  There is no obviously “completely safe” place anywhere on earth. In practice, ICANN has navigated this area extremely well.

Hello Steve, I’m not sure “extremely well” is quite right here. I do believe that ICANN tries to do its best in that area, but frankly OFAC is an illustration of IANA functions (and in some extend ICANN) being subject to a specific country's laws is not aligned with the Internet as an open and permissionless innovation tools we defend. And because there will be similar mechanism in every jurisdiction, IANA function (and ICANN) should look for a way to operate under a Host country agreement (or similar) where the critical role of the function is recognised and protected against a one country based "interest". There has been few scenarios proposed on the list that may need attention and further Analysis. That clearly will be the next "big" thing to fix in the debate of IANA function now that the USG has clearly stated their intent to give up their unique role. One thing at the time but with diligence.

- a (only my personal view).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 313 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://1net-mail.1net.org/pipermail/discuss/attachments/20140317/3f9c3220/signature.asc>