[homenet] Murray Kucherawy's Discuss on draft-ietf-homenet-front-end-naming-delegation-25: (with DISCUSS and COMMENT)

Murray Kucherawy via Datatracker <noreply@ietf.org> Sat, 31 December 2022 00:16 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 5443CC1516E4; Fri, 30 Dec 2022 16:16:30 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Murray Kucherawy via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-homenet-front-end-naming-delegation@ietf.org, homenet-chairs@ietf.org, homenet@ietf.org, stephen.farrell@cs.tcd.ie
X-Test-IDTracker: no
X-IETF-IDTracker: 9.4.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Murray Kucherawy <superuser@gmail.com>
Message-ID: <167244579033.23388.14421796396511638477@ietfa.amsl.com>
Date: Fri, 30 Dec 2022 16:16:30 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/p0akb2tukYGY0OQMg93nqLAVJRo>
Subject: [homenet] Murray Kucherawy's Discuss on draft-ietf-homenet-front-end-naming-delegation-25: (with DISCUSS and COMMENT)
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: Sat, 31 Dec 2022 00:16:30 -0000

Murray Kucherawy has entered the following ballot position for
draft-ietf-homenet-front-end-naming-delegation-25: Discuss

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

According to the shepherd writeup (and assuming it still reflects reality
today; it's dated July of this year, nine revisions ago), there are no
implementations, and none are planned.  There's no Implementation Status
section either.  However, in the reply to Paul's earlier DISCUSS, there as a
claim that some part of this was implemented.  I've also been told there is one
vendor planning to implement this, but that doesn't match the record.  Can
someone clarify where we are today?  The existence of implementations would
certainly allay the previous concerns about complexity and clarity that were
expressed in other prior ballot positions.

This document has been in development for over 10 years.  Assuming there is no
wide deployment or an implementation to which one can refer, why are we
publishing this on the standards track?  Wouldn't Experimental or Informational
be more appropriate?  The shepherd writeup doesn't explain why Proposed
Standard is justified; it just says "PS".

(Please note that RFC 2026 says implementations aren't required, so I am not
requiring one either by posting this ballot.  I just want to have the
discussion.)


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for all the work that went into this, especially since its last pass
through the IESG.

I generally found this to be readable if I look at it as an applicability
statement (RFC 2026, Section 3.2) over DNS for the Homenet use case.  Was that
the intent, or am I way off?

Thanks to Darrel Miller for his ARTART review.  (A second review on the latest
revision is pending as I write this.)

The last bullet of Section 4.1.1 appears to be mangled in a few places.  Please
review.

I have my usual complaint about the use of SHOULD throughout the document:
SHOULD provides implementers with a choice, and generally the SHOULDs here
don't acknowledge that choice or provide implementers with any guidance about
when it might be appropriate to exercise that choice.  I suggest reviewing them
(there are 25, and 6 RECOMMENDEDs) and either adding such prose, or
reconsidering whether they should be MUST or MAY.