[regext] Secdir last call review of draft-ietf-regext-epp-eai-12
Chris Lonvick via Datatracker <noreply@ietf.org> Mon, 13 June 2022 00:48 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: regext@ietf.org
Delivered-To: regext@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B5AC157B35; Sun, 12 Jun 2022 17:48:12 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Chris Lonvick via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-regext-epp-eai.all@ietf.org, last-call@ietf.org, regext@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.3.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <165508129253.14230.7213126475579121692@ietfa.amsl.com>
Reply-To: Chris Lonvick <lonvick.ietf@gmail.com>
Date: Sun, 12 Jun 2022 17:48:12 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/N1SaJGKr42X6kcO4tFxBFbrWzCI>
Subject: [regext] Secdir last call review of draft-ietf-regext-epp-eai-12
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Jun 2022 00:48:12 -0000
Reviewer: Chris Lonvick Review result: Has Issues Hello, 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 that it has issues. The document is well written and the Security Considerations seems appropriate. However, there is insufficient guidance given regarding when the EAI functional extension is negotiated, but when the server cannot satisfy the required obligations. The specification says that when the client and server negotiate the EAI functional specification that, "implies the possibility to process the EAI address". The draft needs to specify what happens if the client and server negotiate the EAI functional extension, but when the server cannot fulfill its obligations to provide the required information, or when the client cannot process the received information. This may be easily fixed by saying in the specification that the server will only accept the negotiation if it can (MUST) provide the required information specified in section 5.3.1 and that the client can (MUST) accept and act upon that received information. The specification should also go on to say what MUST happen if those conditions are not met. Best regards, Chris
- [regext] Secdir last call review of draft-ietf-re… Chris Lonvick via Datatracker
- Re: [regext] Secdir last call review of draft-iet… Gould, James
- Re: [regext] Secdir last call review of draft-iet… Gould, James
- Re: [regext] Secdir last call review of draft-iet… Gould, James