[art] 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: art@ietf.org
Delivered-To: art@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/art/PDXnM9p_Sgj9Th-1YI_Wp-tgJSs>
Subject: [art] Artart last call review of draft-ietf-homenet-front-end-naming-delegation-22
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-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.
- [art] Artart last call review of draft-ietf-homen… Darrel Miller via Datatracker
- Re: [art] Artart last call review of draft-ietf-h… Michael Richardson