Dear Mohamed, Thank you for taking the time to review the OODA-HTTP proposal and for your insightful feedback. Please find below our responses, aligned with your thoughtful observations:
________________________________ "As currently written, it is not easy to assess what aspects you are seeking to standardize and what elements you think requires interoperability." You're absolutely right — we are currently refining the separation between the core protocol behaviors that require standardization and the architectural aspects that can remain implementation-specific. To clarify: Our primary standardization goal is the definition of a behavioral extension to HTTP, including a protocol mechanism for dynamic decision-making based on observed client behaviors, with coordination across TLS. The interoperability requirement arises in defining how behavioral scoring, decision triggers, and layered defense actions are exchanged or coordinated between endpoints, particularly across domains. ________________________________ "When it comes to operations, it is also not clear to me how this integrates with the secops practices out there and whether/what are the distortion you are introducing to the organization followed by operators." We deeply appreciate this operational perspective. Our goal is not to replace but rather to complement SecOps practices by embedding telemetry-driven, behavior-based decision hooks into the HTTP/TLS layer. Instead of introducing distortion, OODA-HTTP proposes: A dynamic threat scoring mechanism that adapts to evolving behavioral patterns. A layered structure compatible with SecOps workflows: pre-decision telemetry, decision triggers, and execution actions. Control interfaces (CLI or API) that allow human supervision and override, ensuring organizational alignment. We believe that automated reaction (such as key rotation, behavioral throttling) is a strategic addition to operational response frameworks — especially under fast-moving, AI- or bot-driven attack scenarios. ________________________________ "You may refer, for example, to https://datatracker.ietf.org/doc/rfc9244/ to see an example of a DDoS telemetry solution." Thank you for the reference — we've analyzed RFC 9244 thoroughly. We note with great interest the telemetry setup, mitigation strategy updates, and baseline traffic modeling in DOTS. Our design indeed draws inspiration from this model, with a few shifts: OODA-HTTP generalizes the telemetry model beyond volumetric DDoS to include behavioral deviation analysis, slow/stealth threats, and post-quantum patterns. We separate telemetry into three layers of configuration (what to observe, how to score, and how to act), which aligns well with the DOTS signal vs. data channel split. We envision future interoperability with DOTS, including a feedback loop from OODA decisions into DOTS telemetry (OODA→DOTS). ________________________________ "The use of X- constructs is not recommended per RFC 6648" Absolutely noted. The X-OODA-Action header was introduced in the early draft as a placeholder. We intend to remove the "X-" prefix in subsequent drafts once the header semantics are standardized. ________________________________ "There were discussion in the past about threat classification: standardizing those wasn't seen as an option" We fully agree. Threat classification in OODA-HTTP will remain abstract and implementation-agnostic. Our aim is to define a scoring and feedback framework, rather than fixed threat taxonomies. ________________________________ "You may look at Section 3.12.2 of RFC7970 for a classification that may help you to better define your 'Threat Score'" Thank you — RFC 7970 is indeed a useful reference. Our model will treat the threat score as a vector: Computed dynamically from real-time behavior, Extended locally (e.g., internal heuristics, AI scoring), Mapped if needed to public classifications for reporting (like STIX, ATT&CK, etc.). ________________________________ We appreciate your guidance, and we look forward to refining the proposal to better align with IETF expectations. Please let us know if we can share a draft version of the extended architecture or if you would prefer a brief discussion call. Warm regards, Rachid Bouziane Founder, SecRoot.io – OODA-HTTP Initiative _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
