[sipcore] Secdir last call review of draft-ietf-sipcore-multiple-reasons-01

Joseph Salowey via Datatracker <noreply@ietf.org> Thu, 29 September 2022 20:46 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: sipcore@ietf.org
Delivered-To: sipcore@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE741C1522D9; Thu, 29 Sep 2022 13:46:37 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Joseph Salowey via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-sipcore-multiple-reasons.all@ietf.org, last-call@ietf.org, sipcore@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.17.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <166448439782.48363.7718802219117889444@ietfa.amsl.com>
Reply-To: Joseph Salowey <joe@salowey.net>
Date: Thu, 29 Sep 2022 13:46:37 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/iV_dRcMNmhmwT1y3rwA4xKff7X4>
Subject: [sipcore] Secdir last call review of draft-ietf-sipcore-multiple-reasons-01
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.39
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Sep 2022 20:46:37 -0000

Reviewer: Joseph Salowey
Review result: Ready

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The summary of the review is Ready

I have one question.  The document takes a field that previously held one
reason and allows to hold multiple reasons. Since this behavior is only allowed
for protocols that define multiple reasons, it seems the exposure to existing
implementations would be small, however it's possible that this behavior will
leak into some existing cases. Do we have any implementation experience as to
what existing implementations will do if the receive multiple reasons that they
do not expect?

Thanks,

Joe