[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
- [sipcore] Secdir last call review of draft-ietf-s… Joseph Salowey via Datatracker
- Re: [sipcore] Secdir last call review of draft-ie… Robert Sparks
- Re: [sipcore] Secdir last call review of draft-ie… Joseph Salowey