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.