VPN एग्ज़िट पता रजिस्टर को वास्तव में क्या दर्ज करना चाहिए?
एग्ज़िट रजिस्टर तभी उपयोगी है जब हर प्रविष्टि अपना अर्थ, अपना प्रकाशक और अपनी समाप्ति बताए। वर्गीकरण ग्राहक की पहचान नहीं है।
एग्ज़िट रजिस्टर सूचियों जैसे लगते हैं, और सूची कठिन हिस्सा नहीं है। कठिन हिस्सा यह तय करना है कि हर प्रविष्टि क्या दावा करती है, उसे कौन प्रकाशित कर सकता है, और जब दावा सच नहीं रहता तो क्या होता है। इन प्रस्तावों में तीन अलग पता भूमिकाएँ आपस में मिला दी जाती हैं, और जो रजिस्टर उन्हें मिलाता है वह किसी भी प्रश्न का भरोसेमंद उत्तर नहीं दे सकता। एक प्रविष्टि को प्रकाशन से वापसी तक ट्रैक करें और डिज़ाइन की आवश्यकताएँ स्वयं दिखाई देंगी।
सूची से नहीं, रिकॉर्ड से शुरू करें
पहला प्रश्न यह नहीं है कि कितने पते शामिल करें, बल्कि यह है कि एक पंक्ति का क्या अर्थ है। क्या यह बताती है कि ग्राहक कहाँ जुड़ते हैं, कोई गंतव्य कौन-सा स्रोत देख सकता है, या रजिस्टर में आवंटन किसके पास है? ये तीन दावे हैं, तीन स्वामियों और तीन विफलता विधियों के साथ। जो रजिस्टर यह नहीं बताता कि वह इनमें से कौन-सा दर्ज करता है, उसका सत्यापन, सुधार या समाप्ति नहीं की जा सकती। अर्थ को सही ढंग से समझना डिज़ाइन का काम है, और सूची केवल परिणाम है।
कोई भी स्कीमा लिखने से पहले पंक्ति की परिभाषा लिखें। अगर परिभाषा को «और» शब्द की ज़रूरत है, तो संभवतः ये दो रिकॉर्ड हैं जो एक होने का दिखावा कर रहे हैं।
एक जैसी दिखने वाली तीन पता भूमिकाएँ
भूमिकाओं को मिलाना आसान है क्योंकि एक परिनियोजन तीनों का एक साथ उपयोग कर सकता है, और अक्सर करता है। एक सेवा एक पते पर कनेक्शन समाप्त कर सकती है और दूसरे पते से ट्रैफ़िक अग्रेषित कर सकती है, जबकि एक रजिस्टर पूरी तरह से तीसरा तथ्य दर्ज करता है।
| Address role | Who may publish | What it does not prove | Withdrawal trigger |
|---|---|---|---|
| Forwarded exit | The operator that forwards the traffic, or a feed it authorizes | That a subscriber is behind the address, or that all its traffic is tunnelled | The address stops forwarding for that operator, or the prefix is reassigned |
| Registered allocation | The registry, or the holder of the allocation | That the resource is used as a VPN exit, or which application uses it | The allocation is returned, transferred, or the holder changes |
| Tunnel entry | The operator that terminates the tunnel | That traffic exits from the same address, or that the client is a subscriber | The endpoint is decommissioned or its address changes |
एक होस्टिंग ब्लॉक में VPN एग्ज़िट और असंबंधित कार्यभार साथ-साथ हो सकते हैं, इसलिए रजिस्टर का मिलान यह नहीं बताता कि कोई दिया गया पता किसी दिए गए क्षण में क्या करता है। जो प्रविष्टि अपनी भूमिका नहीं बताती वह किसी विशेष चीज़ का प्रमाण नहीं है। भूमिका का नाम देना ही रिकॉर्ड को खंडनीय बनाता है। पता परिवार भी बताएँ, क्योंकि जो रजिस्टर चुपचाप केवल IPv4 को कवर करता है वह उल्टा मानने वाले हर व्यक्ति को भ्रमित करेगा।
एक प्रविष्टि को प्रकाशन से वापसी तक ट्रैक करें
एक काल्पनिक एग्ज़िट लें और उसका अनुसरण करें। एक ऑपरेटर घोषित प्रभावी समय पर प्रीफ़िक्स और अपनी भूमिका प्रकाशित करता है, उपभोक्ता उसे प्राप्त करते हैं, और बाद में पता एग्ज़िट के रूप में सेवा देना बंद कर देता है। हर चरण को एक नियम चाहिए: कौन प्रकाशित कर सकता है, प्रीफ़िक्स वास्तव में क्या कवर करता है, प्रविष्टि कब प्रभावी होती है, और उसे कैसे वापस लिया जाता है। वापसी मार्ग के बिना एक फ़ीड पुराने दावे जमा करता है जिन्हें कोई वर्तमान दावों से अलग नहीं कर सकता।
प्रकाशन के अधिकार को लेबल की सटीकता से अलग करें। किसी संगठन को संसाधन से जोड़ने वाला रजिस्टर रिकॉर्ड आवंटन साबित करता है, वर्तमान उपयोग नहीं, और ये अलग साक्ष्यों वाले अलग दावे हैं। उपभोक्ताओं को जानना चाहिए कि वे दोनों में से किस पर भरोसा कर रहे हैं।
सुधार को भी परिभाषित करें। ग्राहक को फिर से आवंटित पता, या गलत लेबल से पकड़ी गई असंबंधित सेवा, टिकट कतार में बहस के बजाय समाधान तक एक प्रलेखित मार्ग माँगती है। वापसी ट्रिगर प्रकाशन नियम वाले उसी दस्तावेज़ में होना चाहिए।
प्रकाशित फ़ीड क्या समर्थन कर सकता है और क्या नहीं
प्रकाशित प्रीफ़िक्स विशेषताएँ एक स्थापित पैटर्न हैं, और मौजूदा उदाहरण व्यवहार के बजाय भूगोल या स्वामित्व का वर्णन करते हैं। VPN फ़ीड को अपना अर्थ-विज्ञान, अपने साक्ष्य नियम और अपनी समीक्षा प्रक्रिया चाहिए होगी, और किसी देश की सूची का नाम बदलने से इनमें से कुछ भी नहीं मिलता। ARIN रजिस्ट्री गाइड दिखाता है कि आवंटन रिकॉर्ड क्या दावा करते हैं और क्या नहीं, और नए फ़ीड को अपने स्वयं के दावों के बारे में वही स्पष्टता अर्जित करनी होगी। यह विनिर्देश का कार्य है, पुनः-लेबल का कार्य नहीं।
ऐसा फ़ीड जिसका समर्थन कर सकता है वह नेटवर्क स्रोत के बारे में वर्गीकरण निर्णय है। जो वह नहीं कर सकता वह है साझा पते के पीछे के व्यक्ति की पहचान करना, यह साबित करना कि उस पते से सारा ट्रैफ़िक सुरंग से जाता है, या यह तय करना कि कोई विशेष अनुरोध दुरुपयोग है या नहीं। ये तीन अलग प्रश्न हैं, तीन अलग साक्ष्य आवश्यकताओं के साथ।
कानूनी प्रश्न को विनिर्देश के बाहर रखें
एक तकनीकी विनिर्देश यह तय नहीं कर सकता कि प्रस्तावित पंजीकरण आवश्यकता वैध, आनुपातिक या बुद्धिमान है या नहीं। उस मूल्यांकन के लिए वास्तविक विधायी पाठ, प्रभावित अधिकार, अधिकारक्षेत्र और एक कानूनी विश्लेषण चाहिए जो कोई डेटा प्रारूप प्रदान नहीं कर सकता। एक प्रारूप अच्छी तरह से डिज़ाइन किया जा सकता है और फिर भी खराब नीति का समर्थन कर सकता है।
विनिर्देश जो कर सकता है वह बहस को ठोस बनाना है। पहले प्रस्तावित डेटा, उसकी सीमाएँ और उसकी विफलता विधियाँ परिभाषित करें, ताकि नीति-बहस एक वास्तविक तंत्र पर हो, न कि ऐसी अपरिभाषित सूची पर जिसकी हर प्रतिभागी अलग कल्पना करता है। किसी कानूनी प्रश्न में एक तकनीकी दस्तावेज़ यही अधिकतम योगदान दे सकता है।