[Last-Call] Secdir last call review of draft-ietf-rift-applicability-14

Watson Ladd via Datatracker <noreply@ietf.org> Thu, 18 April 2024 19:01 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 DBAB7C15153C; Thu, 18 Apr 2024 12:01:58 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Watson Ladd via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-rift-applicability.all@ietf.org, last-call@ietf.org, rift@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.10.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <171346691888.35849.11446635845987775680@ietfa.amsl.com>
Reply-To: Watson Ladd <watsonbladd@gmail.com>
Date: Thu, 18 Apr 2024 12:01:58 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/-mESk5CNpOct2ajh-NtdggMWx9s>
Subject: [Last-Call] Secdir last call review of draft-ietf-rift-applicability-14
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
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, 18 Apr 2024 19:01:59 -0000

Reviewer: Watson Ladd
Review result: Not Ready

I have completed the secdir review of draft-ietf-rift-applicability, part of
the secdir effort to review all documents progressing to this stage in the
IETF. These comments should be treated like any other in the the last call
process. The result of the review is not ready.

I used to think I knew broadly what networking was, then I read this document.
There's a fair number of terms that are new to me, and some more references
might help develop understanding. But that's a minor editorial point.

More concerning is the complete absence of discussion of security, choosing to
kick that to RIFT. That's despite a section about key management in the
document, as well as discussion of operational scenarios that have implications
for the choice of key management technology used. I'd like to see more here:
it's an opportunity to spell out security considerations applicable to the
scenarios with more specificity than in the RIFT drafts.

Sincerely,
Watson Ladd