الخلاصة

  • أعلنت IESG في 28 أغسطس انتهاء مجموعة Security Dispatch وإغلاق قائمتها البريدية وانتقال وظيفتها إلى DISPATCH يغطي ART وSEC والجوانب غير الخاصة بالنقل في WIT.
  • يحتاج الانتقال إلى سجل على مستوى المقترح يربط النسخة والنقاش القديم ونص النتيجة وحالة التوافق ونوع السلطة والوجهة وشروط العودة، من دون تحويل مشورة التوجيه إلى اعتماد لمعيار.

انتقل المدخل ولم يُغلق مجال الأمن

يسمي إعلان الإنهاء Christopher Inacio وDeb Cooley بوصفهما جهتي اتصال في IESG، ويؤكد استمرار تشجيع الأفكار الجديدة في مجال الأمن. المنتهي هو المجموعة المستقلة وقائمتها، لا إمكانية تقديم عمل أمني جديد.

للجهة المستقبلة أساس معتمد. ففي 2 يوليو أقرت IESG ميثاق DISPATCH الحالي، وأصبح يشمل مقترحات ART وSEC وما لا يتعلق ببروتوكولات النقل من WIT. وقبل إعلان الإغلاق، عُقد اجتماع مؤقت مشترك في 30 يونيو، ثم ظهرت جلسة DISPATCH موحدة في IETF 126.

قد يكون الدمج مفيداً. فالمقترح المتصل بالهوية أو البريد أو تطبيقات الويب يمكن أن يعبر حدود عدة مجالات قبل أن يتضح موضعه. وجود مدخل واحد يقلل كلفة معرفة الهيكل الداخلي مسبقاً، ويساعد على اكتشاف التداخل مبكراً.

لكن DISPATCH لا يعتمد معياراً. يتيح ميثاقه توجيه العمل إلى مجموعة قائمة، أو اقتراح BoF، أو إعداد ميثاق لمجموعة جديدة، أو اقتراح مسار برعاية Area Director، أو إنشاء قائمة للنقاش، أو التأجيل أو الرفض. هذه المشورة غير ملزمة. وإذا تعذر على الرؤساء تحديد توافق، فليس إصدار نتيجة مضموناً. وباستثناء وثائق إدارية ضيقة بموافقة مديري المجالات المعنيين، لا تنجز المجموعة الوثائق التقنية.

ستة بنود لا تساوي حالة واحدة

شارك نحو خمسين شخصاً في الاجتماع المشترك يوم 30 يونيو. وبعده نشر الرؤساء ست نتائج وطلبوا الاعتراض إن كانت قراءة التوافق التقريبي غير صحيحة.

في بند، فكر مقدم المقترح في مسار Independent Submission Editor، وسجلت الرسالة صراحة أن ذلك احتمال لا إجراء من Dispatch. ولم يُعرض بندان. ولم ترَ IETF إجراء في بند ثالث. وفي بند آخر لم يكن هناك إجراء في ذلك الوقت، مع حاجة إلى مزيد من المهتمين بالتنفيذ المتبادل ومكان للنقاش. ووُجّه بند خامس نحو BoF المسمى DAWN والعمل التنظيمي المحيط به.

عدم العرض ليس رفضاً تقنياً. و«لا إجراء الآن» ليست حظراً دائماً. والتوجيه إلى BoF لا ينشئ مجموعة عمل ولا يعتمد نصاً. إذا اختُصرت هذه الحالات بعد الدمج في عبارة «عالجتها المجموعة القديمة»، فقد تتحول النصيحة في الذاكرة إلى سلطة لم تكن موجودة.

يوضح RFC 7957 أن مجموعة من نمط DISPATCH تقيّم العمل الجديد وتجد له مكاناً، لكنها لا تكمله. ويمكنها توثيق سبب عدم متابعة عمل ما. أما الحالات الحدية فيختار مكانها مديرو المجالات والرؤساء المسؤولون. ويبين RFC 2418 أن Area Director يستطيع، بعد التشاور مع المجموعة، إعادة صياغة ميثاقها أو تغيير رئاستها أو حلها حين تتغير المهمة أو الافتراضات، مع بقاء طريق الاستئناف إلى IESG.

المطلوب نقل الحالة لا منح حق جديد

ظل أرشيف SECDISPATCH العام متاحاً عند حد البحث، وكان يعرض 1,699 رسالة. لا يضمن ذلك البقاء الدائم، ولا يثبت ضياع أي مقترح. الفجوة هي عدم وجود جسر ظاهر بين السجل القديم والحالة الحالية.

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

لا يعطي هذا السجل حقاً في وقت الاجتماع ولا يفرض إعادة النظر. غرضه أن تبقى خلاصة الرؤساء، والتوافق التقريبي للمجموعة، وقرار Area Director، وخيار مقدم المقترح أفعالاً منفصلة.

مرجع إجرائي برقم غير صحيح

يقول إعلان الإغلاق إن الأفكار ما زالت مرحباً بها «وفق RFC7975». لكن RFC 7975 يصف واجهة لإعادة توجيه الطلبات بين شبكات توزيع المحتوى. أما ميثاق DISPATCH المعتمد فيستشهد بـRFC 7957 الذي يشرح مجموعات نمط DISPATCH.

لا دليل على أن الخطأ الرقمي أبطل الدمج أو غيّر نتيجة. ومع ذلك يلزم تصحيح أو تنبيه، لأن إعلان الإنهاء سيصبح دليلاً طويل العمر من المدخل القديم إلى الإجراء الجديد.

لا تثبت المصادر تعطل مقترح بعينه، ولا اختفاء الأرشيف مستقبلاً، ولا إلزامية المشورة القديمة، ولا حقاً في جلسة جديدة. وعدم ظهور محضر لجلسة IETF 126 على السطح الذي فُحص لا يثبت غياب سجل آخر. سجل التسليم توصية من Daniel Kade وليس التزاماً معلناً من IETF.

المصادر