AFRINIC-29 | اجتماع السياسة العامة

AFRINIC-29 اجتماع السياسة العامة

محضر اجتماع PDWG المنعقد في 29 نوفمبر 2018

الحمامات ، تونس

 

ملف PDF 

 

الرؤساء المشاركون للجلسة: سامي صالح ، دول أجاو

 

جدول:

1. الترحيب وتقديم جدول الأعمال
2. و AFRINIC PDP
3. تقرير تجربة تنفيذ السياسة
4. تحديث تطوير السياسة من جهات أخرى RIRs
5. الاقتراح: AFRINIC Policy Development Process Bis v4
6. الاقتراح: تحديث بسيط لـ PDP
7. الاقتراح: إساءة تحديث سياسة الاتصال
8. الاقتراح: مراجعة موارد أرقام الإنترنت من قبل AFRINIC
9. اقتراح: توضيح بشأن IPv6 مهام فرعية
10. الاقتراح: -RIR تحويل الموارد
11. اقتراح: IPv4 لينة الهبوط BIS
12. الاقتراح: SL-Update
13. افتح سياسة الميكروفون

 

1. مرحبًا ، مقدمة ونظرة عامة على جدول الأعمال

قدم الجلسة إرنست بياروهانجا الذي رحب بالمندوبين في الاجتماع ، وقدم الرئيسين المشاركين (Dewole و Sami) وشكرهما على جهودهما وحث المندوبين على التعاون الكامل معهم. 

قدم سامي draft جدول الأعمال الذي تم اعتماده دون تغييرات.

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

 

2. و AFRINIC PDP

قدم سامي عملية تطوير سياسة AFRINIC ، وذكر أنها تستند إلى مبادئ النهج من القاعدة إلى القمة والانفتاح. يمكن لأي شخص نشر أي مقترح في قائمة سياسة rpd المفتوحة ومناقشتها لمدة 4 أسابيع على الأقل ، ثم يتم تقديمها في اجتماع السياسة العامة. ثم يتم إرسال الاقتراح إلى المكالمة الأخيرة إذا حصل على إجماع في اجتماع السياسة العامة (وإلا فإنه يعود إلى القائمة لمناقشة أخرى لمدة 4 أسابيع). في حالة عدم وجود مشكلات أثناء المكالمة الأخيرة ، يرسل الرؤساء المشاركون تقريرًا إلى المجلس يوصي بالتصديق ، ويصدق المجلس ويطلب من الموظفين التنفيذ ، بشرط اتباع العملية بشكل صحيح.

 

ردود الفعل والأسئلة الواردة:

• كيف يقوم الرؤساء المشاركون بإنفاذ مدونة قواعد السلوك؟ أوضح الرؤساء المشاركون أن هذه مسألة داخلية وفقًا لتقدير الرؤساء المشاركين في الوقت الحالي. 

• هل يصادق المجلس دائمًا على اقتراح عندما ينصح به الرؤساء المشاركون؟ متى يمكن لمجلس الإدارة الاعتراض / رفض السياسة أو مطالبة المجتمع بتقديم مدخلات إضافية؟ ذكر الرؤساء المشاركون أن المجلس يصدق فقط على أساس ما إذا كان الاقتراح قد اتبع العملية أم لا. وأضافوا أن الاقتراح يعود إلى القائمة إذا لم يصادق المجلس عليه.

• يبدو أن بعض المقترحات الواردة في جدول الأعمال تنتهك PDP ، بسبب الموعد النهائي للإرسال وهو أسبوع واحد قبل PDP. أوضح الرئيسان المشاركان أن الاقتراح المعني قُدم في الوقت المحدد ، ولكن لم يتم نشره (ولم يتم نشره في القائمة) في الوقت المحدد. واقترحوا أنه في المستقبل ، لن ينتظر الرؤساء المشاركون نشر موقع الويب لاقتراح مُستلم ، وسيقومون بإرساله إلى القائمة فور استلامه.

 

3. تقرير تجربة تنفيذ السياسة

قدم ذلك جيمس تشيروا ، كبير محللي الملكية الفكرية في AFRINIC. يسلط التقرير الضوء على جوانب السياسة الرئيسية (والثغرات) التي يمكن توضيح تنفيذها (الترجمة إلى التوزيع الفعلي لموارد الأرقام على الأعضاء أثناء معالجة الطلبات) بشكل أفضل حتى يتمكن الموظفون من فهم وتفسير تلك الجوانب بشكل أفضل وسد تلك الفجوات.

 

نقاط بارزة من التقرير:

• السياسات التي تم التصديق عليها مؤخرا هي كما يلي:
  • IPv6 تحديث السياسة والمراجع - الذي تم تنفيذه في 23 نوفمبر 2018 وهو نشط.
  • IPv6 تحديث التخصيص الأولي - تم تنفيذه أيضًا في 23 نوفمبر 2018 وهو نشط.
  • IPv6 تحديث PI - قيد التنفيذ ، وأتمتة معلقة لبعض متطلبات السياسة (أدوات للتحقق من ذلك IPv6 مساحة PI التي تم تخصيصها للأعضاء يتم توجيهها وليست مجزأة).
  • التفويضات العرجاء في AFRINIC العكسي DNS - تم تنفيذه (جزئيًا) في 28 سبتمبر 2018. لم يتم حذف السجلات العرجاء للنطاقات وخوادم الأسماء حتى الآن ، وجارٍ العمل على صفحة الإحصائيات. تدعم AFRINIC الأعضاء المعنيين لتصحيح هذه الوفود الضعيفة.
• التعارضات والغموض في دليل السياسات:
  • تنص CPM 5.4.6.1 على استخدام 90٪ من المساحة التي تم إصدارها قبل أن يتمكن العضو من الحصول على مساحة لاحقة ، وهو ما يتعارض مع 5.5.1.4.1 (استخدام 80٪) و 5.6.3 (معدلات استخدام 50٪ في سنة واحدة)
  • CPM 5.7.1 يسمح بدخولRIR تحويلات IPv4 لكن هناك بعض الأعضاء الذين يرغبون في النقل ASN و IPv6 بسبب عمليات الدمج ، على سبيل المثال.
  • CPM 7.4.2 على متطلبات التوجيه المتعدد لـ ASN ليتم إصدارها - ومع ذلك يحتاج بعض الأعضاء إلى ASN وتقوم بتشغيل BGP - ولكن مع مزود اتصال واحد.
  • CPM 5.2.1.2 - شرط أن يقوم LIR بتسجيل تعيينات عناوين IP لعملائه. تُظهر بعض هذه التخصيصات أسماء الشركات غير الدقيقة أو الصحيحة ، والتي تم إنشاؤها عن قصد أحيانًا بواسطة LIR لتزوير المعلومات.

في حالة حالات الغموض المذكورة أعلاه ، يتم حث المجتمع على النظر في CPM واقتراح تغييرات في السياسة لتصحيح هذه المشكلات.

تفاعل:

• أشار أحد الأعضاء إلى أنه سعيد بكتابة مقترحات السياسة لكل عنصر من العناصر المذكورة أعلاه ، لكنه شجع الأفراد الذين لم يؤلفوا سياسات من قبل على الخروج وكتابة سياسات لمعالجة هذه القضايا.
• واقترح أنه يمكن تشجيع أعضاء معينين في AFRINIC الذين أثاروا القضايا المذكورة أعلاه (والذين تأثروا بشكل مباشر) على اقتراح سياسات لمعالجة أوجه الغموض هذه.
• تم اقتراح أن يكتب الموظفون خطة تنفيذ سياسة عامة تحتوي على الطرق المختلفة التي ستؤثر بها السياسة على الأعضاء. يجب إعلان هذه الوثيقة للأعضاء عند الاستفادة منها. اقترح أحد المشاركين أن يكون هذا القسم جزءًا من تقرير تقييم الموظفين كمبدأ أولي draft.
• فيما يتعلق بمسألة النزاعات المختلفة في هيئة تدابير الصحة النباتية ، يمكن استخدام طريقة ARIN للإشارة إلى ما تم حذفه ، بحيث يمكن بسهولة معرفة عمليات الحذف أو رؤيتها علنًا.

 

4. تحديث تطوير السياسة من جهات أخرى RIRs

تم استلام التحديثات من الجهة المعنية ومشاركتها RIR الممثلين على النحو التالي:

أبنيك:

• تمت الموافقة على التحقق من صحة اقتراح سياسة صندوق البريد (على غرار ما سيتم مناقشته هنا) في apnic-46 وينتظر نظر المجلس التنفيذي.
• سياسة "لا حاجة" التي تهدف إلى إلغاء فحص تقييم الاحتياجات على جميع طلبات النقل في APNIC لم تمر عبر APNIC46
• توضيح على IPv6 تقدم التخصيصات الفرعية (المشابهة أيضًا لتلك الواردة في جدول أعمال هذا الاجتماع) عملية لا تسمح بتوفير مساحة v6 لأجهزة الطرف الثالث خارج البنية التحتية للشبكة الخاصة بصاحب مساحة PI. هذا لم يصل إلى إجماع في APNIC46.
• تحديث PDP - اقتراح يقوم بتحديث APNIC PDP ليشمل المشاركة عن بُعد نحو قرارات الإجماع ، وضبط الوقت المطلوب لتقديم اقتراح قبل اجتماع السياسة العامة ووضع آلية استئناف أبسط. لم تتوصل إلى إجماع في APNIC46

 

أرين:

• توضيح للتخصيص الأولي لـ ISP: يضبط IPv4 سياسة التخصيص الأولي للسماح للشركات بدون IPv4 مساحة للتأهل لـ / 24 تلقائيًا ، وأكبر إذا تم توضيح الحاجة.
• عدم السماح بإنشاء سجلات مؤسسة تابعة لجهة خارجية: يتطلب إنشاء سجلات المؤسسة بواسطة الكيان الذي يمثله سجل المؤسسة ، وفقط من خلال طلب صريح إلى ARIN.
• توضيح متطلبات إعادة التعيين في 4.2.3.7.1: يبسط متطلبات إعادة التعيين بحيث يكون اسم العميل فقط هو المطلوب وليس أي معلومات أخرى.

  

لاكنيك:

• في جملة RIR سياسة النقل. هذا ينشئ آلية للسماح بنقل الموارد (IPv4, IPv6, ASNق) بين المناطق المختلفة ولمواءمة LACNIC مع السوق الحالية التي لا تشارك فيها المنطقة حاليًا. الاقتراح مشابه للاقتراح المدرج في جدول أعمال AFRINIC29 ، ويسمح فقط بالإرث IPv4 مساحة ليتم نقلها خارج LACNIC
• سياسة الاستخدام المقبول لقائمة السياسة البريدية: يقترح سياسة الاستخدام المقبول (AUP) لقائمة السياسة ، حيث لا يوجد مثل هذا المستند حاليًا في LACNIC. تم اقتراحه نتيجة للعديد من الأنشطة المزعجة التي تتعارض مع هدف وروح قائمة سياسة LACNIC ، بما في ذلك حالات إساءة الاستخدام والهجمات الشخصية المختلفة والدعاية الانتخابية التي شوهدت عدة مرات في قائمة سياسة LACNIC.
• مراجعة طفيفة لـ PDP: تصحيح عيب في LACNIC PDP حيث إذا لم يتوصل اقتراح السياسة إلى إجماع والتعليقات التي يتلقاها لا تكفي لإظهار المؤلف "طريقة للمضي قدمًا" كما هو مكتوب ، فإن النص الحالي سيجبر المؤلفين لتقديم نسخة جديدة "بشكل مصطنع" من أجل إبقاء الاقتراح الأصلي قيد المناقشة.
• توضيح على IPv6 المهام الفرعية - المشابهة أيضًا لتلك الموجودة في جدول الأعمال لهذا الاجتماع) تقدم عملية لا تسمح بتوفير IPv6 مساحة PI لأجهزة الطرف الثالث خارج البنية التحتية للشبكة لحامل مساحة PI.
• تسجيل والتحقق من سوء استخدام البريد الإلكتروني وإساءة الاستخدام: لأنه ليس من الواضح ما إذا كان يمكن إرفاق معلومات جهة اتصال إساءة الاستخدام ببعض بيانات الموارد في LACNIC whois ديسيبل. ليس من الواضح ما إذا كان يمكن إرفاق معلومات جهة اتصال إساءة الاستخدام ببعض بيانات الموارد في LACNIC whois ديسيبل.
• يهدف هذا الاقتراح إلى حل المشكلة من خلال التأكد من وجود جهة اتصال مناسبة لسوء المعاملة وعملية لاستخدامها ، ويهدف هذا الاقتراح إلى حل المشكلة من خلال ضمان وجود جهة اتصال مناسبة لإساءة الاستخدام ووضع عملية لـ استخدامه.

  

ناضج: 

• التحقق من إساءة الاستخدام المنتظم: يمنح RIPE NCC التفويض للتحقق سنويًا من عناوين البريد الإلكتروني المسيئة والمتابعة عندما تكون غير صالحة. تمت الموافقة على الاقتراح في اجتماع RIPE الأخير.
• توضيحات LIR المنظمة في IPv6 السياسة: توضح تخصيصات LIR لكل حساب LIR - السياسة القديمة المستخدمة لتوضيح أن ملف IPv6 يُعطى التخصيص لمنظمة ، ولم يوضح نوع المنظمة. هذا أيضا تم تنفيذه بالفعل.
• تحديد المعلومات التي عفا عليها الزمن في IPv4 السياسة: هذا الاقتراح يزيل بعض المراجع القديمة في ذات الصلة IPv4 سياسات./
• توضيح PDP: يوضح الإجراءات التي يمكن أن تحدث في "مرحلة المراجعة" ، والتي لم تكن واضحة تمامًا.
• توضيح المهام في IPv6 التخصيصات - تهدف إلى توضيح تعريف "التنازل" في IPv6 .
• نشر العنوان القانوني لأصحاب الموارد في قاعدة بيانات RIPE: الهدف هو نشر معلومات العنوان القانونية والمعتمدة لأصحاب الموارد في منطقة RIPE. طُلب من المؤلف إبداء بعض الإيضاحات.
• تنظيف كائن المسار غير المعتمد لقاعدة بيانات RIPE NCC IRR: الهدف هو حذف كائنات المسار غير المعتمدة المخزنة في سجل توجيه RIPE إذا كان يتعارض مع RPKI ROA. 

 

5. الاقتراح: AFRINIC عملية وضع السياسات مكرر v4

تم تقديم الاقتراح من قبل المؤلفين ، الذين شاركوا النقاط التالية:

• يبلغ عمر PDP الحالي 10 سنوات ، وبدأ المؤلفون عملية تعديله في أبريل 2017 ، الآن في الإصدار 4.
• كانت التعليقات الواردة من الاجتماع الأخير لإزالة إخفاء هوية مؤلفي المقترحات ، وإزالة إمكانية أن يصبح الرؤساء المشاركون في السياسة محرري للوثائق ، وإزالة التضمين لمجلس الحكماء ، والسماح للرؤساء المشاركين بحوالي أسبوعين للإعلان عن توافق الآراء (بعد التبني) المرحلة) وبعد اجتماع السياسة العامة.
• تم تحديث الاقتراح ليشمل جميع ملاحظات المجتمع أعلاه.
• لم تكن هناك مناقشات جوهرية حول الاقتراح المحدث ، ولا توجد اقتراحات أو مدخلات من المجتمع (بما في ذلك النص الذي وعد به بعض الأعضاء).
• ومع ذلك ، تم تلقي اقتراح منافس جديد بدلاً من ذلك (تحديث بسيط PDP).
• طلب المؤلفون من الرؤساء المشاركين طريقة للمضي قدمًا.

وردت ردود الفعل على النحو التالي:

• أشار الرؤساء المشاركون إلى أنه ينبغي النظر في المقترحات في مصلحة المجتمع وليس الأشخاص الذين قاموا بتأليف هذه المقترحات.
• دعا الرؤساء المشاركون مؤلف الاقتراح "التحديث البسيط لـ PDP" إلى تقديمه أيضًا ، بحيث يمكن إجراء المناقشات حول مزايا كلاهما بعد تقديمهما ، مما يسمح للمجتمع بالمناقشة بموضوعية والرؤساء المشاركين لاتخاذ أفضل القرار بعد ذلك.

 

6. الاقتراح: تحديث بسيط لـ PDP

شارك المؤلف النقاط البارزة التالية من هذا الاقتراح:

• بينما يمكن لأي شخص المشاركة في مناقشات السياسة إما في القائمة البريدية (RPD) و / أو في اجتماعات السياسة العامة نصف السنوية ، لا يستطيع جميع المشاركين في RPD حضور جميع الاجتماعات الفعلية وجهًا لوجه حيث يقرر الرؤساء إجماعًا تقريبيًا على المقترحات - وهذا هو الجزء الأكبر من المجتمع. مع هذا المطلب لاتخاذ قرارات بالإجماع في الاجتماعات وجهًا لوجه ، قد يكون هذا جزئيًا سبب انخفاض مستويات مشاركة المجتمع في عملية السياسة.
• يبسط هذا الاقتراح العملية من خلال عدم طلب المشاركة الشخصية في اجتماعات السياسة العامة للحصول على اقتراح لتحقيق الإجماع - بدلاً من ذلك ، سيتم تحديد الإجماع لتحقيق التوازن بين المساهمات من القائمة البريدية والاجتماع - مما يؤدي بالتالي إلى زيادة مشاركة المجتمع.
• يتم أيضًا تكييف الجداول الزمنية المختلفة لهذا التغيير ، مع بعض السيناريوهات على النحو التالي
  • يتم تقديم اقتراح (أو إصدار جديد) لمدة 8 أسابيع (أو فترة أطول) قبل الاجتماع التحضيري للمؤتمر. سيتم تحديد الإجماع من قبل الكراسي خلال أسبوعين كحد أقصى.
  • يتم تقديم اقتراح (أو نسخة جديدة) قبل أقل من 8 أسابيع من اجتماع مجلس الإدارة. سيتم تحديد توافق الآراء من قبل الرؤساء في غضون أسبوعين كحد أقصى ، بمجرد انتهاء 8 أسابيع من وقت المناقشة في القائمة.
  • يتم تكييف توقيت الدقائق أيضًا ، حيث يبدو من غير الضروري الانتظار لمدة 3 أسابيع ، إذا كان سيتم تحديد الإجماع في غضون أسبوعين.
• ولذلك ، فإن الاقتراح يلغي الشرط الذي يقضي بوجوب التوصل إلى توافق في الآراء فقط في الاجتماع. وهي تتكيف مع التوقيتات ذات الصلة وفي نفس الوقت توضح تعريف "الإجماع" و "النداء الأخير".
• تم تكييف تعريف الإجماع ليتماشى مع مفهوم الإجماع التقريبي لـ IETF.
• تم اقتراح تغييرات مختلفة على الجداول الزمنية ، بما في ذلك حقيقة أن الرؤساء المشاركين يعلنون فقط عن تغييرات على قرارات إجماع سابقة في غضون أسبوع واحد بعد فترة المكالمة الأخيرة.
• أشار المؤلف إلى أن اقتراحًا مشابهًا تم التوصل إليه في منطقة LACNIC في مايو 2018 وتم تنفيذه بالفعل.

ردود الفعل الواردة:

• أشار مؤلف الاقتراح "PDP-bis" إلى أن هناك العديد من أوجه التشابه بين الاقتراحين ، مثل تقييم الموظفين وعملية الإجماع التقريبي (حيث لا يتعلق الأمر فقط بالتعريف). أشار مؤلف "تحديث PDP البسيط" إلى أن مقترح PDP-bis معقد ، نظرًا للعديد من (خمس) مراحل مختلفة ، وأنه يحتاج إلى التبسيط.
• ولوحظ أن المقترحات في AFRINIC لا ينبغي تشبيهها بتلك الموجودة في منطقة LACNIC ومناطق أخرى.
• قال مؤلف هذا الاقتراح إنه قرأ اقتراح PDP-bis بعناية ووجد 15 نقطة ضعف جدًا والعديد من المشكلات المفقودة التي أشار إليها المؤلفون وهو على استعداد لتوضيح هذه الأمور إذا كان كلا الجانبين منفتحين للمناقشة.
• أشار الرئيسان المشاركان إلى عدم وجود سجل رسمي بالمسائل المذكورة أعلاه في القائمة البريدية.
• لاحظ العديد من الأفراد أن هناك العديد من النقاط في كل من مقترحات السياسة البناءة للغاية وبالتالي يجب على المؤلفين من الجانبين العمل معًا للتوصل إلى نسخة واحدة من الاقتراح تم تحسينها كثيرًا.
• أشار عدد قليل من الأفراد إلى أن PDP الحالي ليس لديه أي مشاكل كبيرة تحتاج إلى إصلاح ، بدلاً من ذلك ، يبحث العديد من الأفراد عن طرق للتعامل مع العملية من أجل المصالح الشخصية - ويمكن أن تظل هذه المشكلة بغض النظر.
• حث بعض الأعضاء الرؤساء المشاركين على الامتناع عن قبول مثل هذه المقترحات المتنافسة ، ولكن أشار الرؤساء المشاركون إلى أنه ليس لديهم مثل هذا التفويض وفقًا لـ PDP ، ولكن يمكنهم تشجيع الأطراف على العمل معًا.
• كما ذكرنا سابقًا ، على الرغم من أن العملية تسمح بظهور العديد من المقترحات المتنافسة على الطاولة ، يجب استخدام النوايا الحسنة بحيث لا ينتهي بنا الأمر في مثل هذا الموقف. أشار مؤلف "Simple PDP Update" إلى أنه ليس بالضرورة فكرة سيئة أن يكون لديك مقترحات منافسة لأنها تتيح للمجتمع دراسة وجهات نظر مختلفة.
• يفضل أحد الاقتراحات المشاركين عن بُعد ، وهذا أمر جيد لأن العديد من الأشخاص لا يمكنهم السفر بسبب ضيق الوقت والقيود المالية.

نصح الرؤساء المشاركون أن مؤلفي الاقتراحين المتنافسين يفكرون في العمل معًا للتوصل إلى اقتراح موحد يجمع بين نقطتين قويتين من كلا الاقتراحين ، لصالح المجتمع الذي يمتلك PDP أوسع نطاقًا ومحسّنًا.

قرر مؤلف "التحديث البسيط لـ PDP" سحب اقتراح سياسته وأشار إلى أن لديه توقعات قوية بأنه سيعمل مع مؤلفي اقتراح السياسة "AFRINIC PDP-bis"في هذا الجهد لتحسين PDP.

حث مؤلفو "AFRINIC PDP-bis" على أنه في محاولة للعمل معًا ، يجب أن يكون هناك احترام متبادل ، حيث سيشمل ذلك دمج الآراء القوية من طرفين منفصلين.

قرر الرؤساء المشاركون إعادة اقتراح AFRINIC PDP-bis إلى القائمة والبدء في عملية إشراك الطرفين للعمل نحو نسخة محسنة تأخذ النقاط من الاقتراحين بعين الاعتبار.

 

7. الاقتراح: إساءة تحديث سياسة الاتصال

شارك المؤلف النقاط البارزة التالية من الاقتراح:

• لا تجعل CPM 8.0 الحالية (مواصفات معلومات الاتصال المسيئة) إلزاميًا تسجيل جهة اتصال مسيئة. نتيجة لذلك ، قد لا يكون لدى العديد من الأعضاء معلومات الاتصال هذه الخاصة بهم المسجلين والمحدثة لمواردهم.
• قد تكون هناك حالات يستخدم فيها الأعضاء عناوين بريد إلكتروني غير موجودة أو عنوان لا تتم مراقبته بشكل نشط ، مما يجعل من الصعب الإبلاغ عن إساءة استخدام من هذه الشبكات ويؤدي بشكل عام إلى مشاكل أمنية وحتى تكاليف للضحايا.
• يهدف هذا الاقتراح إلى حل هذه المشكلة من خلال ضمان وجود جهة اتصال مناسبة لإساءة الاستخدام لكل مورد تم إصداره وأيضًا عملية للحفاظ على دقة هذه المعلومات. تم اقتراح السياسة على الإطلاق RIRطريقة موحدة عالميًا للإبلاغ عن إساءة الاستخدام بين المناطق.
• تشير السياسة الحالية في CPM 8.0 إلى "ورقة أفضل الممارسات" ، وهي ليست إلزامية ولا يبدو أنها مستخدمة من قبل المجتمع.
• تقترح ورقة أفضل الممارسات كائن IRT ، ويوصي هذا الاقتراح بربط الإساءة المقترحة- c و IRT في BCP تلقائيًا. بهذه الطريقة ، سوف تتماشى عمليات الاتصال مع إساءة استخدام AFRINIC مع عمليات أخرى RIRس. يستخدم APNIC الآن IRT ، ولكن نظرًا لأنه تم قبول اقتراح مكافئ ، سيتم إنشاء "ارتباط" آلي مع IRT الحالي ، لذا سيظل إساءة استخدام صندوق البريد وإساءة الاستخدام سائدين.
• ليست هناك حاجة لحذف البيانات الاختيارية الأخرى المدرجة اليوم في IRT. تضمن هذه السياسة فقط أن صندوق البريد المسيء متاح ويتم التحقق منه بشكل دوري.
• على الرغم من أن مجتمع الإنترنت يعتمد على التعاون ، إلا أن هذا في كثير من الحالات ليس كافيًا ونحتاج جميعًا إلى أن نكون قادرين على الاتصال بمزودي خدمة الإنترنت الذين قد يواجهون مشكلة في شبكاتهم وغير مدركين للموقف.
• ينشئ هذا الاقتراح قسمًا جديدًا في دليل السياسة لحل هذه المشكلة عن طريق التحقق الدوري البسيط ، ويضع القواعد الأساسية لإجراء هذا التحقق وبالتالي يتجنب التكاليف غير الضرورية للأطراف الثالثة التي تحتاج إلى الاتصال بالأشخاص المسؤولين عن حل انتهاكات شبكة محددة.
• يضمن الاقتراح أن تكلفة معالجة الإيذاء تقع على عاتق LIR الذي يتسبب عميله في الإساءة (ومن يتلقون منه تعويضًا ماليًا عن الخدمة) ، بدلاً من السقوط على الضحية ، كما هو الحال إذا اضطروا إلى اللجوء إلى المحاكم ، وبالتالي تجنب التكاليف (المحامون والمحامون ، وما إلى ذلك) وتوفير الوقت لكلا الطرفين.
• لهذا ، تصبح سمة abuse-c إلزامية في كائنات "aut-num" و "inetnum" و "inet6num" ، وكذلك في أي أشياء أخرى يمكن استخدامها في المستقبل. هذه السمة هي جهة اتصال لإساءة الاستخدام ، ويجب أن تحتوي على الأقل على سمة "صندوق البريد - الإساءة".
• من المتوقع أن يتم تنفيذ الاقتراح من قبل AFRINIC في غضون إطار زمني معقول يسمح لكل من الموظفين بتطوير البرامج اللازمة والأعضاء لتحديث جهات الاتصال الخاصة بهم.
• أشار المؤلف إلى أنه على الرغم من أن AFRINIC قد اقترحت إزالة التفاصيل التشغيلية وعمليات التحقق المعقدة من الاقتراح ، فمن المهم أن تظل كما هي وظيفة أساسية في عمليات التحقق من البريد الإلكتروني المسيئة.
• تم قبول اقتراح مماثل في APNIC (قيد التنفيذ) وهو قيد المناقشة في منطقتي LACNIC و RIPE.

كانت ردود الفعل من المجتمع كما يلي:

• التحقق من معلومات الاتصال مهم من سياق وعمل فرق الاستجابة للطوارئ.
• ماذا يحدث عندما لا يستجيب الأعضاء لطلبات التحقق من AFRINIC؟ صرح المؤلف أن AFRINIC سيمنع الوصول إلى MyAFRINIC كما هو مبين في نص الاقتراح.
• وأوضح المؤلف أن ما تم حظره هو الوصول إليه MyAFRINIC، وليس استخدام الموارد عن طريق إبطالها أو استعادتها. ومع ذلك ، فإن الاستصلاح جزء من الاتفاقية المبرمة بين العضو و AFRINIC.
• يشير النص في الاقتراح إلى "حظر وصول الحساب إلى الموارد" والذي يمكن أن يساء تفسيره على أنه إبطال للموارد ". أوضح المؤلف مرة أخرى أن هذا هو الوصول إلى MyAFRINIC.
• كان هناك دعم لفكرة التحقق من عناوين البريد الإلكتروني.
• لوحظ أنه من الأسهل الحفاظ على كائن أو سمة جهة اتصال إساءة استخدام واحدة.
• ولوحظ أيضًا أنه أثناء التحقق ، يجب ألا تتخذ AFRINIC إجراءات عقابية ضد الأعضاء الذين لا يستجيبون لعمليات التحقق ، حيث إنها ليست شرطة الإنترنت. يمكن لـ AFRINIC فقط وضع علامة على أولئك الذين لا يستجيبون ، وجعل القائمة علنية لمجتمع المشغلين ليقرروا ما يجب فعله ، مثل عدم التناظر.
• حظر الوصول إلى MyAFRINIC تم دعمه ، ولكن كان هناك اقتراح للسماح بتسجيل الدخول ، ولكن لديك رسالة بعد تسجيل الدخول للإشارة إلى أنه يجب على العضو أولاً تحديث / التحقق من معلومات الاتصال التي تسيء استخدامها قبل أن يتم الوصول إلى أي وظيفة أخرى.
• كان هناك قلق بشأن معدلات الاستجابة العامة من الأعضاء عندما حاولت AFRINIC حث الأعضاء على تحديث جهات الاتصال غير الدقيقة الخاصة بهم. صرح الرئيس التنفيذي أنه في الجهود المماثلة السابقة ، كان هناك معدل استجابة أكثر من 90 ٪.
• تم اقتراح أنه من الأفضل الحفاظ على الاستخدام الحالي لكائن IRT ، حيث إنه يخزن أكثر من مجرد عنوان بريد إلكتروني وهو قيد الاستخدام بالفعل على نطاق واسع.
• وأشار أحد الأعضاء إلى أن AFRINIC يجب أن تكون قادرة على التدخل إذا كان الأعضاء يستخدمون الموارد المصدرة بشكل غير مناسب.
• لم يتم الإشارة إلى الخط الزمني للحساب المراد حظره والحساب الموقوف المراد إلغاء حظره ، ويجب توضيح ذلك في نص الاقتراح. أوضح المؤلف أن الجداول الزمنية واضحة في نص الاقتراح.
• لوحظ أن MyAFRINIC يستخدم للتصويت ، وهذا يمنع الوصول إلى MyAFRINIC خلال فترة الانتخابات يحرم الأعضاء من التصويت. ذكر المؤلف أن هذه هي الأمور التي من شأنها أن تحفز الأعضاء على تحديث سجلاتهم ، ولكن تسجيل الدخول إلى MyAFRINIC يمكن استخدامها في التصويت ، ولكن ليس لإدارة الموارد.
• أشار موظفو AFRINIC إلى أن السياسة تحتاج إلى أن تكون واضحة بشكل صريح حول كيفية ارتباط IRT الحالي بإساءة الاستخدام- c.

 

قرار الرئيس المشارك: لا يوجد إجماع - يعود الاقتراح إلى القائمة البريدية لمزيد من إدخالات المجتمع والتحسين.

 

8. الاقتراح: مراجعة موارد أرقام الإنترنت من قبل AFRINIC

سار مؤلفو هذا الاقتراح على النحو التالي:

• لن يسهب المؤلفون كثيرًا في المحتوى ، حيث تطور الاقتراح على مدار عامين (من خلال ستة إصدارات مختلفة) ويعتبر ناضجًا بدرجة كافية في رأيهم.
• لذلك فإن الطريق إلى الأمام هو أفضل نهج للمضي قدمًا.
• خلص الرؤساء المشاركون من اجتماع داكار الأخير إلى أنه نتيجة لكل من المعارضة القوية والدعم القوي لمقترح السياسة لمجموعة متنوعة من الأسباب التي تم التعبير عنها عبر الإنترنت وفي اجتماع PPM ، يعود الاقتراح إلى قائمة rpd لمزيد من المناقشة والتحسين. اقترح الرؤساء المشاركون أيضًا (بعد داكار) أن يناقش المجتمع أكثر لمعرفة ما إذا كانت هناك طرق أفضل لـ AFRINIC لمعالجة المشكلة المتصورة / الملاحظة المتمثلة في الاستخدام غير المسؤول (أو التطبيقات الاحتيالية) لموارد ترقيم الإنترنت.
• سأل المؤلفون كيف يمكن للرؤساء المشاركين فك الارتباط بين الدعم القوي والمعارضة القوية ، حيث يتفق الكثيرون على أن مراجعة وتدقيق الموارد المخصصة أمر ضروري. اقترح المؤلفون تعديلاً محتملاً للقيمة 13.4 ب من خلال عدم طلب إلغاء الموارد بحكم الواقع ووضع أحكام للموظفين لإدارة عدم الامتثال على أساس كل حالة على حدة.

 

ردود فعل المجتمع:

• تحرم السياسة المستخدمين النهائيين من الوصول إلى الإنترنت ولكنهم لن يكونوا على دراية بأي عمليات تدقيق ومحفزات لعمليات التدقيق هذه على مستوى مزود خدمة الإنترنت.
• سيكون أيضًا مكلفًا وغير عملي لأن AFRINIC ستحتاج إلى توظيف أطراف خارجية لإجراء عمليات تدقيق / مراجعات. أجاب المؤلف أن القضايا فقط هي موضع ترحيب ، وبيانات الدعم أو عدم الدعم.
• وأشار بعض الأعضاء إلى أن AFRINIC تقوم حاليًا بإجراء مراجعات أو بذل جهود العناية الواجبة بشأن استخدام الموارد المصدرة ، وهذا ليس بالأمر الجديد ، وبالتالي قد لا يكون هذا الاقتراح ضروريًا على الإطلاق.
• وأوضح أحد الأعضاء أن الكثيرين لا يتفقون على أن السياسة ضرورية ، وأنه لا يوجد إجماع على أن هذا الاقتراح ضروري. ولوحظ أيضا أن نفس نسخة الاقتراح والنص فشلا في المرور في الاجتماع السابق وأنه ينبغي منطقيا ألا يمر في هذا الاجتماع. لاحظ أيضًا أن هذا الاقتراح يجعل من AFRINIC شرطة إنترنت من نوع ما ، وهي ليست جزءًا من ولايتها ، وأنه ينبغي عليها التركيز على وظائفها الأساسية.
• أشار المستشار القانوني لـ AFRINIC إلى أنه لا توجد قضايا قانونية وغيرها مع هذه النسخة بعد العمل مع المؤلفين لمعالجة المسائل التي أثيرت في تقييمات الموظفين.

 

قرار الرئيس المشارك: يذهب الاقتراح إلى المكالمة الأخيرة ولكن المزيد من مشاركات المجتمع لا تزال مفتوحة خلال تلك الفترة.

(ملاحظة: بناءً على المناقشات والارتباطات في القائمة بعد الاجتماع ، تم إرجاع الاقتراح إلى القائمة البريدية.)

 

9. الاقتراح: توضيح بشأن IPv6 مهام فرعية

شارك المؤلف النقاط البارزة من الاقتراح على النحو التالي:

• تم تقديم الاقتراح إلى الخمسة جميعًا RIR المجتمعات.
• عندما الأولي IPv6 كانت السياسة draftإد ، لم يعتبر مفهوم المهام / التخصيصات الفرعية ممارسة شائعة جدًا في IPv4 الذي يتم نسخه وتضخيمه حتى IPv6 - استخدام عناوين IP للروابط من نقطة إلى نقطة أو شبكات VPN.
• In IPv4، عادة ، هذه ليست مشكلة لأن استخدام NAT.
• في حالة IPv6بدلاً من العناوين الفريدة ، يتزايد استخدام البادئات الفريدة (/ 64). وبالمثل ، فشلت السياسة في النظر في استخدام عناوين IP في النقاط الفعالة ، أو استخدام عناوين IP من قبل الضيوف أو الموظفين في إحضار جهازك الخاص (BYOD) والعديد من الحالات الأخرى.
• هناك أوقات يتعاقد فيها المستخدم النهائي مع طرف ثالث للقيام ببعض الخدمات في شبكته الخاصة ويحتاج إلى نشر أجهزته الخاصة ، حتى الخوادم ، ومعدات الشبكة ، وما إلى ذلك ، على سبيل المثال ، قد تتطلب خدمات المراقبة الأمنية أن يوفرها المقاول الكاميرات الخاصة بهم ، ونظام التسجيل ، وحتى جدار الحماية و / أو جهاز التوجيه الخاص بهم لشبكة VPN مخصصة ، وما إلى ذلك بالطبع ، في كثير من الحالات ، قد يحتاج نظام المراقبة هذا إلى استخدام مساحة العنونة للمستخدم النهائي.
• وافق IETF مؤخرًا على استخدام بادئة فريدة / 64 لكل واجهة / مضيف (RFC8273) بدلاً من عنوان فريد. هذا ، على سبيل المثال ، يسمح للمستخدمين بالاتصال بنقطة اتصال ، واستلام / 64 بحيث يتم عزلهم عن المستخدمين الآخرين (لأسباب تتعلق بالأمان ، والمتطلبات التنظيمية ، وما إلى ذلك) ويمكنهم أيضًا استخدام أجهزة افتراضية متعددة على أجهزتهم باستخدام عنوان فريد لكل واحد (داخل نفس / 64).
• القسم 2.6 (التعريفات العامة / التنازل) ، يحظر صراحة مثل هذه التخصيصات ، مشيرًا إلى أن التخصيصات لن يتم تخصيصها من الباطن لأطراف أخرى. هناك خياران ، أولاً - اطلب من المستخدمين النهائيين التأكد من أنهم يستخدمون السياسة بشكل صحيح وإنفاذها ، واستعادة الموارد في حالة إساءة استخدامها ، وثانيًا ، تصحيح أخطائنا في الوقت الحالي IPv6 السياسة - ما هو الخيار الأخير هو النهج المتبع مع تقديم هذا الاقتراح.
• يوضح هذا الاقتراح هذا الموقف ويحدد المفهوم بشكل أفضل ، لا سيما النظر في الاستخدامات الجديدة لـ IPv6 (RFC 8273) ، عن طريق نص جديد في نهاية أي نص متاح في IPv6 سياسة تخصيصات PI. كما يوضح أن استخدام التخصيصات الفرعية في مزودي خدمات الإنترنت ومراكز البيانات والحالات المماثلة غير مسموح به.
• باختصار ، هذا الاقتراح ينص فقط على ذلك IPv6 يُسمح باستخدام مساحة PI في شبكة صاحب المهمة وأجهزة الطرف الثالث فقط التي تعمل بشكل صارم داخل تلك البنية التحتية ، بما في ذلك أي وصلات بينية. ومع ذلك لا يسمح باستخدام الصادرة IPv6 مساحة PI لتقديم الخدمات للعملاء مثل مزودي خدمة الإنترنت ومركز البيانات أو الحالات المماثلة. هذه هي الحالات التي يتم النظر فيها هنا كتخصيصات فرعية.
• هناك اقتراح مماثل قيد المناقشة في مجتمعات LACNIC و RIPE و APNIC.
• وأشار الموظفون إلى عدم وجود مخاوف في التقييم.

ردود فعل المجتمع:

• كان هناك بيان دعم للاقتراح ولم توجد بيانات ضده.
• أثير قلق بشأن الترقيم من قبل الموظفين - وأوضح المؤلف أنه يجب إدراج نص الاقتراح مباشرة بعد النص الحالي في المادة 6.8 من هيئة تدابير الصحة النباتية حيث يسهل قراءته وتفسيره.

قرار الرئيس المشارك: ينتقل الاقتراح إلى آخر مكالمة - لكن المزيد من مشاركات المجتمع لا تزال مفتوحة خلال تلك الفترة.

 

10 - الاقتراح: -RIR نقل الموارد

وقدم الاقتراح صاحب الاقتراح - وأشار إلى ما يلي:

• يسمح لـ AFRINIC بدخول سوق قائم للتحويلات لـ IPv4, IPv6 و ASN موارد.
• وقد لوحظ ذلك IPv6 تساعد التحويلات في حالة انتقال الشركة إلى شركة أخرى RIR المنطقة وتريد أن تنتقل بمواردها إلى هذا الجديد RIR.
• ألا تكون جزءًا من السوق خلال مراحل IPv4 الاستنفاد سوف يضر AFRINIC ISPs.
• للحد من ذلك بكثير IPv4 خارج القارة ، فإن الاقتراح يسمح فقط بنقل الإرث إلى الخارج IPv4 الفراغ. هذا مهم لأن التسجيل الدقيق لهذه الموارد أمر بالغ الأهمية ، ومع ذلك فمن المحتمل أن تكون قيد الاستخدام خارج المنطقة.
• الحد الأدنى للأحجام القابلة للتحويل هو / 24 ل IPv4 و / 48 لـ IPv6. في كلتا الحالتين ، يجب على المستلم إثبات الحاجة إلى نقل المورد.
• In IPv6 لا يمكن نقل الكتلة إلا بعد عامين من التخصيص أو التعيين الأولي.
• فيما يتعلق بنقل أنواع الموارد الأخرى ، أشارت AFRINIC بالفعل (في تقرير تنفيذ السياسة) إلى أنRIR يسمح النقل فقط IPv4 عمليات النقل ، وليس أنواع الموارد الأخرى.
• لا يمكن إعادة تحويل الموارد المحولة إلا بعد عام واحد من آخر عملية تحويل.
• توجد سياسات مكافئة في مناطق أخرى ، وتناقش LACNIC نصًا شبه متطابق. تقوم ARIN بتصدير أكبر عدد من الموارد في سوق النقل.

 

وردت ردود وتعليقات على النحو التالي: 

• وقد لوحظ أن كتلة مثل 196 لها مساحة قديمة وغير قديمة موجودة في AFRINIC وفي مناطق أخرى.
• يجب وضع السياسة للتحويلات الداخلية فقط ، بحيث تظل موارد AFRINIC في إفريقيا. وأشار المؤلف إلى أن المناطق الأخرى بحاجة إلى المعاملة بالمثل ، ومن ثم الحاجة إلى توفير خيارات خارجية.
• وقد لاحظ البعض أنه نظرًا لأن السياسة تسمح فقط بالخارج IPv4 مساحة الإرث فقط ، إنها سياسة جيدة.
• كان هناك دعم لهذه السياسة لأنها تسمح لـ AFRINIC بالمشاركة في السوق العالمية ، والسياسة كما هي مكتوبة مقبولة.
• وقد لوحظ أن هناك حاجة إلى أن يكون هناك تحويلات ثنائية الاتجاه حتى يكون الاقتراح متبادلاً ومتوافقًا مع سياسة النقل ARIN.
• سُئل المؤلف عن سبب عدم وجود حد أقصى للكتلة القابلة للتحويل (بينما توجد أحجام دنيا). أشار المؤلف إلى أنه لم يقترح أحد هذه الفكرة حتى الآن ، لكنه أشار إلى أنه قد لا تكون هناك حاجة إليها - ولكنه منفتح على الاقتراحات من المجتمع.

  

قرار الرئيس المشارك: لا يوجد إجماع - يعود الاقتراح إلى القائمة البريدية لمزيد من إدخالات المجتمع والتحسين.

 

11- الاقتراح: IPv4 لينة الهبوط BIS

كانت ملاحظات المؤلفين على النحو التالي:

• كان الهدف من اقتراح Soft Landing-bis تحديث سياسة الهبوط الناعم الحالية المعتمدة في عام 2011.
• كان من الواضح في تقرير تنفيذ سياسة AFRINIC أن بعض المخاوف المذكورة تم تناولها في هذا الاقتراح.
• تم تناول إحدى القضايا التي سيتم تناولها بالفعل في مقترح السياسة الأخرى للمؤلفين التالي على جدول الأعمال ، بعنوان "تحديث SL".
• ولذلك قرر أصحاب البلاغ السماح بالاقتراح "IPv4 Soft Landing bis "تنتهي صلاحيته.

[ملاحظة: انتهت صلاحية اقتراح السياسة في 01 ديسمبر 2018 بما يتماشى مع PDP]

 

12. الاقتراح: SL-Update 

شارك المؤلفون النقاط البارزة على النحو التالي:

• يحتفظ قسم CPM 5.4.7.1 من سياسة الهبوط الناعم الحالية باحتياطيات a / 12 من آخر / 8 للاستخدامات المستقبلية غير المتوقعة.
• يسمح قسم CPM 5.4.7.2 لمجلس AFRINIC وفقًا لتقديره (النظر في الطلب وعوامل أخرى) - في الوقت الذي لم تعد فيه AFRINIC قادرة على تلبية أي طلبات أخرى لمساحة العنوان من آخر / 8 أو أي مساحة عنوان متاحة أخرى ، لتجديد تجمع الاستنفاد مع أي مساحة عنوان (أو جزء منها) ، والتي قد تكون متاحة في ذلك الوقت والقيام بذلك بطريقة تصب في مصلحة المجتمع.
• وبالتالي ، يمنح القسم 5.4.7.2 المجلس السلطة المطلقة والوحيدة لاتخاذ قرار بشأن كيفية استخدام الكتلة المحجوزة لتجديد مجموعة الاستنفاد في نهاية المطاف وقد يكون تحديد قواعد التخصيص / التخصيص.
• تكمن المشاكل في ذلك في أنه إذا لم يتم اعتماد سياسة يحركها المجتمع لتحديد كيفية استخدام المساحة المحجوزة قبل استنفاد التجمع ، فقد يتصرف مجلس الإدارة وفقًا لتقديره مع أو بدون مشاركة المجتمع وموافقته.
• وبالتالي ، فإن المجتمع في وضع أفضل لتحديد ما هو في مصلحته ويتم مناقشة ذلك بشكل أفضل من خلال PDP.
• وبناءً عليه ، فإن هذا الاقتراح يعيد منح 5.4.7.2 لإلغاء تقدير المجلس ، من أجل: "إذا ظل المحجوز / 12 غير مستخدم بحلول الوقت الذي تم فيه تخصيص المساحة المتبقية المتاحة ، فسيتم إرجاع / 12 إلى تجمع AFRINIC للتوزيع وفقًا لشروط المرحلة 2 من سياسة الهبوط السهل.

 

تم تلقي ردود الفعل والتعليقات من المجتمع على النحو التالي:

• طُلب من AFRINIC توضيح ما إذا كانت وحدات البت والقطع الصغيرة المستلمة من IANA ستصدر أيضًا بموجب سياسة الهبوط الناعم. أوضح AFRINIC أن الهبوط الناعم بدأ عندما بدأت AFRINIC في التخصيص من آخر / 8 ، وأن كل المساحة داخل المخزون (وليس بالضرورة الأخير / 8) ستصدر جميعها بموجب آلية الهبوط الناعم.
• لا شيء يشير إلى أن مجلس الإدارة يجب أن يتبع سياسة الهبوط الناعم عند تحديد ما يجب فعله بالاحتياطي ، وبالتالي من الجيد تصحيح هذه المخاطر وعدم اليقين إذا قرر مجلس الإدارة إدارة الاحتياطي خارج عمليات الهبوط السهل.
• يجب أن تركز السياسات على التعزيز والترويج IPv6، وعدم إضافة المزيد من القيود على المتضائل IPv4 حوض السباحة. ذكر الكتاب أن IPv4 لا يزال ذا صلة حيث توجد مناقشات نشطة حول IPv4 التحويلات وكيف لا يزال بإمكان مجتمع AFRINIC الاستفادة من السوق.
• لوحظ أن منطقة ARIN ليس لديها IPv4 سياسة الهبوط اللين وأن هناك سوقًا نابضة بالحياة في تلك المنطقة في نفس الوقت أعلى IPv6 معدلات التبني.

قرار الرئيس المشارك: لا يوجد إجماع - يعود الاقتراح إلى القائمة البريدية لمزيد من إدخالات المجتمع والتحسين.

 

13. افتح ميكروفون السياسة

تم طرح النقاط التالية من قبل المجتمع خلال جلسة Open Microphone: 

• فيما يتعلق بقرار تقديم المقترحات للمكالمة الأخيرة ، أو إرسالها مرة أخرى إلى القائمة البريدية ، فمن الأفضل أن يذكر الرؤساء المشاركون أسباب إعادة إرسال الاقتراح إلى القائمة ، بحيث يكون واضحًا للجميع. فيما يتعلق بمسألة اقتراح SL-Update ، أوضح الرؤساء المشاركون أن الاقتراح يحتاج إلى مزيد من الوقت لمناقشته ، على الرغم من أن المؤلفين أشاروا إلى أن الوقت كان كافياً ، بما يتماشى مع ما تنص عليه PDP. أشار أحد الأعضاء إلى وجود أحكام في PDP للطعن في قرارات الرؤساء المشاركين في حالة السخط.
• وقد لوحظ أن التقديم في غضون الوقت المحدد لا يُترجم إلى مناقشات كافية ، وأن الاجتماع وجهاً لوجه يمنح المجتمع أيضًا رؤى أفضل حول روح الاقتراح ، مما يسمح بإجراء مناقشات إضافية مستنيرة ومثرية.
• عرض جوردي مساعدة أي أفراد لم يساهموا في عملية السياسة للتواصل معه ، بحيث يمكن معالجة القضايا التي أثيرت في تقرير تنفيذ السياسة من قبل موظفي AFRINIC من خلال مقترحات السياسة من قبل هؤلاء الأفراد.
• أثنى أحد الأعضاء على الرؤساء المشاركين على جهودهم في عملهم ، وكذلك العديد من مؤلفي السياسات على جهودهم.
• وقد لوحظ أن المناقشات في هذا الاجتماع كانت ودية ولم تكن هناك هجمات مهينة كما كان الحال من قبل ، وأنه ينبغي الحفاظ على الطريقة الودية للمناقشات سواء في القائمة البريدية أو في الاجتماعات المقبلة.
• وشكر أحد الزملاء AFRINIC نيابة عن جميع الزملاء الآخرين على الفرصة وعرض AFRINIC للمشاركات التي حدثت خلال هذا الاجتماع. كما أعرب زميل آخر عن تقديره لتجربة هذه المناقشات وجهًا لوجه على عكس ما كان يراه في القائمة ، وشكر جوردي على عرضه لتجنيد مؤلفي السياسة الجدد.
• يجب أن يركز المجتمع بشكل أقل على السياسة وأكثر على تعزيز سياسات أفضل على الرغم من أنها قد لا تكون مثالية بنسبة 100٪ ، بالإضافة إلى موضوعات أخرى مثل RPKI.
• حث أحد المشاركين عن بعد الرؤساء المشاركين على إعادة النظر في قرارهم للمضي قدمًا في اقتراح مراجعة موارد أرقام الإنترنت حتى آخر مكالمة ، وإعادته إلى القائمة ، حيث أثيرت قضايا مهمة ضده ، وأن بعض الأشخاص سوف يستأنفون بالتأكيد - مما سيخلق التبادلات غير الضرورية. كما حث المؤلفين على النظر في سحبها ، حيث قد لا يكون هناك أي إجماع حولها في المستقبل.
• كان هناك استفسار حول إمكانية قيام AFRINIC بدفع تكاليف واضعي السياسات لحضور اجتماعات السياسة العامة.
• وقد لوحظ أنه بما أن الموظفين أشاروا في تقرير تنفيذ السياسة حول أوجه عدم الاتساق المختلفة ، فهناك حاجة إلى الاتساق ، وأن مقترحات المراجعة تحدد الطريق إلى الاتساق في الاتجاه الصحيح. 

 

ملخص قرارات الرئيس المشارك بشأن مقترحات السياسة 

مقترح	قرار	التعليقات
عملية تطوير سياسة أفرينيك - AFRINIC مكرر v4	العودة للقائمة
تحديث بسيط من PDP		سحبت من قبل المؤلف
تحديث سياسة إساءة الاتصال	العودة للقائمة
مراجعة موارد رقم الإنترنت من قبل AFRINIC	الرجوع للقائمة	تم تغيير القرار الأولي بعد الاجتماع
توضيح على IPv6 مهام فرعية	النداء الأخير
بين الوكالاتRIR تحويل الموارد	العودة للقائمة
IPv4 لينة الهبوط BIS		سحبها المؤلفون
SL-تحديث	العودة للقائمة