كيف تفحص تاريخ نقل عناوين IPv4 قبل استخدام بادئة
دليل عملي لفحص سجلات نقل IPv4 وبيانات التسجيل وتاريخ التوجيه والوثائق الداعمة قبل استخدام بادئة.
قبل تشغيل بادئة IPv4 أو استئجارها أو نقلها أو قبولها، من المفيد فهم كيف وصلت كتلة العناوين هذه إلى وضعها الحالي.
يمكن أن يقدّم قيد السجل الحالي معلومات مهمة عن المورد اليوم.
لكنه قد لا يروي تاريخه كاملًا.
ربما خُصّصت كتلة IPv4 قبل سنوات، ثم قُسّمت إلى بادئات أصغر، أو نُقلت بين مؤسسات، أو انتقلت بين سجلات الإنترنت الإقليمية، أو أعلنتها أرقام أنظمة مستقلة مختلفة، أو فُوّض استخدامها إلى عملاء، أو شملتها عملية اندماج أو استحواذ.
لذلك لا يقتصر السؤال العملي لمشغّلي الشبكات على:
مَن يظهر في السجل اليوم؟
بل يشمل أيضًا:
هل يمكن ربط الوضع الحالي بتاريخ واضح وموثوق للتغييرات السابقة في الحالة؟
هنا تتضح فائدة العناية الواجبة عند فحص تاريخ نقل IPv4.
ما تاريخ نقل IPv4؟
تاريخ نقل IPv4 هو التاريخ الموثّق للتغييرات في العلاقة المسجّلة بين مورد IPv4 والمؤسسات المرتبطة به.
بحسب السجل ونوع المعاملة، قد تتضمن بيانات النقل البادئة المنقولة، والمؤسسة الناقلة، والمؤسسة المستقبلة، وسجلات الإنترنت الإقليمية المعنية، ونوع النقل، وتاريخ معالجة المعاملة.
فعلى سبيل المثال، ينشر RIPE NCC عمليات نقل IPv4 الصحيحة، ويميّز بين النقل المعتاد بموجب السياسات والتغييرات المرتبطة بإعادة هيكلة المؤسسات، مثل الاندماج أو الاستحواذ.
وتحتفظ ARIN أيضًا بسجل علني لعمليات نقل IPv4 إلى مستلمين محددين داخل منطقتها، ولعمليات النقل بين سجلات الإنترنت الإقليمية التي تستوفي الشروط.
وصيغة سجل النقل لدى APNIC تراكمية، وقد صُمّمت لحفظ المعلومات التاريخية عن النقل بمرور الوقت.
تشكّل هذه القيود طبقة تاريخية مهمة من المعلومات حول موارد IPv4.
لماذا نفحص تاريخ نقل IPv4؟
قد تظل عناوين IPv4 قيد التشغيل لعقود.
وخلال ذلك، قد تتغير المؤسسات والشبكات المحيطة بها تغيرًا كبيرًا.
قد تكون البادئة مرّت بالمراحل التالية:
تخصيص أولي، ثم نقل، ثم تقسيم، ثم نقل آخر، ثم نقل بين سجلات الإنترنت الإقليمية، ثم تغيير مزوّد الخدمة، ثم تفويض الاستخدام، ثم ترتيب توجيه جديد.
تبقى أرقام IPv4 نفسها.
لكن السياق المحيط بها يتغير.
لذلك يساعد تاريخ النقل في تحديد ما إذا كانت حالة السجل الحالية تتسق مع سلسلة موثوقة من التغييرات السابقة الموثّقة.
وتزداد فائدته قبل:
- الحصول على مساحة عناوين IPv4؛
- قبول بادئة منقولة؛
- استئجار مساحة عناوين؛
- تشغيل كتلة غير مألوفة؛
- إتمام اندماج أو استحواذ؛
- تغيير مزوّد الخدمة؛
- تقييم إثبات التحكم؛ أو
- التحقيق في تغيير غير متوقع في السجل.
يوضح نقاش Heng.lu حول [إثبات التحكم في عنوان IP] لماذا لا ينبغي اعتبار أي حقل منفرد في قاعدة بيانات دليلًا تلقائيًا على جميع الحقوق المحتملة المرتبطة بمورد ترقيم على الإنترنت. فمعلومات السجل، وتفويضات التوجيه، والعقود، والأدلة التشغيلية تجيب عن أسئلة مختلفة. إثبات التحكم في عنوان IP
ويقدّم تاريخ النقل جزءًا آخر من هذه الأدلة.
الخطوة 1: تحديد البادئة بدقة
ابدأ بتحديد مورد IPv4 نفسه بدقة.
مثلًا:
203.0.113.0/24
بدل الاكتفاء بعنوان مثل:
203.0.113.15
قد ينتمي العنوان الفردي إلى بادئة مسجّلة أكبر.
وإذا جرى تقسيم المورد من قبل، فقد تكون البادئة الحالية أصغر أيضًا من التخصيص الأصلي.
وهذا مهم لأن تاريخ النقل قد يشمل أحيانًا:
الكتلة الأصلية
→ البادئة الفرعية المنقولة
مثلًا:
/16 → /20
أو:
/20 → عدة كتل /24
لذلك قد تكون الكتلة الأم التاريخية ذات صلة، حتى لو كان المورد الحالي أصغر بكثير.
الخطوة 2: فحص الحالة الحالية لدى السجل المرجعي المختص
الخطوة التالية هي تحديد سجل الإنترنت الإقليمي المسؤول حاليًا عن معلومات تسجيل البادئة.
RDAP هو الآلية الحديثة الموحّدة للاستعلام عن بيانات التسجيل على الإنترنت.
يحدّد RFC 9082 أنماطًا موحّدة لاستعلامات RDAP لاسترجاع معلومات التسجيل من السجلات، ومنها سجلات الإنترنت الإقليمية.
قد تساعد استجابة RDAP الحالية في تحديد:
سجل الإنترنت الإقليمي الحالي
المؤسسة المسجّلة
نطاق المورد
جهات الاتصال المعنية
حالة التسجيل
وغير ذلك من معلومات السجل الحالية.
لكن هناك تمييز مهم:
الحالة الحالية ليست هي الحالة التاريخية.
إذا أظهر RDAP المؤسسة B اليوم، فهذا لا يفسّر بالضرورة ما إذا كان المورد قد خُصّص أصلًا للمؤسسة A، أو نُقل من منطقة أخرى، أو نتج عن تقسيم تخصيص أكبر.
ولمعرفة ذلك نحتاج إلى أدلة تاريخية.
الخطوة 3: البحث في سجلات النقل لدى السجلات الإقليمية المعنية
بعد تحديد السجل الحالي، راجع سجلات النقل المتاحة.
تنشر سجلات الإنترنت الإقليمية معلومات النقل عبر واجهات وصيغ مختلفة.
مثلًا، يوثّق نظام ARIN العلني النقل إلى مستلمين محددين والنقل بين السجلات الإقليمية، بينما ينشر RIPE NCC عمليات النقل الصحيحة ويوفّر بيانات قابلة للتنزيل. وتحتفظ APNIC بسجلات نقل تراكمية.
من الأسئلة المفيدة:
هل نُقلت هذه البادئة تحديدًا؟
هل كانت جزءًا من كتلة أكبر جرى نقلها؟
متى عولجت عملية النقل؟
ما المؤسسات التي شاركت فيها؟
هل كانت عملية نقل معتادة أم إعادة هيكلة للمؤسسة؟
هل عبر المورد حدود سجل إقليمي؟
تساعد هذه الأسئلة في إعادة بناء تاريخ السجل.
الخطوة 4: التحقق من النقل بين سجلات الإنترنت الإقليمية
قد تكون البادئة قد انتقلت أيضًا بين سجلات الإنترنت الإقليمية.
مثلًا:
ARIN → RIPE NCC
أو:
ARIN → APNIC
حينئذ قد لا يمثّل السجل الحالي وحده التاريخ الإداري الكامل للبادئة.
فمثلًا، ينشر RIPE NCC معلومات النقل بين السجلات الإقليمية، بما يشمل الكتل المنقولة، والسجل الإقليمي المصدر، ومعلومات المستلم، وتواريخ المعالجة.
وهذا مهم لأن النقل بين السجلات الإقليمية انتقال جوهري في حالة التسجيل.
تبقى أرقام IPv4 دون تغيير.
لكن بيئة التسجيل المرتبطة بالمورد تتغير.
يتناول تحليل Heng.lu عن [نقل IPv4 بين السجلات الإقليمية في 2026] هذه الحركة بتفصيل أكبر، ويوضح كيف تواصل ملايين عناوين IPv4 عبور حدود السجلات. نقل IPv4 بين السجلات الإقليمية في 2026
الخطوة 5: مقارنة قيد النقل بقيد التسجيل الحالي
بعد العثور على عملية نقل تاريخية، قارنها بمعلومات السجل الحالية.
لنفترض أن قيد النقل يوضح:
من المؤسسة A إلى المؤسسة B
وأن RDAP الحالي يعرض:
المؤسسة B
فهذا متسق في المجمل.
لكن لنفترض أن المعلومات الحالية تعرض:
المؤسسة C
لا يعني ذلك تلقائيًا أن هناك خطأ.
ربما حدث:
نقل آخر؛
اندماج أو استحواذ؛
تغيير لاسم الشركة؛
إعادة هيكلة؛
أو تحديث مشروع آخر.
ليس هدف العناية الواجبة اعتبار كل اختلاف أمرًا مريبًا.
بل تفسير الاختلاف.
ينبغي أن يجعل التاريخ الموثوق للمورد انتقالات الحالة الرئيسية مفهومة.
الخطوة 6: فحص تاريخ توجيه BGP بصورة منفصلة
لا تخلط بين تاريخ النقل وتاريخ التوجيه.
يمكن أن يتغير رقم النظام المستقل المنشئ لإعلان البادئة دون حدوث نقل في السجل.
وبالمثل، قد يستمر رقم النظام المستقل نفسه في إعلان بادئة بعد نقلها.
وهذا يعني أن مورد IPv4 قد يكون له تاريخان مختلفان على الأقل:
تاريخ السجل
و
تاريخ التوجيه
قد يتداخلان.
لكنهما ليسا بديلين أحدهما عن الآخر.
إذا أظهرت بيانات BGP التاريخية انتقال البادئة من رقم نظام مستقل منشئ إلى آخر، فهذا دليل على تغير في التوجيه.
لكنه لا يثبت وحده أن الحائز المسجّل تغير.
وهذا التمييز مهم عند محاولة إعادة بناء دورة حياة مورد العناوين.
الخطوة 7: مراجعة حالة RPKI
توفّر RPKI طبقة أخرى من الأدلة.
قد يبيّن تفويض منشأ المسار، أو ROA، رقم النظام المستقل المخوّل بإنشاء إعلان البادئة ضمن إطار RPKI.
إذا تغير حائز البادئة أو مزوّدها أو بنية توجيهها، فقد يكون تاريخ تفويضات ROA قد تغير أيضًا.
مثلًا:
التوجيه السابق
البادئة يعلنها AS64500
التوجيه الحالي
البادئة يعلنها AS64550
السؤال المفيد ليس فقط ما إذا كان رقم النظام المستقل قد تغير.
بل هو:
هل كانت علاقة التوجيه الجديدة مخوّلة ومتسقة مع الانتقال التشغيلي للمورد؟
لذلك تكمّل RPKI معلومات النقل وBGP.
ولا تحل محل أي منهما.
الخطوة 8: البحث عن أدلة على تقسيم البادئة
يصبح تاريخ النقل أعقد عندما يكون المورد قد قُسّم.
لنأخذ تخصيصًا أصليًا هو:
192.0.0.0/16
لاحقًا، تُنقل الكتلة التالية:
192.0.32.0/20
وحدها.
قد يعرض البحث الحالي عن /20 الحالة الراهنة، بينما تشير سجلات التخصيص الأقدم إلى /16.
لا يمثّل ذلك بالضرورة تناقضًا.
قد يعكس ببساطة دورة حياة المورد.
يصف تحليل Heng.lu عن [تغيّر دورة حياة عناوين IPv4] كيف تمر موارد IPv4 الناضجة، بصورة متزايدة، بالنقل والتقسيم وإعادة التوجيه وإعادة الاستخدام. تغيّر دورة حياة عناوين IPv4
عند تقييم تاريخ النقل، ضع دائمًا في الحسبان احتمال أن المورد الحالي كان أصلًا جزءًا من كتلة أكبر.
الخطوة 9: فصل تاريخ السجل عن تاريخ السمعة
قد يغيّر النقل أيضًا السياق المحيط بكتلة عناوين دون أن تتغير فورًا أنظمة السمعة التابعة لأطراف أخرى.
فمثلًا، ربما استُخدمت البادئة سابقًا في:
الاستضافة؛
البنية التحتية للبريد الإلكتروني؛
خدمات النطاق العريض المنزلية؛
خدمات VPN؛
أحمال العمل السحابية؛
أو تطبيق آخر.
وبعد النقل، قد تُستخدم لغرض مختلف تمامًا.
لكن قواعد بيانات السمعة أو تحديد الموقع الجغرافي لدى أطراف أخرى قد تظل تعكس ملاحظات سابقة.
وهنا يظهر تمييز مهم آخر:
يشرح تاريخ النقل التغييرات في حالة السجل.
ولا يعيد تلقائيًا ضبط كل قاعدة بيانات خارجية مرتبطة بعناوين IP.
لذلك قد يحتاج المشغّلون قبل التشغيل الفعلي إلى مراجعة كليهما:
تاريخ السجل
و
تاريخ السمعة التشغيلية.
فكل منهما يعالج مشكلة مختلفة.
الخطوة 10: فحص الوثائق الداعمة
يمكن للبيانات العامة أن تثبت الكثير، لكن ليس بالضرورة كل شيء.
في المعاملات المهمة أو البنى التحتية الحرجة، قد تشمل الأدلة الإضافية تأكيدات النقل، والمراسلات مع السجل، ووثائق صلاحيات تمثيل الشركة، وخطابات التفويض، والعقود، وسجلات الأصول الداخلية، ووثائق التغيير.
وتزداد أهمية ذلك حين تختلف عدة طبقات من المعلومات.
مثلًا:
السجل: المؤسسة A
BGP: نظام مستقل تشغّله المؤسسة B
المستخدم التشغيلي: المؤسسة C
قد يكون هذا الترتيب مشروعًا تمامًا.
وقد يفسّره عقد إيجار أو خدمة مُدارة أو تفويض آخر.
ليس الهدف فرض اسم المؤسسة نفسه في جميع الطبقات.
بل إثبات أن كل علاقة مشروعة وقابلة للفهم.
ما الذي لا يخبرك به سجل النقل؟
سجلات النقل مفيدة للغاية، لكن لها حدودًا.
عمومًا، لا ينبغي اعتبار سجل النقل دليلًا على:
سعر المعاملة؛
الاتفاق التجاري الكامل؛
سبب النقل؛
الموقع المادي للبنية التحتية؛
منشأ BGP الحالي؛
المستخدم التشغيلي الحالي؛
أو جميع المصالح التعاقدية المرتبطة بالمورد.
وبالمثل، فإن غياب قيد من سجل نقل واحد لا يثبت تلقائيًا أن شيئًا لم يتغير قط.
فربما حدثت عمليات اندماج، أو وُجدت سجلات موروثة، أو اختلافات في السياسات، أو تفويضات استخدام، أو أحداث أخرى تحتاج إلى تحقيق إضافي.
لذلك تجمع العناية الواجبة الجيدة الأدلة بدل الاعتماد على مصدر واحد.
الفرق بين تاريخ النقل وتاريخ الملكية
كثيرًا ما يبحث الناس عن «تاريخ ملكية» عنوان IP.
قد تكون هذه الصياغة مضللة.
توجد موارد ترقيم الإنترنت ضمن أطر تقنية وتعاقدية وتسجيلية وقانونية قد تختلف باختلاف الولاية القضائية والظروف.
من الأدق فهم قيد النقل العلني في السجل باعتباره دليلًا على انتقال موثّق للمورد.
قد يخبرنا بأن سجلًا اعترف بنقل المورد من مؤسسة إلى أخرى.
لكنه لا يحسم بالضرورة كل مسألة قانونية محتملة تتعلق بالملكية أو مصالح المستفيدين أو الحقوق التعاقدية.
لذلك فإن السؤال الأدق هو:
ما التاريخ الذي جرى التحقق منه لحالة السجل المرتبطة بهذا المورد؟
يمكن عادة الإجابة عن هذا السؤال بموضوعية أكبر.
لماذا يهم تاريخ النقل في إثبات التحكم؟
لنفترض أن المؤسسة B تريد نقل كتلة IPv4.
تحدّد معلومات السجل الحالية المؤسسة B.
وتوضح السجلات التاريخية:
من المؤسسة A إلى المؤسسة B
وتؤكد وثائق الشركة أن الممثلين المخوّلين للمؤسسة B هم من يطلبون المعاملة الجديدة.
كما تتسق حالة التوجيه وRPKI مع البيئة التشغيلية المتوقعة.
تقدّم هذه الأدلة مجتمعة صورة أقوى من أي قيد منفرد.
وهذا هو هدف قابلية التدقيق.
لا ينبغي أن يقتصر انتقال الحالة على مجرد حدوثه.
بل ينبغي أن يكون ممكنًا فهم كيف حدث.
لماذا يجب حفظ الحالات التاريخية؟
معلومات السجل الحالية ضرورية.
وتزداد أهمية الحالات التاريخية كلما تقادمت الموارد وزادت حركتها.
لنفترض أن بادئة مرّت بالمراحل التالية:
1998: التخصيص الأولي
2013: إعادة هيكلة الشركة
2017: التقسيم
2020: النقل
2023: النقل بين سجلات الإنترنت الإقليمية
2025: تغيير مزوّد الخدمة
2026: تفويض الاستخدام
النظر إلى قيد اليوم وحده يخبرنا بالوجهة.
لكنه لا يشرح الرحلة.
يطوّر اقتراح Heng.lu بشأن [تصدير حالة السجل لموارد ترقيم الإنترنت] هذه الفكرة: ينبغي لبنية السجل القادرة على الصمود أن تحفظ قدرًا كافيًا من بيانات الحالة والتاريخ المتحقَّق من أصالتها، بحيث تظل انتقالات الموارد المهمة قابلة للتحقق والنقل بمرور الوقت. تصدير حالة السجل لموارد ترقيم الإنترنت
وهكذا يتحول تاريخ السجل من أرشيف إداري إلى بنية تحتية للاستمرارية.
قائمة عملية لفحص تاريخ نقل IPv4
قبل الاعتماد على بادئة IPv4 غير مألوفة، تحقّق مما يلي:
- المورد المحدد بدقة — تأكد من كتلة CIDR الصحيحة، ومما إذا كانت مشتقة من تخصيص أكبر.
- السجل الحالي — حدّد سجل الإنترنت الإقليمي المرجعي المختص وحالة RDAP الحالية.
- الحائز الحالي — تأكد من المؤسسة التي يعترف بها السجل حاليًا.
- سجلات النقل — ابحث عن البادئة والكتل الأم ذات الصلة في سجلات النقل المتاحة لدى سجلات الإنترنت الإقليمية.
- تاريخ الانتقال بين السجلات الإقليمية — حدّد ما إذا كان المورد قد انتقل بين سجلات الإنترنت الإقليمية.
- تغييرات الشركات — ابحث عن عمليات اندماج أو استحواذ أو تغييرات أسماء تفسّر الانتقالات.
- تاريخ التوجيه — راجع أرقام الأنظمة المستقلة المنشئة السابقة والحالية بمعزل عن تاريخ النقل.
- RPKI — تأكد من أن تفويض منشأ المسار الحالي يتوافق مع الشبكة المقصودة.
- تفويض الاستخدام — حدّد علاقات الإيجار أو الاستضافة أو العملاء حيث تكون ذات صلة.
- حفظ الأدلة — احتفظ بنسخ من قيود التسجيل والنقل والتوجيه والتفويض المستخدمة في المراجعة.
ليس الهدف إضافة أوراق لا داعي لها.
بل ضمان أن موردًا مهمًا للبنية التحتية يمتلك سلسلة حالات مفهومة.
ماذا لو لم تتطابق السجلات؟
ينبغي التحقيق في الاختلافات، لا اعتبارها فورًا دليلًا على مخالفة.
حدّد أولًا الطبقة التي تختلف.
هل المشكلة في:
حالة السجل؟
تاريخ النقل؟
توجيه BGP؟
RPKI؟
IRR؟
هوية الشركة؟
تفويض الاستخدام؟
ثم حدّد ما إذا كان هناك تفسير مشروع.
إذا تغير قيد السجل المرجعي نفسه بصورة غير متوقعة، فاحفظ الأدلة الموجودة قبل إجراء تغييرات إضافية.
يوصي دليل Heng.lu عن [الاستعداد لتغيير غير متوقع في قيود السجل] بحفظ مخرجات RDAP أو WHOIS، ومعلومات التوجيه، وحالة RPKI، وبيانات IRR، والسجلات الداخلية، حتى يمكن إعادة بناء الحالة السابقة المعروفة بصورة مستقلة. الاستعداد لتغيير غير متوقع في قيود السجل
تاريخ النقل جزء من دورة حياة IPv4
غيّر نفاد IPv4 دور السجلات.
لم تعد المسألة تقتصر على:
كيف ينبغي تخصيص العناوين غير المستخدمة؟
بل أصبحت بصورة متزايدة:
كيف ينبغي للعناوين الموجودة أن تنتقل بين حالات مشروعة، مع الحفاظ على تفرّدها ودقة تسجيلها؟
قد تعيش بادئة IPv4 ناضجة مدة أطول من حائزها الأصلي وشبكتها الأصلية ورقم نظامها المستقل الأصلي وغرضها التجاري الأول.
وهذا يجعل التاريخ أكثر قيمة مع الوقت.
على السجل إظهار الحالة الحالية.
وتساعد سجلات النقل في تفسير الحالات السابقة.
يصف BGP حالة التوجيه.
وتصف RPKI تفويض منشأ المسار.
وتصف السجلات التشغيلية كيفية استخدام المورد فعليًا.
لا تحتاج هذه الأنظمة إلى الإجابة عن السؤال نفسه.
لكن يجب أن تبقى مفهومة عند النظر إليها معًا.
الخلاصة
فحص تاريخ نقل IPv4 ليس بحثًا عن حقل واحد يثبت كل شيء.
بل هو إعادة بناء سلسلة مفهومة من حالات المورد.
ابدأ بالقيد الحالي لدى السجل المرجعي المختص.
ثم افحص سجلات النقل.
وابحث عن الانتقال بين السجلات الإقليمية وعن التقسيم.
وقارن تاريخ السجل بمعلومات التوجيه وRPKI.
وافهم أي تفويض للاستخدام.
واحفظ الأدلة الداعمة.
السؤال المحوري ليس ببساطة:
مَن يظهر بجوار هذه البادئة اليوم؟
بل هو:
هل يمكن ربط حالة اليوم بسلسلة واضحة وقابلة للتحقق ومشروعة من التغييرات السابقة؟
كلما تقادمت موارد IPv4 وازدادت قيمتها وحركتها، ازدادت أهمية هذا التاريخ.
تخبرنا القيود الحالية الدقيقة أين يوجد المورد الآن.
ويخبرنا تاريخ التدقيق كيف وصل إلى هناك.
ويحتاج نظام موارد ترقيم الإنترنت القادر على الصمود إلى الاثنين معًا.
1. هل يمكنني فحص تاريخ نقل عنوان IPv4؟
في كثير من الحالات، نعم. تنشر سجلات الإنترنت الإقليمية أشكالًا مختلفة من بيانات نقل IPv4. ابدأ بتحديد البادئة والسجل الإقليمي الحالي، ثم راجع قيود النقل والمعلومات التاريخية المناسبة.
2. هل يعرض RDAP تاريخ نقل IPv4 كاملًا؟
ليس بالضرورة. يفيد RDAP أساسًا في معلومات التسجيل الحالية. وقد يلزم الحصول على معلومات النقل التاريخية من سجلات نقل منفصلة لدى السجلات الإقليمية أو من قيود تسجيل أخرى.
3. هل يثبت قيد النقل ملكية عنوان IP؟
يقدّم قيد النقل دليلًا على أن سجلًا اعترف بانتقال المورد. ولا ينبغي اعتباره تلقائيًا حسمًا شاملًا لكل مصلحة قانونية أو تجارية أو تشغيلية مرتبطة بالمورد.
4. هل يمكن نقل بادئة IPv4 أكثر من مرة؟
نعم. قد يُنقل المورد أكثر من مرة خلال دورة حياته.
5. هل يوضح النقل أين تُستخدم العناوين ماديًا؟
لا.
موقع السجل، وموقع الشركة، وتوجيه BGP، وتحديد الموقع الجغرافي لعنوان IP مفاهيم منفصلة.
شارك برأيك
سجّل الدخول بحساب موجود لتتمكن من التعليق.