عاد نظام التدقيق فوجد الوتيرة الجديدة، لا سببها

الخلاصة

• تسمح المراجعة 18 من مسودة NETCONF للاشتراك المتكيّف بأن يختار الناشر فترة إرسال وفق تعبيرات XPath متنافية، تُقيّم بوتيرة يحددها المشترك أو الخادم.
• لا يجوز إسقاط إشعار adaptive-period-update أو حجبه عن المستقبلين المتأثرين الموجودين على الخط، لكن لا يجوز أيضاً تخزينه في مخازن الإعادة.
• يستطيع جامع يعود بعد الانقطاع أن يستعيد محتوى القياس من دون أن يستعيد حدث التحكم الذي غيّر وتيرته؛ لذلك لا يثبت غياب الإشعار من الإعادة أن التبديل لم يحدث.
• تقييم الشرط، وتبديل الفترة، وحدّ الجدولة التالي، وتسليم البيانات، ومعالجة العميل أحداث مستقلة زمنياً؛ التدفق الأسرع لا يجعلها حدثاً واحداً.
• المسودة في طابور محرر RFC للنشر التجريبي، لكنها ما زالت Internet-Draft بلا رقم RFC. والنموذج الأولي المذكور إفادة من مساهم لا دليلاً مستقلاً على التشغيل البيني.

سؤال المدقق بعد انقضاء الجلسة

المشهد الأصعب ليس لحظة التبديل، بل صباح اليوم التالي. يرى فريق الحوادث أن الاشتراك كان يرسل كل عشر دقائق ثم صار يرسل كل عشر ثوان. يسأل: ما القيمة التي عبرت العتبة، وأي قاعدة كانت نافذة، ومتى عرف الخادم، ومن تلقى الإشعار؟

تقدّم المسودة جزءاً دقيقاً من الإجابة أثناء الاتصال. يربط eval-expression عقدة بيانات بفترة تقرير. ويحدد eval-interval عدد مرات تقييم XPath. إذا غاب هذا الحقل، يختار الخادم أقل فاصل يستطيع دعمه، وقد يتغير ذلك الاختيار مع ضغط المعالج أو الذاكرة. وعندما يصبح التعبير صحيحاً، ينتقل الناشر إلى الفترة المرتبطة به.

لكن المحتوى لا يخرج بالضرورة في لحظة التقييم. تظل الحدود الدورية محسوبة من period وanchor-time. يمكن أن تتغير قيمة الجهاز أولاً، ثم يراها التقييم اللاحق، ثم يدخل التبديل حيز التنفيذ، ثم يصل أول تحديث على حد الجدولة التالي. period-update-time، عند وجوده، يصف وقت التبديل؛ لا يحوّل القياس المتقطع إلى مراقبة مستمرة.

لهذا لا يجوز لنظام التدقيق أن يستنتج من أول حزمة سريعة زمن عبور العتبة. ما يراه هو أثر لاحق لقرار ذي ساعة مختلفة.

تعبير XPath هو قاعدة تشغيل

لا يغيّر تعبير التقييم مرشح المحتوى، ولا يولّد بنفسه تحديث بيانات. وظيفته اختيار الفترة. يفصل ذلك بين سؤالين: ماذا يرسل الاشتراك، وكم مرة يرسله. والفصل مفيد، لكنه يعني أن صحة البيانات المرئية لا تثبت صحة منطق اختيار الوتيرة.

هناك أيضاً حد عددي. تستخدم XPath 1.0 أرقاماً بدقة مضاعفة وفق IEEE 754. لا يمكن تمثيل بعض قيم int64 وuint64 وdecimal64 تمثيلاً دقيقاً. وقد يكون التعبير صحيح البنية لكنه غالي التنفيذ، أو غير مدعوم، أو مختلفاً عند الحافة عما تصوره المشغل. لذلك توصي المراجعة 18 بمجموعة عقد صغيرة، وتوافق أنواع البيانات، وثوابت عددية واضحة.

يجب أن تكون الشروط المتعددة في التكوين الواحد متنافية. يستطيع الخادم رفض تعارض عبر multi-xpath-criteria-conflict، أو رفض فاصل تقييم لا يستطيع الحفاظ عليه، أو رفض صيغة XPath غير مدعومة. القبول إيصال قدرة محلي: هذا الناشر قبل هذه السياسة الآن. وهو ليس شهادة بأن العتبة جيدة، ولا بأن الخادم سيحافظ على وتيرة التقييم نفسها تحت الضغط.

حذف عقدة الهدف يجعل الشرط كاذباً، وتحوَّل نتائج XPath غير المنطقية وفق دالة boolean(). هذان التفصيلان مهمان في التحقيق؛ فاختفاء القياس ليس بالضرورة عبوراً معاكساً للعتبة، والتحويل الضمني قد يختلف عن اللغة التي كتب بها دفتر التشغيل.

إيصال حي لا يدخل الأرشيف

يحتوي adaptive-period-update على معرّف الاشتراك والفترة الجديدة، وقد يضم وقت التبديل والبيانات التي حققت الشرط ومرشح المحتوى. تنص المسودة على أنه لا يجوز إسقاط هذا الإشعار أو ترشيحه، وأنه يذهب إلى المستقبلين المتأثرين. هذه خصائص قوية لإيصال حي.

ثم تضع حداً واضحاً: لا يجوز حفظ الإشعار في مخازن الإعادة. منطق المسودة مفهوم؛ هذا حدث حالة للاشتراك الحي، وليس جزءاً عادياً من محتوى القياس القابل للإعادة. لكن النتيجة التشغيلية لا تختفي. إذا انفصل المستقبل قبل التبديل وعاد بعده، يمكنه الحصول على سجل محتوى لا يحتوي السطر الذي يشرح لماذا تغيّرت كثافته.

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

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

الكثافة ليست اكتمالاً

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

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

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

حالة معيارية من دون مبالغة

تضع Datatracker المراجعة 18 في طابور محرر RFC باتجاه نشر تجريبي. النسخة المؤرشفة مؤرخة في 22 أبريل 2026، وما زالت تحمل صفة Internet-Draft. الطابور دليل على تقدم الإجراء، لا رقم RFC ولا إثبات نجاح التجربة في الإنتاج.

يسرد قسم حالة التنفيذ نموذجاً أولياً واحداً قدمه مساهم لقياس شبكة Wi-Fi جامعية. تنص الوثيقة نفسها على أن القوائم ليست اعتماداً من IETF ولم تُتحقق منها جهة مستقلة. الإفادة تثبت أن مساهم أبلغ عن شيفرة عاملة؛ لا تثبت تغطية XPath العامة أو الاستعادة أو التشغيل البيني بين الموردين أو الاستقرار تحت الحمل.

القيمة الحالية أضيق وأكثر عملية: للمشترك والناشر عقد تجريبي محدد، بأخطاء مسماة ورسالة تبديل مرئية. أما سلسلة الدليل التي تبقى بعد الجلسة، فعلى التنفيذ والتشغيل أن يبنياها.