Roman Danyliw's No Objection on draft-ietf-6man-rfc4941bis-11: (with COMMENT)
Roman Danyliw via Datatracker <noreply@ietf.org> Tue, 20 October 2020 20:48 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: ipv6@ietf.org
Delivered-To: ipv6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4539C3A0736; Tue, 20 Oct 2020 13:48:54 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-6man-rfc4941bis@ietf.org, 6man-chairs@ietf.org, ipv6@ietf.org, Ole Trøan <otroan@employees.org>, otroan@employees.org
Subject: Roman Danyliw's No Objection on draft-ietf-6man-rfc4941bis-11: (with COMMENT)
X-Test-IDTracker: no
X-IETF-IDTracker: 7.20.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <160322693425.32704.2984378163015793558@ietfa.amsl.com>
Date: Tue, 20 Oct 2020 13:48:54 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/TZYNdfxUm4Bbqg5tcqWUklHB_uI>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Oct 2020 20:48:54 -0000
Roman Danyliw has entered the following ballot position for draft-ietf-6man-rfc4941bis-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4941bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Ben Kaduk’s DISCUSS position around the need for clarity on what “statistically different” means (per Section 3). I also strongly concur with Ben’s guidance on the construction of the RID in Section 3.3.1 ** Section 3.*. The guidance uses the language of “deprecate”. This to me would suggest some notion of state being kept where I know I’ve used an address before and I won’t use it again. However, that doesn’t seem right here. ** Section 3.1. Per “it must be difficult for an outside entity …”, what’s the rough thinking on the workload for “difficult” or is there more precise language. I ask because Section 2.1 ** Section 3.3. The subsections present two different algorithms. Is there an MTI approach? ** Section 3.3.2. This section suggests that use of SHA-256, but is there normative guidance on an MTI algorithm? ** Section 3.3.2. If the hash algorithm output length exceeds the needed identifier length, how should truncations be handled? ** Editorial -- Section 1.2. Nit. For consistency, s/on-link/on path/
- Roman Danyliw's No Objection on draft-ietf-6man-r… Roman Danyliw via Datatracker
- Re: Roman Danyliw's No Objection on draft-ietf-6m… Fernando Gont