[Last-Call] Opsdir last call review of draft-ietf-dots-rfc8782-bis-01

Dan Romascanu via Datatracker <noreply@ietf.org> Thu, 12 November 2020 11:19 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: last-call@ietf.org
Delivered-To: last-call@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5EB3A15D3; Thu, 12 Nov 2020 03:19:29 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Dan Romascanu via Datatracker <noreply@ietf.org>
To: ops-dir@ietf.org
Cc: last-call@ietf.org, draft-ietf-dots-rfc8782-bis.all@ietf.org, dots@ietf.org, dromasca@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.22.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <160517996946.10959.4421104962013499250@ietfa.amsl.com>
Reply-To: Dan Romascanu <dromasca@gmail.com>
Date: Thu, 12 Nov 2020 03:19:29 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/T6i4cRxyoaDBv-4Q3cZi8ZY0T7U>
Subject: [Last-Call] Opsdir last call review of draft-ietf-dots-rfc8782-bis-01
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Nov 2020 11:19:30 -0000

Reviewer: Dan Romascanu
Review result: Has Issues

This document specifies the Distributed Denial-of-Service Open Threat Signaling
(DOTS) signal channel, a protocol for signaling the need for protection against
Distributed Denial-of-Service (DDoS) attacks to a server capable of enabling
network traffic mitigation on behalf of the requesting client. The DOTS data
channel is defined in an associated document. The document updates RFC 8872.

The document is almost Ready from an OPS perspective, but there are a couple of
issues worth clarification before approval.

1. Appendix A describes the changes from RFC 8782. I could not find however any
information in the document concerning backwards compatibility and the path of
upgrade that an operator should be aware about when migrating an existing
client, server or the whole network from RFC 8782 support. If I missed it,
please point and maybe detail this information in the Appendix. If not, it
would be useful to add.

2. I could not find any information about the supplementary overload that the
changes in signaling brought by this update may bring. If such an analysis was
made, it would be useful to mention its results. No significant extra-load is
fine. If anything different, it would be useful to add more details.