[homenet] Roman Danyliw's No Objection on draft-ietf-homenet-naming-architecture-dhc-options-21: (with COMMENT)

Roman Danyliw via Datatracker <noreply@ietf.org> Thu, 20 October 2022 00:59 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 6BDCBC1526E0; Wed, 19 Oct 2022 17:59:20 -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-homenet-naming-architecture-dhc-options@ietf.org, homenet-chairs@ietf.org, homenet@ietf.org, stephen.farrell@cs.tcd.ie, stephen.farrell@cs.tcd.ie
X-Test-IDTracker: no
X-IETF-IDTracker: 8.18.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <166622756043.29904.4661157433826026513@ietfa.amsl.com>
Date: Wed, 19 Oct 2022 17:59:20 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/ws27TPGm2-y0DuEe_u-4jv1r0fs>
Subject: [homenet] Roman Danyliw's No Objection on draft-ietf-homenet-naming-architecture-dhc-options-21: (with 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: Thu, 20 Oct 2022 00:59:20 -0000

Roman Danyliw has entered the following ballot position for
draft-ietf-homenet-naming-architecture-dhc-options-21: 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/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-naming-architecture-dhc-options/



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

Thank you to Hilarie Orman for the SECDIR review.  This review has a list of
actionable comments the authors should consider.  In particular, see the
feedback on the framing of the Security Considerations language.

** Section 2.
  In addition, ISPs often identify the line of the home network with a
  name.

Is the referenced “line” here talking about the physical cable?  Should this
language generalized to capture fixed wireless technology?

** Section 2.

   Such name is used for their internal network management
   operations and is not a name the home network owner has registered
   to.

Could this be rephrased to explain the idea of a name “that the home network
owner hasn’t registered.”

** Section 3.

Note also that this is not
   mandatory and the DHCPv6 client may instruct remotely the HNA and the
   DHCPv6 either with a proprietary protocol or a protocol that will be
   defined in the future.

I had trouble parsing this sentence.  What is the proprietary protocol related
to DHCPv6?

** Section 3.

   This scenario is believed to be the most popular scenario

Is this statement based on deployment experience or speculative about how
deployments will be configured?  If the latter, this text should likely read:
“This scenario is believe to be the most popular scenario”?

** Section 3.  The steps in the scenario are numbered 1, 2, 1.  Is that an
error?  Maybe, 1, 2, 3.

** Section 3.
The HNA is authenticated (see Section 4.6 of
       [I-D.ietf-homenet-front-end-naming-delegation]) by the DM and the
       RDM.

As pointed out in the draft-ietf-homenet-front-end-naming-delegation ballot,
this authentication is not mandatory.

** Section 4.2.  Editorial.  Sentence doesn’t parse.

OLD
   It is worth noticing that the Supported Transport field does not
   enable to specify a port and the used port is defined by standard.
   In the case of DNS over TLS [RFC7858], the port is defined by
   [RFC7858] to be 853.

NEW
Note that the Supported Transport field does not enable the specification of a
port. The default port for the protocol identified by the Supported Transport
field is assumed.  In the case of DNS over TLS [RFC7858], the default port is
853 [RFC7858].