Re: [DNSOP] [Ext] Re: Deprecating infrastructure .INT domains
Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Sun, 14 November 2021 12:50 UTC
Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
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 73F9F3A0970 for <dnsop@ietfa.amsl.com>; Sun, 14 Nov 2021 04:50:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.75
X-Spam-Level:
X-Spam-Status: No, score=-3.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-1.852, SPF_HELO_NONE=0.001, SPF_NONE=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 42WeoIL513Jq for <dnsop@ietfa.amsl.com>; Sun, 14 Nov 2021 04:50:48 -0800 (PST)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 503CB3A096F for <dnsop@ietf.org>; Sun, 14 Nov 2021 04:50:46 -0800 (PST)
Received: (qmail 70855 invoked from network); 14 Nov 2021 12:48:10 -0000
Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 14 Nov 2021 12:48:10 -0000
Message-ID: <6306c467-8ee8-65a3-e96c-f697ceb3cf81@necom830.hpcl.titech.ac.jp>
Date: Sun, 14 Nov 2021 21:50:41 +0900
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0
Content-Language: en-US
To: Kim Davies <kim.davies@iana.org>, dnsop@ietf.org
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> <YY7caBqlX2Wfswrc@KIDA-9190.local>
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
In-Reply-To: <YY7caBqlX2Wfswrc@KIDA-9190.local>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/BkFpGtAR_CaPoJvm4zxkHglqvcI>
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: Sun, 14 Nov 2021 12:50:51 -0000
Kim Davies wrote: >> 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. No, they are my comments on a possible separate document definitely *not* *against* your ID. So, don't modify your ID for them only to introduce weasel wording, please. I merely think your draft can be better if it better clarifies that the decisions are made by not IETF but IANA/ICANN, which should be *already* accepted by the Internet community including IETF. > (RFC 2860 does define the relationship between IETF > and IANA But, the rfc says deprecation of some domain under "int" must be decided by not IANA but IETF, which the Internet community including IETF is not practical, which should result in your ID. > but the role of .INT was modified as a consequence of RFC > 3172) Rfc3172 certainly, though silently, assumes such consequences, rfc2860 requires IETF, not IANA, should make them loudly explicit. But, as the issues are highly operational for which IETF do not and should not have much to do with, if something is wrong, it should be rfc2860. Moreover, as IETF is not governing the operational reality of the Internet, I don't think it necessary to modify rfc2860 before making your ID an up-to-date informational rfc to reflect the operational reality. Masataka Ohta PS To accommodate operational reality, I think, IANA functionalities should be divided by three, one for domain name under ICANN, another for IP addresses under operators community of RIRs and remaining inoperational ones for IETF/ISOC, which, for formality, requires modifications to rfc2860. But, don't interpret it as my objection to your ID. We must move on.
- [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