IETF Logo Mail Archive

Re: [auth48] [AD] AUTH48: RFC-to-be 9526 <draft-ietf-homenet-front-end-naming-delegation-27> for your review

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 13 January 2024 20:51 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4BFC14F5FC; Sat, 13 Jan 2024 12:51:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcWrtgoj-p5B; Sat, 13 Jan 2024 12:51:07 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00:e000:2bb::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79915C14F5F5; Sat, 13 Jan 2024 12:51:07 -0800 (PST)
Received: from dyas.sandelman.ca (unknown [IPv6:2001:18c0:3a2:7500:ac05:3ed3:c598:7521]) by relay.sandelman.ca (Postfix) with ESMTPS id E21691F455; Sat, 13 Jan 2024 20:51:04 +0000 (UTC)
Authentication-Results: relay.sandelman.ca; dkim=pass (2048-bit key; secure) header.d=sandelman.ca header.i=@sandelman.ca header.b="GNGHfpzV"; dkim-atps=neutral
Received: by dyas.sandelman.ca (Postfix, from userid 1000) id 24CAEA0B7F; Sat, 13 Jan 2024 15:50:46 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sandelman.ca; s=dyas; t=1705179046; bh=F2K44YHysOtMAhIe9xPz3WOykWe+7jvs0+HRwk4IRHg=; h=From:To:cc:Subject:In-reply-to:References:Date:From; b=GNGHfpzVRZPoLTA1fn4l2Fwwx37G7mmkS2+0ta0VuhOHEHpfCoO8LcDQaVQZIJlWI 0BuOVupCDjmfSdTVBfXFUKDm60IUssQexyO6rflv8gLDs8m/BtuqkJvdSK7gVUO5Dc yGbAihxDDIRQKyadsyp4uJ9J01C6X3VGQlDbPHocqpxi0D0RbxobhXresQQVd/12AI IBOs/+IM3qbuJXKo+5rS36qZYaQRsx7bzxNYNO1dWTl6xJJDN9ay0l8HakJsFP8pTX K6goWv8Xnf//fVgJJy875tiEsYKUsDW1StIaILAHzqfN4zipLA//B6uMms5+y/t1Mh ouLgJ5GkgChcQ==
Received: from dyas (localhost [127.0.0.1]) by dyas.sandelman.ca (Postfix) with ESMTP id 213E8A0B7D; Sat, 13 Jan 2024 15:50:46 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
cc: Karen Moore <kmoore@amsl.com>, Daniel Migault <daniel.migault@ericsson.com>, "ralf.weber@nominum.com" <ralf.weber@nominum.com>, "v6ops@globis.net" <v6ops@globis.net>, "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>, "homenet-ads@ietf.org" <homenet-ads@ietf.org>, "homenet-chairs@ietf.org" <homenet-chairs@ietf.org>, "stephen.farrell@cs.tcd.ie" <stephen.farrell@cs.tcd.ie>, "auth48archive@rfc-editor.org" <auth48archive@rfc-editor.org>
In-reply-to: <BE845CEE-E339-46BB-A116-759F3FA15610@cisco.com>
References: <20231219055759.80A9885416@rfcpa.amsl.com> <DM6PR15MB3689F4248A1BDCD5FA61E12CE397A@DM6PR15MB3689.namprd15.prod.outlook.com> <144FAC4B-8B12-4A92-A139-91A6E50EC6D6@amsl.com> <DM6PR15MB3689833B2313E8D6E4DE665CE396A@DM6PR15MB3689.namprd15.prod.outlook.com> <87FF52A0-14B7-4BE3-ABAA-707B0EB3A655@amsl.com> <06EE6281-0B2A-4762-BF1A-FD1709BED8AF@amsl.com> <69B7322C-C5C0-4434-92DC-9DA063D863E6@amsl.com> <BE845CEE-E339-46BB-A116-759F3FA15610@cisco.com>
Comments: In-reply-to "Eric Vyncke (evyncke)" <evyncke@cisco.com> message dated "Fri, 12 Jan 2024 16:23:19 +0000."
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Sat, 13 Jan 2024 15:50:46 -0500
Message-ID: <1775151.1705179046@dyas>
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/UuRHLvvo57oFUOQ1G39V2f6t44E>
Subject: Re: [auth48] [AD] AUTH48: RFC-to-be 9526 <draft-ietf-homenet-front-end-naming-delegation-27> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Jan 2024 20:51:11 -0000

Eric Vyncke (evyncke) <evyncke@cisco.com> wrote:
    > About section 2, I find the new text a little confusing... I.e., the
    > text ***Note that when "DNS Resolver" is used in this document, it
    > refers to "DNS or DNSSEC Resolver"*** is just before ***DNS
    > Resolver:***. Should it be after the DNS resolver item?

That seems like a reasonable tweak.

    > Still on section 2, s/While the resolver does not necessarily perform
    > DNSSEC resolutions, it is expected that DNSSEC is enabled/While the
    > resolver does not necessarily perform DNSSEC resolutions, it is
    > *RECOMMENDED* that DNSSEC *validation* is enabled/ ?

I admit that re-reading the sentence, I have no idea what it means.
What is DNSSEC resolution vs validation vs "enabled"?

    > About section 10, I am fine for using more bits in the leading 64
    > bits. Now, are we sure that "DHCPv6 or PPP" is not enough ? I.e., s/by
    > DHCPv6 or PPP *and Router Advertisement (RA)*/by DHCPv6 or PPP/

Yes.  It could also way, "PPP with Router Advertisement".
I agree with your change (or mine).

    > About section 14.1, I am fine with the "MUST NOT".

good.


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*

v2.23.0 | Report a Bug | By Email