دفتر ثبت نشانی‌های خروجی 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 نشان می‌دهد که ثبت‌های تخصیص چه چیزی را ادعا می‌کنند و چه چیزی را نه، و خوراک تازه باید همان روشنی را درباره ادعاهای خودش به دست آورد. این کار مشخصات است، نه کار تغییر برچسب.
آنچه چنین خوراکی می‌تواند پشتیبانی کند تصمیمی درباره طبقه‌بندی یک منبع شبکه است. آنچه نمی‌تواند انجام دهد این است: شناسایی شخصی در پشت یک نشانی مشترک، اثبات اینکه همه ترافیک آن نشانی از تونل می‌گذرد، یا تصمیم‌گیری درباره اینکه درخواستی معین سوءاستفاده است یا نه. این‌ها سه پرسش جدا با سه الزام شواهد جدا هستند.
پرسش حقوقی را بیرون از مشخصات نگه دارید
یک مشخصات فنی نمی‌تواند روشن کند که آیا الزام ثبت پیشنهادی قانونی، متناسب یا خردمندانه است. آن ارزیابی به متن واقعی قانون‌گذاری، حقوق متأثر، صلاحیت قضایی و تحلیلی حقوقی نیاز دارد که قالب داده نمی‌تواند فراهم کند. یک قالب می‌تواند خوب طراحی شود و همچنان از سیاست بد پشتیبانی کند.
آنچه مشخصات می‌تواند انجام دهد این است که بحث را ملموس کند. نخست داده‌های پیشنهادی، محدودیت‌ها و شیوه‌های شکست آن را تعریف کنید، تا استدلال سیاستی درباره سازوکاری واقعی باشد نه فهرستی تعریف‌نشده که هر مشارکت‌کننده آن را متفاوت تصور می‌کند. این بیشترین سهمی است که یک سند فنی می‌تواند در یک پرسش حقوقی داشته باشد.