Re: [Int-area] [dhcwg] WGLC started -- draft-ietf-homenet-naming-architecture-dhc-options-12

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 05 May 2021 19:10 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F30E3A1D3F; Wed, 5 May 2021 12:10:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1_VPCWoP9Is; Wed, 5 May 2021 12:10:34 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F9F23A1D3E; Wed, 5 May 2021 12:10:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id C8E3A39ED5; Wed, 5 May 2021 15:19:07 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id M6L0c3AdrN_R; Wed, 5 May 2021 15:19:06 -0400 (EDT)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id A8C1B39ED0; Wed, 5 May 2021 15:19:06 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1CF3E196F; Wed, 5 May 2021 15:10:31 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Ted Lemon <mellon@fugue.com>
cc: "Bernie Volz (volz)" <volz=40cisco.com@dmarc.ietf.org>, "STARK, BARBARA H" <bs7652@att.com>, "homenet@ietf.org" <homenet@ietf.org>, "dhcwg@ietf.org" <dhcwg@ietf.org>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>, "int-area@ietf.org" <int-area@ietf.org>
In-Reply-To: <DC8B3D00-DCED-4556-866C-58789126556E@fugue.com>
References: <BN7PR11MB25479A9DA04F1D961A2A33ADCF599@BN7PR11MB2547.namprd11.prod.outlook.com> <8746.1620229451@localhost> <DC8B3D00-DCED-4556-866C-58789126556E@fugue.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Wed, 05 May 2021 15:10:31 -0400
Message-ID: <9020.1620241831@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/KTVgNYqBy_BVZpJI3bk0llUU88Y>
Subject: Re: [Int-area] [dhcwg] WGLC started -- draft-ietf-homenet-naming-architecture-dhc-options-12
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 May 2021 19:10:39 -0000

Ted Lemon <mellon@fugue.com> wrote:
    > On May 5, 2021, at 11:44 AM, Michael Richardson <mcr+ietf@sandelman.ca>
    > wrote:
    >> The end user might suffer slightly by having locally served reverse
    >> names that are no longer connected: they should obsolete that zone
    >> when they realize that their PD hasn't been renewed, until such time,
    >> (if it was a flash renumber), they would be right to think that they
    >> legitimately control them.

    > In practice I don’t think this is an issue. The reverse lookup is
    > usually triggered by receipt of a message from an IP address, so as
    > long as the IP address is still in use internally, the presence of the
    > reverse zone is wanted. When the address changes, the old zone becomes
    > obsolete whether it continues to be served or not. The likelihood of
    > the zone being re-allocated to some other network for which the
    > original network will then do a reverse lookup is very small, so I
    > don’t think there’s any reason to be concerned about this.

I agree with you completely.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide