ملخص
- حالة أفضل الممارسات الحالية (BCP) هي نتيجة نشر محددة من IETF. تعكس إجماعاً تقريبياً، ومراجعة عامة، وموافقة IESG على ممارسة أو مبدأ أو وظيفة IETF. إنها أكثر من مجرد رأي مؤلف، ولكنها ليست معياراً للإنترنت، وليست أبداً استفتاءً عالمياً.
- كلمة "حالية" هي ادعاء قائم على الأدلة يظل عرضة للتنفيذ والنشر. يمكن تحديث BCP، أو أن تتكون من عدة RFCs، أو أن تكون محدودة بالطوبولوجيا، أو أن تصبح متقادمة بسبب التغييرات التشغيلية والمؤسسية. المؤشر الحالي وتقرير النشر أهم من تسمية معزولة على الصفحة الأولى.
- يجب على المتبنين الخارجيين تحديد الادعاء الدقيق الذي يتبنونه، والسكان المتأثرين، والأدلة على أهمية الممارسة، والبدائل، ومعالجة الإصدارات، وسلطتهم الخاصة. لا يجوز لهم تحويل الإجماع التقريبي لـ IETF إلى ادعاء بأن جميع المنفذين أو جميع مستخدمي الإنترنت قد وافقوا.
تم إنشاء BCP لتسمية الممارسة الموصى بها دون تسميتها معياراً
بدأت فئة أفضل الممارسات الحالية بحل مشكلة تصنيف. احتاجت IETF إلى طريقة لتوصية معلومات تقنية مفيدة لا تنتمي إلى سلم نضج البروتوكول. بعض الوثائق تعلقت بإرشادات تشغيلية. أخرى صاغت مبادئ، أو وصفت وظائف إدارية، أو سجلت كيف يجب أن تعمل IETF نفسها. تسميتها كلها كمعايير إنترنت كان سيصف المحتوى والتأثير بشكل خاطئ.
RFC 1818، المنشور في أغسطس 1995، أنشأ السلسلة الفرعية BCP. نصت على أن مسار المراجعة سيكون مشابهاً لمسار المعيار المقترح، بما في ذلك مراجعة IESG ودعوة IETF الأخيرة. بعد الموافقة، ستحمل الوثيقة موافقة IETF التقنية، لكنها لم تكن ولا يمكن أن تصبح معياراً رسمياً للإنترنت. هذه المذكرة أصبحت تاريخية الآن، لكن تمييزها الأساسي لا يزال مفيداً.
RFC 2026قدم الإطار الدائم في العام التالي. تصف BCPs كوسيلة لتوحيد الممارسات ونتائج التشاور الجماعي: بيانات المبادئ، والأساليب التشغيلية المفضلة، ووظائف IETF. اعترفت بأن الشبكات التي تديرها منظمات ذات أهداف مختلفة لا تزال بحاجة إلى إرشادات مشتركة. تختلف هذه الإرشادات عن مواصفات البروتوكول، حتى لو تطلب إنشاؤها بناء إجماع مماثل.
تحمل الفئة إذن رسالتين في وقت واحد. الموافقة مهمة. الوثيقة ليست مجرد مذكرة متداولة أو اقتراح بائع. لقد تعرضت لمسار مراجعة IETF وتمت الموافقة عليها كأفضل تفكير حالي للمجتمع. التصنيف مهم أيضاً. الوثيقة ليست معياراً للإنترنت لمجرد أنها تستخدم مصطلحات معيارية أو تؤثر على التبني.
يبدأ سوء التفسير عندما يتم إسقاط نصف. تجاهل BCP كنصيحة عابرة يتجاهل المراجعة والحكم التقني الجماعي. معاملته كأمر عالمي يتجاهل الفئة والنطاق والتبني وحدود الهيئة التي وصلت إلى الإجماع. يجب أن تحمل القراءة الأمينة كلا العبارتين معاً.
التسمية تحدد نتيجة مؤسسية، وليس هيئة ناخبة
تنص نصوص BCP الحديثة على أن BCP من مسار IETF يمثل إجماع مجتمع IETF، وقد خضع لمراجعة عامة، وتمت الموافقة عليه من قبل مجموعة توجيه هندسة الإنترنت (IESG). تحدد هذه العبارات المؤسسة والمراجعة والهيئة الموافقة. لا تقول إن كل منفذ أو مشغل أو حكومة أو بائع أو مستخدم قد وافق.
الفرق ليس تواضعاً دلالياً. إنه يحدد ما يمكن استنتاجه بشكل مشروع. يتصرف مشاركو IETF كأفراد في مجتمع تقني مفتوح. لا تقاس المشاركة بعدد السكان أو الولاية القضائية أو الحصة السوقية أو حجم الشبكة أو عدد الأشخاص المتأثرين بالبروتوكول. ترسل المنظمات مشاركين مطلعين وتمول عملاً مكثفاً، لكنها لا تدلي بأصوات مؤسسية. نادراً ما يظهر المستخدمون النهائيون بأعداد تتناسب مع اعتمادهم على الإنترنت.
يمكن أن تكون نتيجة BCP موثوقة ضمن هذا النموذج. الأرشفة المفتوحة، والمعالجة المنطقية للاعتراضات، والكفاءة التقنية، والمراجعة المتمرسة يمكن أن تنتج توصيات جديرة بالثقة دون انتخابات تمثيلية. يتم تحديد العديد من الأسئلة التقنية بشكل سيء عن طريق عدد السكان الوطنيين أو مستخدمي المنتج. لا يتعلق الأمر بشرعية IETF، بل بنوع الشرعية التي تمتلكها.
شرعيتها تكون في أقوى حالاتها عندما يتعلق الادعاء بالسلوك التقني القابل للتشغيل البيني، أو تشغيل البروتوكول، أو آليات التسجيل ضمن مسؤوليتها، أو إجراءاتها الخاصة. تصبح أكثر احتمالية عندما توزع التوصية التكاليف بين الأطراف، أو تفترض هيكل سوق معين، أو تستخدم لتبرير عواقب قانونية خارج ولاية IETF. نفس الوثيقة يمكن أن تكون مقنعة تقنياً وغير مكتملة سياسياً لاستخدام خارجي معين.
لذلك يجب أن يؤخذ تعبير "إجماع IETF" حرفياً. إنه يخبرنا من وصل إلى الاستنتاج وبأي نوع من التشاور. إنه ليس اختصاراً لموافقة الإنترنت. توفر القائمة البريدية المتاحة للجمهور فرصة للمشاركة للخارجيين؛ إنها لا تثبت أن كل فئة متأثرة كان لديها المعرفة أو الموارد أو الخبرة أو الوصول اللغوي أو سبب للتوقع من الاستخدام المقصود.
هذا التفسير المحدود يقوي التسمية. إنه يجعل ادعاءً معقولاً حول مؤسسة حقيقية، بدلاً من ادعاء مستحيل حول مليارات الأشخاص.
الإجماع التقريبي مصمم لتجنب كل من حق النقض والعد الرأسي
تعتمد حالة BCP على الإجماع التقريبي وليس الإجماع الكامل.RFC 7282تشرح الطريقة كاهتمام بالمشاكل، وليس كمجرد جمع للأصوات الداعمة. يجب فهم الاعتراض التقني الموضوعي ومعالجته. ليس من الضروري أخذه في الاعتبار إذا خلصت المجموعة إلى أن القلق قد تمت الإجابة عليه أو أن العمل لا يستحق المتابعة.
هذا يسمح بالتقدم دون منح حق النقض لمعارض عنيد. كما يمنع أغلبية كبيرة من الفوز فقط بسبب حجمها. يمكن لعدد صغير من المشاركين تحديد خطأ ينقض التصميم المفضل. يمكن لعدد كبير دعم اقتراح دون الإجابة على ذلك الخطأ. مهمة الرئيس هي الحكم على المشكلات غير المحلولة والدعم الكافي، وليس تأكيد الموافقة بالإجماع.
الطريقة مناسبة بشكل خاص للهندسة. خطأ في قابلية التشغيل البيني لا يصبح غير ضار لأن معظم الناس يؤيدون الميزة. هجوم قابل للتكرار لا يختفي برفع الأيدي. بالعكس، تفضيل بناء جملة مختلف لا يمنع تصميماً سليماً إلى أجل غير مسمى. النقاش والتنفيذ والأدلة يمكن أن تفرق بين مشكلة حاسمة وذوق.
لكن الإجماع التقريبي لا يمكن ترجمته إلى موافقة عالمية دون تدمير معناه. إنه يسمح صراحةً بالخلاف. إنه لا يحصي جميع المتأثرين. إنه لا يعتبر المنفذين الغائبين داعمين. إنه لا يجعل الصمت تنازلاً إيجابياً عن الحقوق. إنه لا يثبت أن الأطراف خارج IETF قبلت التكاليف التي تم فرضها لاحقاً باسم الوثيقة.
حتى داخل المجموعة النشطة، الإجماع ليس موافقة شخصية على كل جملة. قد يقبل المشاركون نتيجة يرونها أقل جاذبية لأن الاعتراضات تمت الإجابة عليها بشكل كافٍ. القرار المؤسسي أقوى من استطلاع الرأي، لكنه أضيق من ادعاء التفضيل المشترك.
يجب على الهيئات الخارجية الحفاظ على هذه الدقة. يمكنهم القول إن BCP يعكس إجماع IETF التقريبي الذي تمت مراجعته. لا ينبغي لهم القول إن "الإنترنت العالمي وافق" أو "الصناعة وافقت" إلا إذا كان لديهم أدلة منفصلة حول هؤلاء السكان. هذا التمييز هو أول دفاع ضد الاستيلاء على الإجماع، حيث يتم تقديم قرار تقني محدود في مكان آخر كولاية عالمية.