[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].
- [homenet] Roman Danyliw's No Objection on draft-i… Roman Danyliw via Datatracker