Re: [Last-Call] Secdir last call review of draft-ietf-6man-rfc6874bis-02

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 27 September 2022 19:37 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DADADC15C51D; Tue, 27 Sep 2022 12:37:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qvbi71Z-NmaZ; Tue, 27 Sep 2022 12:37:55 -0700 (PDT)
Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68D91C159483; Tue, 27 Sep 2022 12:37:50 -0700 (PDT)
Received: by mail-pj1-x1033.google.com with SMTP id lx7so3825896pjb.0; Tue, 27 Sep 2022 12:37:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date; bh=KhPJKcQ8sk37EWzU9e5f+aGNrRpkDEIMwyU+M/5AGVo=; b=Gj+jyTNYFAlxROuzmD0CLwy9afgwN6Uc+J9JeI3cS9kizk0vKYYig/Upn6P60h3+r2 3ElMEFMspiL+3PhrLO/a7go3bSKu3v17N9FqjGbI60NNUSl+RjIWJdFXDKhYedvZlijy I+5t1iNTCwf8EmeBWjGdB6swcSfnkxQWDjmnfPFRJ6mgn3ihkVjOM3+fPKOQ4v+oaVBN QmwA+WuqzGOPg/swXFtPqh27kleTLUWpwmBPmRv21Kujlz6u1Yi0VRNZvbJk1u50RMs/ SAKaqQwB8ZPLxE+XTvAFx0xYPvpajM2iPZVH1fkNswVi4t0pxLD0QhBV4Y6sJVxH4rqo ml8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date; bh=KhPJKcQ8sk37EWzU9e5f+aGNrRpkDEIMwyU+M/5AGVo=; b=hiK+ZdUJhq1GWTf7XprhCjNYcXNPcfsIguPnX6LUKH7cw1slq0vqevZu9PAN7VgNZ/ jCvz16iUayGYmX/yGRS5Lm7QbtmPBL6S8R2xIlgaJEGRgGdW7oqgJ1KtahwigzlTw1T7 nCm8KFDP1dojn/vuhikmTZ50vN6qg/mkW5KDew9G1hQzGxJPMInTIzCn2O7JSSR3oV2F w9eFKv2tJ6DjsCkHWM7p1RNibrBbWszTg5ZCeI4i8VYwH5qYTYmHUsrdxMAs86IF+ZzJ aSrfpR5JjqTxIvRuheNANtX46HiSB66PTkZgYeaeCbswDQUUHxfV///kAmn7m0Dt5ZgD J5ow==
X-Gm-Message-State: ACrzQf0TY0zqwz5V6FoqrxZeCRfH7bobHfzcoo6HyQ7nEc+JRceyzGvR JYLvNZzDohinJiGfAvT3M58=
X-Google-Smtp-Source: AMsMyM5sxMex4Fm/YEcE41zhR/2MujQgiQv+QH8mtq8sYTzM6KgZExOdhkPew0mqGw/e1BZpEmGubw==
X-Received: by 2002:a17:902:ce03:b0:178:3ba6:f731 with SMTP id k3-20020a170902ce0300b001783ba6f731mr28699460plg.115.1664307469512; Tue, 27 Sep 2022 12:37:49 -0700 (PDT)
Received: from ?IPV6:2406:e003:1124:9301:80b2:5c79:2266:e431? ([2406:e003:1124:9301:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id l5-20020a170903120500b0017508d2665dsm1988084plh.34.2022.09.27.12.37.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Sep 2022 12:37:48 -0700 (PDT)
Message-ID: <37c7d0fb-2b2d-7b12-a914-9e377244fd77@gmail.com>
Date: Wed, 28 Sep 2022 08:37:43 +1300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0
Content-Language: en-US
To: Leif Johansson <leifj@sunet.se>, secdir@ietf.org
Cc: draft-ietf-6man-rfc6874bis.all@ietf.org, ipv6@ietf.org, last-call@ietf.org
References: <166426412740.9727.14113052995276684864@ietfa.amsl.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <166426412740.9727.14113052995276684864@ietfa.amsl.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/DVyu5cVHh-aLdEkXWBwHGF7k4hU>
Subject: Re: [Last-Call] Secdir last call review of draft-ietf-6man-rfc6874bis-02
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
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 19:37:56 -0000

Thanks Leif. We will certainly be changing the wording of that section
following the ART area review. It is a bit tricky to write strong
requirements for URI parsing, however, because there are so many
different approaches and the IETF is not the only standards organization
in that field.

Regards
    Brian Carpenter

On 27-Sep-22 20:35, Leif Johansson via Datatracker wrote:
> 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?
> 
> 
> 
>