针对人们在参加互联网尺度制订中存在的一些问题和误区，，日前，，IETF的资深钻研人员Nick发了一份邮件。。。
邮件是发给一个名叫Khaled的人。。。Khaled之前提交了自己的一个新的和谈规划草案，，自我感触极度：。。。但该规划在IETF并没有得到选取，，他感应很生气。。。这一过程持续了两年，，他一向说自己的规划极度：，，但自己不是法式员，，无法编程验证。。。最近他又换了一个工作组，，重新提出他的草案，，并发出关于IETF不够器重其提议的公开邮件。。。针对此，，Nick提出四点建议，，这些建议提到的一些问题对于想在IETF提交草案并进展可能成为RFC尺度的钻研人员同样拥有参考价值，，邮件内容如下：：
Khaled：：
从前几年中，，有好多人看过你提议，，他们通过几百封邮件的会商互换后一致得出一样的结论：：你的提议行不通。。。现实上，，这也意味着，，你是在要求IETF工作组处置一个他们感触行不通的提议。。。
若是你想让IETF郑重思考你的设法，，那么你首先必要证明这些提议是能够实现的。。。那你就必要从倾听和处置定见起头，，尤其是那些被屡次提出着重会商的问题。。。
关于此，，我有几个建议：：
1. 写一份你所提出的提议是若何工作的道理实现。。 ；；；蛘呤墙裁飨，，你所提出的技术是若何与IPv4或者IPv6网络成立衔接的？
2. 更新其他和谈的规范文件以支持你的提议，，如路由和谈：：BGP、、、mpls、、、OSPFv2、、、OSPFv3、、、ISIS等。。。仅针对这些和谈就至少有500个RFC，，所以为什么不选择一小部门进行更新，，使其可能支持你的设法？若是你能编写出一个有效的实现文档，，应该会更好。。。
3. 为主机利用法式编写一个API规范以解决双重寻址问题。。。
4. 写一份你所提议的“路由和谈”的实现细则，，它应允许一个网络与另一个网络互换路由信息。。。专业提醒：：确保它能在你提议的技术上工作。。。
说你不是法式员以及让别报答你的设法编写代码必然是不成取的。。。此刻的问题是，，很多钻研人员已经明确暗示你的设法不成行，，若是你但愿你的设法被当真、、、郑重对待，，那么你有责任去证明他们的设法是谬误的。。。
一向辩论别人应应该真对待你的设法，，这件事也是没有效的。。。除非你能证明它们是能够工作的，，是的确有效的，，不然人们不会当真对待它们。。。
当你写出代码证明你的设法的确可行，，而后再回到IETF，，也许那时人们会更当真地对待你的设法。。。
Nick
