[Last-Call] Artart last call review of draft-ietf-homenet-naming-architecture-dhc-options-21

Bron Gondwana via Datatracker <noreply@ietf.org> Wed, 05 October 2022 06:39 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 4674BC14F728; Tue, 4 Oct 2022 23:39:33 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Bron Gondwana via Datatracker <noreply@ietf.org>
To: art@ietf.org
Cc: draft-ietf-homenet-naming-architecture-dhc-options.all@ietf.org, homenet@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.17.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <166495197328.13357.10855384475504686703@ietfa.amsl.com>
Reply-To: Bron Gondwana <brong@fastmailteam.com>
Date: Tue, 04 Oct 2022 23:39:33 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/uzRP1Y53utREd2PXWIOHQe2y2_E>
Subject: [Last-Call] Artart last call review of draft-ietf-homenet-naming-architecture-dhc-options-21
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: Wed, 05 Oct 2022 06:39:33 -0000

Reviewer: Bron Gondwana
Review result: Ready with Nits

Thanks to the authors for this, and apologies for a slightly delayed review.

I read this document and skim-read the linked
draft-ietf-homenet-front-end-naming-delegation which describes why these fields
might want to be provided by DHCPv6.

I found this document clear and easy to read - there were no nits that stood
out to me other than the double-definition of the "Supported Transport" field. 
While there is a chicken-and-egg problem, the RFC editor and IANA could be
instructed to link things up such that section 4 immediately named the registry
to look up the values in rather than hard-coding an initial table into this
document, and having future readers reach this section without finding the
pointer to IANA in the natural place.

Likewise once the values are assigned by IANA for the DHCP option codes,
putting them directly into this document in the spots where a reader would
naturally be looking would help implementations.

Overall - this document has a very long history - well done for sticking with
it.  I hope one day to buy a product which uses the end result of this work and
transparently configures MY home network!