RFC 2860 يرسم حدود العمل التقني لـ IANA

الخلاصة

• سجّل RFC 2860 مذكرة مارس 2000 التي حصرت عمل IANA المقصود في الجوانب التقنية لمعلمات بروتوكولات IETF وIRTF. تحدد RFCs المعايير، ويوجه IESG الحالات الملتبسة، بينما يحسم IAB بعض النزاعات.
• تستثني المذكرة قضايا السياسة في تخصيص أسماء النطاقات وكتل عناوين IP، لكنها تبقي أنواعاً محددة من التخصيص التقني ضمن الإجراء. كما تتطلب سجلات عامة، وقناة للطلبات، وأسباباً تقنية مشروعة للرفض، ومسار استئناف، وإشعاراً مسبقاً مدته ستة أشهر للإنهاء المنفرد.

التحليل

يبدأ RFC 2860 بتعريف ما يعنيه اسم IANA داخل المذكرة: اسم تقليدي للفريق التقني الذي ينفذ وينشر تخصيصات معلمات بروتوكولات الإنترنت. ويذكر أن هذا الفريق أصبح جزءاً من ICANN. هذا التعريف مهم لأنه يمنع تحويل اسم تاريخي إلى مؤسسة واحدة ذات تفويض موحد في كل مجال. فالمذكرة تقصر غرضها على العمل التقني نيابة عن IETF وIRTF، وتقر بأن ICANN قد تقدم خدمات شبيهة لسجلات لم تنشئها هاتان الجهتان.

على هذا الأساس، تضع الفقرة 4.1 مصدر المعايير قبل الفعل التنفيذي. تُسند IANA معلمات البروتوكول وتسجلها وفق معايير وإجراءات تنص عليها RFCs، سواء كانت معايير مقترحة أو مسودات أو معايير إنترنت كاملة، أو ممارسات حالية جيدة، أو أي RFC آخر يطلب تخصيصاً. إذا غاب المعيار أو وقع التباس، تستمر الممارسة التقليدية ما لم يوجّه IESG بخلاف ذلك. وعند الشك أو النزاع التقني، تطلب IANA التوجيه التقني من IESG وتتّبعه؛ ويمكن لـ IESG تعيين خبير عند الحاجة. كما تتعهد الجهات بتطوير المعايير الناقصة مع الوقت، على أن تعتمدها IANA بعد توجيه IESG.

إذا نشأ النزاع بين IANA وIESG، تنقل الفقرة 4.2 المسألة إلى IAB، وتصف قراره بأنه نهائي بموجب المذكرة. أما طلبات التخصيص، فتتناولها الفقرة 4.5: يجب توفير وسيلة إلكترونية عامة للطلب، ثم تنفيذ التخصيص أو رفضه في الوقت المناسب بسبب عدم استيفاء متطلبات تقنية مطبقة. ولا يجوز الرفض إلا لأسباب تقنية مشروعة. إذا كان السجل قد أُنشئ بفعل من IETF، يستطيع صاحب الطلب الطعن أمام IESG ثم IAB. هذه خطوات مكتوبة للمراجعة، لا سجل لحالة بعينها ولا إحصاء لنتائج فعلية.

وتضيف الفقرة 4.4 واجباً عاماً بالنشر. يجب إتاحة بيانات كل تخصيص قائم، بما فيها معلومات الاتصال بالمستفيد، عبر الإنترنت مجاناً. ويُعد التخصيص المنشور في RFC بواسطة محرر RFC مستوفياً لهذا الشرط. يتيح ذلك للمطورين والمشغلين معرفة القيمة المسجلة والرجوع إلى أساسها المنشور. لكن السجل المرئي لا يثبت وحده أن طلباً آخر قُبل، ولا أن كل تنفيذ تشغيلي يطابقه.

تمنح المذكرة IANA طريقاً لإبلاغ متطلبات التشغيل إلى عملية وضع القواعد. تسمح الفقرة 4.6 بمقاعد اتصال بلا تصويت في اللجان المناسبة التي تحددها IETF، وبالمشاركة في نقاشات متطلبات تخصيص المعلمات. وتطلب الفقرة 4.7 مراجعة وثائق IETF في مرحلة Last Call ورفع ما يثير القلق إلى IESG. المشاركة هنا تتيح كشف مشكلات التنفيذ، لكنها لا تنقل إلى مشغل السجل سلطة وضع المعايير التي تربطها الوثيقة بـ RFCs وتوجيهات IESG.

ولا تدمج الفقرة 5 العمل البحثي في مسار واحد. فالمعلمات التي تتصل أساساً بـ IRTF تخضع للإجراءات نفسها مع استبدال IRTF وIRSG بـ IETF وIESG. وإذا لم يتضح إلى أي المجالين ينتمي معامل ما، يملك IAB سلطة تحديد ذلك. وهكذا يتوقف تحديد الجهة الإجرائية على تصنيف المعامل أولاً.

أما حدود السياسة، فتعرضها الفقرة 4.3 بدقة. قضايا السياسة المرتبطة بتخصيص أسماء النطاقات وكتل عناوين IP خارج نطاق المذكرة. لكن أسماء DNS العكسي، وكتل العناوين المتخصصة مثل multicast وanycast، والتخصيصات التجريبية تبقى خاضعة للقسم 4 إذا لم تُعد قضايا سياسة. وإذا منعت سياسة لدى ICANN الامتثال في هذه الحالات، فعلى ICANN إخطار IETF، التي يمكنها عندئذ استخدام حق الإنهاء الوارد في الفقرة 2. لذلك لا يصح القول إن كل عمل يتعلق بالنطاقات أو العناوين مستثنى.

نُشر RFC 2860 في يونيو 2000 بوصفه Informational، ويقول إنه لا يحدد معياراً للإنترنت. وهو يسجل مذكرة وُقعت بين IETF وICANN في 1 مارس وصادق عليها مجلس ICANN في 10 مارس. وكان بالإمكان تعديلها أو إنهاؤها بالاتفاق المتبادل، كما يجوز لأي طرف إنهاؤها بإشعار لا يقل عن ستة أشهر. هذه قابلية مكتوبة للتغيير، لا دليل على وقوع إنهاء.

في 2011، وصف RFC 6220 لاحقاً دور مشغلي سجلات معلمات بروتوكولات IETF، وأكد أن IETF تحتفظ بالمسؤولية عن إدارة تلك المعلمات رغم تفويض بعض القرارات التشغيلية. يفيد هذا النص في فهم دور المشغل كما عُرض لاحقاً، لكنه لا يثبت أن كل ترتيب في 2000 ظل ثابتاً، ولا يحسم الأسئلة التي استبعدتها الفقرة 4.3. ما يثبته RFC 2860 هو الإجراء المكتوب وحدوده؛ أما الامتثال الفعلي، ونتيجة أي طعن، والسلطة على قضايا السياسة المستثناة، فلا يثبتها هذا السجل وحده.

المصادر

المصدر الأولي هو RFC 2860, Memorandum of Understanding Concerning the Technical Work of the IANA، ولا سيما الأقسام 1–5. وللوصف اللاحق لمشغلي السجلات، راجع RFC 6220.