分类目录归档:杂项

请帮助阻止将.org域名的非政府非营利管理机构Public Interest Registry (PIR)出售给私人持股公司

今日惊闻.org域名管理机构Public Interest Registry 将要被出售给一家私人持股公司,由于担心出售后的巨大风险,社区发起了一场活动 SaveDotOrg,意在呼吁ICANN和PIR停止此项交易。为了让更多的中文社区了解此项交易带来的风险,共同为互联网的繁荣,捍卫其所一直坚持的原则,我将SaveDotOrg 的公开信翻译为中文,以便读者了解情况,如果您愿意支持此项活动,阻止此项交易,请在 https://savedotorg.org/ 的 “TAKE ACTION ” 部分进行登记声援。谢谢!

为了读者能够理解公开信中涉及的组织信息,对其中几个组织进行一些说明:

ISOC: 全名为 Internet Society ,国际互联网协会, 为一个非政府非营利的国际组织,主要职责是制定互联网相关标准,加快互联网的普及。

PIR: Public Interest Registry, 负责.org域名的管理,2002年由ISOC创建,属于非政府非营利组织。此次被出售对象正是该组织。

ICANN:全名为 Internet Corporation for Assigned Names and Numbers, 为互联网名称与数字地址分配组织,非政府非营利组织。负责ip地址管理、域名管理、根服务器管理。所以,与域名有关的业务如果出现侵权事项,都可以联系该组织解决。特别是若遇到国内一些域名代理商锁定域名迁移、更新域名所有人信息时设置障碍并收费这类事件,都可向该组织进行投诉,但.cn域名就算了。域名属于所有者资产,所有人有权进行所有人联系信息等的变更、也有权更换其域名代理商。此次交易之所以涉及ICANN的批准,原因也正是ICANN的职责和权利所在。

以下为公开信翻译:

请帮助阻止将.org域名的非政府非赢利组织Public Interest Registry (PIR)出售给私人持股公司

日期:2019-11-22

收件人:

  • Andrew Sullivan, CEO, Internet Society(ISOC)
  • Jon Nevett, CEO, Public Interest Registry(PIR)
  • Maarten Botterman, Board Chair, Internet Corporation for Assigned Names and Numbers(ICANN)
  • Göran Marby, CEO, Internet Corporation for Assigned Names and Numbers (ICANN)

我们督促您停止将Public Interest Registry (PIR)出售给 Ethos Capital。

全世界的非政府组织都依赖顶级域名 .org 。

影响.org域名的决策必须咨询非政府组织团体,并在受信任的互联网社区领导人监督下进行。如果互联网协会 (ISOC)不再是互联网社区的领导人,则应与非政府组织团体和互联网名称与数字地址分配机构(ICANN)合作,以寻求合适的替代者。

2019年, .org域名的注册协议明显偏离了拥有34年历史的.org域名。它使注册管理机构有权制定一些不利于.org域名社区的政策:

  • 未经ICANN或.org社区批准而提高.org域名注册费的权力。.org价格上涨将使很多资金短缺的非政府组织处于困境,要么支付增加的费用,要么失去.org域名的合法性和品牌知名度。
  • 无需咨询.org社区即可单方面开发和实施权利保护机制的权力。如果不与非政府组织团体合作精心设计此类机制,则它们可能会审查完全合法的非营利活动。
  • 有权基于“违反适用法律的活动”的指控实施暂停域名的流程。.org注册机构不应该执行这样的流程,而无需了解国家机关如何频繁以指控非法活动为目标针对非政府组织。

域名注册机构可能滥用这些权力,有意或无意对全球非政府组织造成重大伤害。我们不能将.org的管理权交由尚未获得非政府组织团体信任的私人持股公司处理。.org域名必须由将非政府组织的需求置于利润之上的领导者进行管理。

当ISOC最初于2002年提出将.ORG的管理权转移到PIR(Public Interest Registry)时,ISOC当时的总裁兼首席执行官Lynn St. Amour承诺.org域名将继续由非政府组织社区推动–用她的话说,PIR将“利用ISOC在全球网络的扩展资源来推动政策和管理。”。 做为全球网络的长期成员,我们坚持要求您遵守诺言。

from: https://savedotorg.org/

为了捍卫互联网一直坚持的原则,请支持此项活动,阻止此项交易!阻止这类事情发生是为了不让它再次出现,让互联网的原则被坚持!请至 https://savedotorg.org/ 的”TAKE ACTION” 进行声援!谢谢!

0.7check规则

今天在工作中遇到个问题,发现有个已经单体测试完成的source严重与详细设计书不一致,经过调查发现,程序在单体测试开始过程中进行了不断的修正,而没有同步的将详细设计对应的进行修正。于是,我查看了版本发现,程序从单体测试开始到测试完成共修正了18次,而详细设计仅修改了7次,详细设计对应频率为7/18=0.39,这个比值直观的感觉就比较小了!然后我查看了没有不一致的代码和详细设计,并计算了这个比值,发现,它们基本在0.7左右波动。呵呵,也许这就是个规则,也就是说,平均每修改10次source就应该对应修改7次详细设计,小于这个值就很有可能出现不一致现象,一定要进行严格 check,而大于这个可能会导致大家的厌烦,所以我喜欢把这个称为0.7check规则。以后检查时先看这个频率

p=详细设计对应修改次数/source修改次数
当p<0.7时, 一定要进行再次check; 0.7=<p<0.8时,应该基本正常;p>=0.8时,详细设计修改次数过多,增加了工作量.
希望这个规则能对大家管理项目有所帮助.:)

作者:豆博草堂