[homenet] Artart last call review of draft-ietf-homenet-front-end-naming-delegation-22

Darrel Miller via Datatracker <noreply@ietf.org> Sun, 06 November 2022 10:33 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: homenet@ietf.org
Delivered-To: homenet@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 342D7C14F730; Sun, 6 Nov 2022 02:33:32 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Darrel Miller via Datatracker <noreply@ietf.org>
To: art@ietf.org
Cc: draft-ietf-homenet-front-end-naming-delegation.all@ietf.org, homenet@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.20.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <166773081220.63276.11714365327813560313@ietfa.amsl.com>
Reply-To: Darrel Miller <darrel.miller@microsoft.com>
Date: Sun, 06 Nov 2022 02:33:32 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/-g5zPy_mb5PkbZDhng6QhyhSaTk>
Subject: [homenet] Artart last call review of draft-ietf-homenet-front-end-naming-delegation-22
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.39
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 06 Nov 2022 10:33:32 -0000

Reviewer: Darrel Miller
Review result: Ready with Issues

Summary:

In general, this document was able to communicate its goals and approach, to
someone who is not familiar with the area. There are a number of grammatical
errors that make reading harder than it needs to be.  The biggest concern I
have with the document is that it raises the possibility that the objectives of
the document could be addressed using a "RESTful service" but then provides no
reasoning for why a DNS solution was chosen instead. As the authors noted,
existing DDNS implementations chose to use HTTP APIs rather than use dynamic
DNS update. Understanding the reasons behind this choice seems important before
defining a new mechanism based on DNS.

Major issues: N/A

Minor issues:
Section 1.3.2 says "A good way to provide the parameters would be the home
network be able to copy/paste a JSON object".  This does not seem like a good
experience for a home device.

Nits/editorial comments:

- Abbreviations such as CPE are used before being designed
- The phrase "The use cases are not limitations" in section 1.3 could benefit
from some clarification. - The document would benefit from a thorough editorial
review for language.