[Last-Call] Secdir last call review of draft-ietf-6man-rfc6874bis-02
Leif Johansson via Datatracker <noreply@ietf.org> Tue, 27 September 2022 07:35 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 6474AC1524B0; Tue, 27 Sep 2022 00:35:27 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Leif Johansson via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-6man-rfc6874bis.all@ietf.org, ipv6@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.17.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <166426412740.9727.14113052995276684864@ietfa.amsl.com>
Reply-To: Leif Johansson <leifj@sunet.se>
Date: Tue, 27 Sep 2022 00:35:27 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/2gNvLFcNWGh6zhMWuvb44jBfNKY>
Subject: [Last-Call] Secdir last call review of draft-ietf-6man-rfc6874bis-02
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: Tue, 27 Sep 2022 07:35:27 -0000
Reviewer: Leif Johansson Review result: Has Nits 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. In summary: one issue Overall the document seems ok and well written to me but for one thing: the lack of normative language in section 4. The explanation that this is because of a lack of clear behavioral distinction between browser input boxes and URI parsers seems a bit weak to me. I don't understand why it isn't desirable to write down normative language for the behavior of one of these cases (URI parsers) even if the other (input boxes) can't be specified. This phrasing caught my eye: "It is desirable for all URI parsers to recognise a zone identifier according to the syntax defined in Section 3." Since the bulk of the I-D is in section 3, why not make this normative language along the lines of "URI parsers implementing this specification MUST recognize zone identifiers according to the syntax in section 3."? The fact that not all browsers choose to do so is a separate issue. Also this: "It is desirable for all URI parsers to recognise a zone identifier according to the syntax defined in Section 3.". We already know this is not the case but isn't it better to have a document that clearly defines the behavior for those browsers who choose to implement this I-D?
- [Last-Call] Secdir last call review of draft-ietf… Leif Johansson via Datatracker
- Re: [Last-Call] Secdir last call review of draft-… Brian E Carpenter
- Re: [Last-Call] Secdir last call review of draft-… Leif Johansson