Re: [DNSOP] [Ext] Re: Deprecating infrastructure .INT domains
Kim Davies <kim.davies@iana.org> Fri, 12 November 2021 21:28 UTC
Return-Path: <kim.davies@iana.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAAD83A1216 for <dnsop@ietfa.amsl.com>; Fri, 12 Nov 2021 13:28:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 NLgEUaHqfG4s for <dnsop@ietfa.amsl.com>; Fri, 12 Nov 2021 13:28:10 -0800 (PST)
Received: from smtp.lax.icann.org (smtp.lax.icann.org [192.0.33.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDD443A120A for <dnsop@ietf.org>; Fri, 12 Nov 2021 13:28:10 -0800 (PST)
Received: from KIDA-9190.local (unknown [10.32.63.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: kim.davies@smtp.lax.icann.org) by smtp.lax.icann.org (Postfix) with ESMTPSA id DB754E0F98; Fri, 12 Nov 2021 21:28:09 +0000 (UTC)
Date: Fri, 12 Nov 2021 13:28:08 -0800
From: Kim Davies <kim.davies@iana.org>
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Cc: Joe Abley <jabley@hopcount.ca>, dnsop@ietf.org
Message-ID: <YY7caBqlX2Wfswrc@KIDA-9190.local>
References: <9376d93c-becb-b7a8-1602-adbecccae99a@necom830.hpcl.titech.ac.jp> <357A4865-3BE1-453E-85A2-EF47BA0A0D25@hopcount.ca> <49d7a00b-28d5-fbe5-3cd1-531aeb1f323c@necom830.hpcl.titech.ac.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <49d7a00b-28d5-fbe5-3cd1-531aeb1f323c@necom830.hpcl.titech.ac.jp>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/eBhTEafd5xbeE4hrDiz7ZTGyRWQ>
Subject: Re: [DNSOP] [Ext] Re: Deprecating infrastructure .INT domains
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Nov 2021 21:28:16 -0000
Quoting Masataka Ohta on Friday November 12, 2021: > > > The operational decisions relating to these things have already been > > made, as I understand it -- the delegations no longer exist. Kim and > > Amanda's document seems to have two purposes: (1) to document this > > operational reality, and (2) to update protocol specifications to > > reflect that operational reality. > > I'm afraid (1) should be documented by a separate rfc maybe titled > as "Relationship between IETF and IANA", which should clarify > semantics of "IANA considerations" section of not only this but > also other rfcs, which was not a problem when both of the rfc > editor and IANA was the same person. > > Is the "IANA considerations" section just a recommendation from > IETF/ISOC to IANA/ICANN or approved by IANA/ICANN during *modified* > standardization process of IETF? These are fair points and hopefully the language can be tweaked to make it a little clearer. (RFC 2860 does define the relationship between IETF and IANA, but the role of .INT was modified as a consequence of RFC 3172) Most of the names in the draft were in the zone when we started the inventory process a couple of years ago. For those that were lame for over a year we removed them from the zone because they were already functionally inoperable. For the remaining two that are in there, there doesn't appear to be any sign that they are currently configured to operate as documented. Specifically, {1..9}.tpc.int and {0..9,a..f}.nsap.int all return NXDOMAIN. Even if we are perhaps duly empowered to make such an operational decision regarding these delegations, producing this draft and gaining additional consensus on these actions I think will produce a better result given the original delegations eminated from IETF work. kim
- [DNSOP] Deprecating infrastructure .INT domains Kim Davies
- Re: [DNSOP] Deprecating infrastructure .INT domai… Joe Abley
- Re: [DNSOP] Deprecating infrastructure .INT domai… Bob Bownes -Seiri
- Re: [DNSOP] Deprecating infrastructure .INT domai… Petr Špaček
- Re: [DNSOP] Deprecating infrastructure .INT domai… Tim Wicinski
- Re: [DNSOP] Deprecating infrastructure .INT domai… Masataka Ohta
- Re: [DNSOP] Deprecating infrastructure .INT domai… Joe Abley
- Re: [DNSOP] Deprecating infrastructure .INT domai… Masataka Ohta
- Re: [DNSOP] Deprecating infrastructure .INT domai… Stephane Bortzmeyer
- Re: [DNSOP] [Ext] Re: Deprecating infrastructure … Kim Davies
- Re: [DNSOP] [Ext] Re: Deprecating infrastructure … Masataka Ohta