[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?