針對人們在參與互聯(lián)網(wǎng)標準制定中存在的一些問題和誤區(qū)，日前，IETF的資深研究人員Nick發(fā)了一份郵件。
郵件是發(fā)給一個名叫Khaled的人。Khaled之前提交了自己的一個新的協(xié)議方案草案，自我感覺非常好。但該方案在IETF并沒有得到采納，他感到很生氣。這一過程持續(xù)了兩年，他一直說自己的方案非常好，但自己不是程序員，無法編程驗證。最近他又換了一個工作組，重新提出他的草案，并發(fā)出關(guān)于IETF不夠重視其提議的公開郵件。針對此，Nick提出四點建議，這些建議提到的一些問題對于想在IETF提交草案并期望能夠成為RFC標準的研究人員同樣具有參考價值，郵件內(nèi)容如下：
Khaled：
過去幾年中，有很多人看過你提議，他們通過幾百封郵件的討論交流后一致得出相同的結(jié)論：你的提議行不通。實際上，這也意味著，你是在要求IETF工作組處理一個他們覺得行不通的提議。
如果你想讓IETF慎重考慮你的想法，那么你首先需要證明這些提議是可以實現(xiàn)的。那你就需要從傾聽和處理意見開始，尤其是那些被多次提出著重討論的問題。
關(guān)于此，我有幾個建議：
1. 寫一份你所提出的提議是如何工作的原理實現(xiàn)。或者是講清楚，你所提出的技術(shù)是如何與IPv4或者IPv6網(wǎng)絡(luò)建立連接的？
2. 更新其他協(xié)議的規(guī)范文件以支持你的提議，如路由協(xié)議：BGP、mpls、OSPFv2、OSPFv3、ISIS等。僅針對這些協(xié)議就至少有500個RFC，所以為什么不選擇一小部分進行更新，使其能夠支持你的想法？如果你能編寫出一個有效的實現(xiàn)文檔，應(yīng)該會更好。
3. 為主機應(yīng)用程序編寫一個API規(guī)范以解決雙重尋址問題。
4. 寫一份你所提議的“路由協(xié)議”的實現(xiàn)細則，它應(yīng)允許一個網(wǎng)絡(luò)與另一個網(wǎng)絡(luò)交換路由信息。專業(yè)提示：確保它能在你提議的技術(shù)上工作。
說你不是程序員以及讓別人為你的想法編寫代碼必然是不可取的?，F(xiàn)在的問題是，許多研究人員已經(jīng)明確表示你的想法不可行，如果你希望你的想法被認真、慎重對待，那么你有責(zé)任去證明他們的想法是錯誤的。
一直爭辯別人應(yīng)該認真對待你的想法，這件事也是沒有用的。除非你能證明它們是可以工作的，是確實有效的，否則人們不會認真對待它們。
當(dāng)你寫出代碼證明你的想法確實可行，然后再回到IETF，也許那時人們會更認真地對待你的想法。
Nick