Re: [Last-Call] Last Call: <draft-davies-int-historic-04.txt> (Deprecating infrastructure "int" domains) to Informational RFC

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 19 October 2022 22:56 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6082EC14F749 for <last-call@ietfa.amsl.com>; Wed, 19 Oct 2022 15:56:51 -0700 (PDT)
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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, 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=gmail.com
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 zL4Y8VFWZTnA for <last-call@ietfa.amsl.com>; Wed, 19 Oct 2022 15:56:46 -0700 (PDT)
Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 D3B8EC14F728 for <last-call@ietf.org>; Wed, 19 Oct 2022 15:56:46 -0700 (PDT)
Received: by mail-pl1-x634.google.com with SMTP id k9so18201206pll.11 for <last-call@ietf.org>; Wed, 19 Oct 2022 15:56:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=PW3MYlunsSkWvHT41LjpRfv8vzcR12ellne6hISXOJ4=; b=W7KTS+/DAzzguLWes4Dtqg6WHHR2cIJgcyc14olZqG9mjL4lZG7qgRz/DC8bDSmBz2 YVxCDpujoOwJX8yk81avNMn6zvfM/zvmP2zNUzMi7bSKkUB7CCoVsZPG71/98wpvSweO IUDhgIlg/k+AJAd4GXF4gxF3EuhOCzC2ZKpiuodZwwM/cno+FMCRz2kwup6RZ1qLKagN xMmoYa5H9Nb4sBrjAJ4dkCJGXJ1JGVZ+EQc0Wn+b2byETTdhvPx2eP/mBdyhigPIag5Q o+B/T+2kCZlfEK/0kp8r0DSlTYq7tTtVboZinEqViSd8eO0uj6s96xKZAUYa6TPVflnv zjBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=PW3MYlunsSkWvHT41LjpRfv8vzcR12ellne6hISXOJ4=; b=Vhplr+evAlIPmzStQuoEB9eilHxJnK2a06lbzxtU6LqKBS+sEjulDIbrLBkmr756o0 hAjy3TZ+0+8VxjR6Yhm8IVV3GaPsuMyvioMc6WpWI1n02goE/KdBS9YaDjVd14YPG/2U pb+5qB9NSIkjjxoPZNiXev8o2mTpIYsDjdlRFKYIufrUZ7EeMYrSncba1wOTNZqVdTyI +7F+SMzu/6xgbxkH+qW8tA6a9zaHSze2qHURQ9dCt6AnU+mK+VxyADCzCjqUhL3oR8nC suo8qI0+kQ654YoC707YyEoxVnn4Dw9U4LROhqhViVpMQHz395Mi8bf8QGQjcRntnjTS DpPA==
X-Gm-Message-State: ACrzQf1a1MLQQImi/i5e9tvsVicbkG2YLw89EyqMPdADoJz2SlVHUwXF 5QbJlyAJMRqPWOGcMBalg35+XuUVP3y61A==
X-Google-Smtp-Source: AMsMyM43RCr5tcebYTh5PKCEOv9yA9/Dcb8nxTqtmdKRGQaoBCd2wdunphOGRUS+GUepZOh7lvwIbg==
X-Received: by 2002:a17:903:2cf:b0:186:61b8:84d3 with SMTP id s15-20020a17090302cf00b0018661b884d3mr486973plk.34.1666220206271; Wed, 19 Oct 2022 15:56:46 -0700 (PDT)
Received: from ?IPV6:2406:e003:1124:9301:80b2:5c79:2266:e431? ([2406:e003:1124:9301:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id w14-20020a63fb4e000000b0041a6638b357sm10385469pgj.72.2022.10.19.15.56.44 for <last-call@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Oct 2022 15:56:45 -0700 (PDT)
Message-ID: <295948c3-b116-365f-a682-6e286be69ffb@gmail.com>
Date: Thu, 20 Oct 2022 11:56:41 +1300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0
Content-Language: en-US
To: last-call@ietf.org
References: <166621075802.44847.14382611991776479938@ietfa.amsl.com> <371922.1666215280@dyas> <Y1B7IPGPfzDcDDxE@faui48e.informatik.uni-erlangen.de>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <Y1B7IPGPfzDcDDxE@faui48e.informatik.uni-erlangen.de>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/VWD9Wog97xwd4U_GRHeUoVQ-7HY>
Subject: Re: [Last-Call] Last Call: <draft-davies-int-historic-04.txt> (Deprecating infrastructure "int" domains) to Informational RFC
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Oct 2022 22:56:51 -0000

Toerless,

Most of your comments are not IETF business; the whole point of this long
overdue action is to remove any remaining bit of IETF business from .int,
so that we can forget about it and leave all the metaphysics to ICANN.

I fully support both this draft and the accompanying deprecation of
RFC1706 and RFC1528. Time to move on.

Regards
    Brian Carpenter

On 20-Oct-22 11:33, Toerless Eckert wrote:
> a) Why does the draft say
> 
>    "intergovernmental organizations, which are organizations established by
>    international treaties between or among national governments
>    
>    when rfc1591 says:
>    
>    "organizations established by international treaties, (or international databases)"
>    
>    This seems to be an intentional different/refined wording. Why ?
> 
>    For example there are laws for treaties between international organiations,
>    aka: another layer of indirection, which in my reading would be covered by
>    rfc1591 but not the draft wording.
> 
> b) If we are going to want to refine the future use of .int (because
>    we want to be crisp about the purpose before passing it on to some operating
>    registry):
> 
>    Would https://en.wikipedia.org/wiki/Commonwealth_of_Nations be able to
>    get a .int domain ? The way i read wikipedia, there is no treaty involved,
>    but it is an association and formalized through a declaration
>    and later a statue. Or does this rightfully not deserve a .int domain
>    because it does not have the right (treaty) paperwork (and the DNS has the wrong
>    order for the brits anyhow ;-) ?
> 
>    Aka: if we have the freedom to make .int more useful maybe rethink / broaden
>    it permitted use with cases like this considered.
> 
>    IMHO: as broad as possible in the original spirit while still effectively prohibiting FCFS land grabs.
> 
>    Maybe something like international organizations established by national governments or their international organizations.
> 
> c) "The documented uses of infrastructural identifiers in the "int"
>     domain were largely experimental and in practice obsolete."
> 
>    ... and are now in practice ...
> 
> d) I suggest to replace the security considerations of
> 
>     "The operator of the "int" domain should be cautious about any potential
>      re-use of these domains for intergovernmental treaty organizations"
> 
>     with explicit text earlier, that these domain names must never be re-used
>     and maybe even instructions how to populate them with some appropriate NULL RR
>     (not sure what the best RR would be).
> 
>     Halloween horror story of the day: ITU gets ipv4.int and ipv6.int and uses it
>     for a new international database how to filter Internet traffic. Just saying.
>     Look up the EU presidents history of Internet filtering proposals...
> 
>     Note: It would  be nice if ITU gets tpc.int and populates it with
>     the some official E164 database, but neither does ITU have this type of humor,
>     nor does domain availability change the business model that makes DNS
>     not desired for E164 space... unfortunately... i think).
> 
> Cheers
>      Toerless
> 
> 
> On Wed, Oct 19, 2022 at 05:34:40PM -0400, Michael Richardson wrote:
>>
>> The IESG <iesg-secretary@ietf.org> wrote:
>>      > The IESG plans to make a decision in the next few weeks, and solicits
>>      > final comments on this action. Please send substantive comments to the
>>      > last-call@ietf.org mailing lists by 2022-11-23. Exceptionally, comments
>>      > may be sent to iesg@ietf.org instead. In either case, please retain the
>>      > beginning of the Subject line to allow automated sorting.
>>
>>      > Abstract
>>
>>
>>      >    The document marks as historic any "int" domain names that were
>>      > designated for infrastructure purposes, and identifies them for removal
>>      > from the "int" top-level domain.  Any implementation that involves
>>      > these domains should be considered deprecated.  This document also
>>      > marks RFC 1528 and RFC 1706 as historic.
>>
>> So, I understand that none of our infrastructure has been in .int for some
>> years (decades even).
>>
>> The document says:
>>     In conjunction with this change, the eligibility for "int" domains was
>>     limited to only intergovernmental treaty organizations.
>>
>> I think that, after approval, that this use for int will remain, and the
>> management of it will fall to, I guess, ICANN, as yet another TLD?
>>
>> At first reading, it seemed like we were removing int entirely, but upon more
>> careful reading, I see that we are just removing our infrastructure
>> delegations.
>>
> 
>> --
>> ]               Never tell me the odds!                 | ipv6 mesh networks [
>> ]   Michael Richardson, Sandelman Software Works        | network architect  [
>> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
>>
>>
>>
> 
> 
> 
> 
>> -- 
>> last-call mailing list
>> last-call@ietf.org
>> https://www.ietf.org/mailman/listinfo/last-call
> 
>