Re: [Last-Call] Last Call: <status-change-int-tlds-to-historic-00.txt> (Moving TCP.INT and NSAP.INT infrastructure domains to historic)
Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 01 April 2022 03:11 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 DF2F03A1F2C
for <last-call@ietfa.amsl.com>; Thu, 31 Mar 2022 20:11:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 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_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 ([4.31.198.44])
by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id BWkvLH2qNbLs for <last-call@ietfa.amsl.com>;
Thu, 31 Mar 2022 20:11:08 -0700 (PDT)
Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com
[IPv6:2607:f8b0:4864:20::52b])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id CB3923A1F2A
for <last-call@ietf.org>; Thu, 31 Mar 2022 20:11:08 -0700 (PDT)
Received: by mail-pg1-x52b.google.com with SMTP id s72so1354262pgc.5
for <last-call@ietf.org>; Thu, 31 Mar 2022 20:11:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=subject:to:references:from:message-id:date:user-agent:mime-version
:in-reply-to:content-language:content-transfer-encoding;
bh=PTRDkL3Dk47o5sbq3LSqGV6dtRFV9twuNNIn1m6iSoo=;
b=jTqVLwWZUlQ77db4okE8sYJuJHJn2wlo/rcUTsFy4F0RJdZNjtnawmIpCtUdj/ms02
GBtAwoDpF24uiohfoRSdpiGs07szXHDnK3GzMt9g5mt3iG3dEPMtyISrMZ9++co3qlnr
1O2sy51+aaQvlOnp19Z9AlvDPuPDHU5CuJm22z9vglIyhDiM1k83D+g70t55rP1cFwjb
6hEO5zuGhQx1XrHBUQekImtpGCaFiRfuwVWeGltU0UUbK6H2K1gjLE1pI6e0TfJGO5DE
w2+DTcogaHwEBGlP0MLikt1zIr6XJHt0Sy7TnshxHN1ek/5IT4C7vkiTjKuPeZEofOvI
xp1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:subject:to:references:from:message-id:date
:user-agent:mime-version:in-reply-to:content-language
:content-transfer-encoding;
bh=PTRDkL3Dk47o5sbq3LSqGV6dtRFV9twuNNIn1m6iSoo=;
b=XXZ4nUREGe9dxBScyYb+YD8kIFobyal+i7GIlDPT9q8Zgtr2nEEbUQvQMmRbjVygIl
kkRt/33LsxTLQnZg2mvLaut7fkR1KPQzRYEfd5RVEkK0HLrFIu0Zg5p4X9nBqr9/Yggd
I4Bq0YEFClMiUNNpKL5b51j9qXt5pyLKOjwIqKtWSJh5gA80Hr3s6nXYmq29Yk/+j09c
3pIafbAoLNVcSOknLEv028dL9QMEnIDWiGE/KxdUhWkWg3rcXYqPU1SrvxZYKXs/kntN
BPFpeiXB+zQ0aRnj4WVZjsjqJeZWy+J940knVLHE8wCG7FD4ntEWt3L9q/pWNptYL1i6
VA5w==
X-Gm-Message-State: AOAM533vK7fXHMloma9qBFQ/3cicMtnXpjcP58fMYLHgfJxX96ExzP6s
6yduqTP4aZqInJfuuAGBo+5LS1eVue7niw==
X-Google-Smtp-Source: ABdhPJy9AWNF4GElR3VhMwv6LfTyGzJBek5ZRaQeJea27yYhiXahFiaH/M5JsobvpnMtAQYaLej5Wg==
X-Received: by 2002:a65:6813:0:b0:384:b288:8702 with SMTP id
l19-20020a656813000000b00384b2888702mr13433375pgt.275.1648782667389;
Thu, 31 Mar 2022 20:11:07 -0700 (PDT)
Received: from ?IPv6:2406:e003:1005:b501:80b2:5c79:2266:e431?
([2406:e003:1005:b501:80b2:5c79:2266:e431])
by smtp.gmail.com with ESMTPSA id
m21-20020a17090ab79500b001ca3c46ba2fsm148247pjr.24.2022.03.31.20.11.05
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Thu, 31 Mar 2022 20:11:07 -0700 (PDT)
To: John C Klensin <john-ietf@jck.com>, S Moonesamy <sm+ietf@elandsys.com>,
Joe Abley <jabley@hopcount.ca>, last-call@ietf.org
References: <6.2.5.6.2.20220330004724.07d61520@elandnews.com>
<D224B6D3-762A-4254-883E-BAB7C8712048@hopcount.ca>
<6.2.5.6.2.20220331063526.07f88b38@elandnews.com>
<5eb63308-94dc-b3dc-b251-9e90a8676c32@gmail.com>
<33FAB2C47052F604762A9A6E@PSB>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <dfdbd382-0d34-7b11-6ecb-0294c789959c@gmail.com>
Date: Fri, 1 Apr 2022 16:11:03 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <33FAB2C47052F604762A9A6E@PSB>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/uoy4pROPPXfWlb3yvwI4rFdzCNE>
Subject: Re: [Last-Call] Last Call:
<status-change-int-tlds-to-historic-00.txt> (Moving TCP.INT and NSAP.INT
infrastructure domains to historic)
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 01 Apr 2022 03:11:14 -0000
On 01-Apr-22 15:29, John C Klensin wrote: > > > --On Friday, April 1, 2022 09:05 +1300 Brian E Carpenter > <brian.e.carpenter@gmail.com> wrote: > >>> The documents relating to the domain are not IESG-approved >>> documents. They are not covered by the agreement which >>> supplements the ICANN-IETF MoU signed between the IETF >>> Administration LLC and the Internet Corporation for Assigned >>> Names and Numbers. > >> That doesn't matter. The domain names concerned are in the >> category of "assignments of domain names for technical uses" >> defined in the basic MoU, which are explicitly "not considered >> to be policy issues" and remain under the IETF's control. > > Brian, > > I had planned to save this for another day but, while I think it > is easy to categorize NSAP.INT that way, I wonder on what basis > you justify subdomains of TPC.INT as "technical use". Agreed that it's a strange beast with a strange history. And to be frank, if ICANN came back and said 'No, it isn't just a "technical use"' I'd be happy enough to say 'OK' and move on. So it's my personal opinion that it would fall under "technical use", but if it doesn't, and somebody else wants to obsolete it instead of the IETF doing so, I would be perfectly content. (Whether it should have been added to .int in the first place is an interesting historical question, but I don't believe it has any current impact.) Rgds Brian > It is an > SLD that has a rather-odd looking subdomain structure, one that > (deliberately if I remember the discussions at the time > correctly) does not require any special handling in the DNS > itself. Beyond that, it is, as far as the DNS is concerned, > rather ordinary, with some applications-level protocols using > the DNS to simply map names (however odd-looking the might be to > addresses. > > Let me illustrate with a few examples and accompanying questions: > > Suppose I were running a circus with several touring companies, > each of which had several carriages and wagons for different > types of performers, wagon numbers for each performer type, and > each wagon contained one or more hosts that I wanted to > identify. I also got together with other circus operators, > plunked down my money, and got an appropriate TLD. To avoid > arguments about who got which names, I numbered the companies, > the carriages, and the computers, ending up a DNS structure > looking like > > <host>.<carriage>.<performer-type>.<company>.johns-big-top.circus. > I'd then have FQDNs that looked like > 2.1.1.3.johns-big-top.circus. > and that were used for plain, ordinary, host name to address > mapping. > > Is that a "technical use" even though the TLD would have to be > allocated by ICANN? If it is not, what distinguished it from > the domain names of TPC.INT? Number of labels aside, they look > pretty much alike once one get below the SLD? Both are used for > name to address mapping -- no special RRs or odd interpretations > of the DATA portion of the DNS records. > > Second example: > > Suppose ITU concluded that the TPC.INT numbering scheme was > really interesting and that they have a good use for it > (although probably pointing to servers belonging National > Administrations or numbering databases rather that privately > operated hosts. They set that up using precisely the same > reversed-number labeling structure as that used by TPC.INT only > subsidiary to E164.ITU.INT. Would that make that E164 subtree a > "technical use"? If so, would their decision to create that > subtree suddenly put all of ITU.INT a domain under IETF control, > overriding whatever arrangements exist between ITU and IANA > because of the words in the MOU? > > Third example: > > Suppose, when the ideas that led to the TPC activity came along, > it had been registered, not in INT, but in NET, but otherwise > with exactly the same structure and protocols being supported. > (The reason why it ended up in INT is a piece of history I don't > know and suddenly find interesting, but, if I had to guess, it > might be along the lines of "because they could" or "it was > free".) Would that make it "not a technical use" just because > of the TLD used to house/anchor it? > > Although I can think of several reasons why it would have been a > bad idea, the MOU could have defined "domain for technical use" > by either an enumerated list of such domains or as anything that > was not on an enumerated list of intergovernmental-type bodies. > It didn't. It also could have said "Other than in ARPA, ICANN > gets to decide what is or is not a technical use subdomain". Or > it could say that with the IETF in charge or established some > sort of procedure for making the determination. It didn't do > any of those things either. It would have been reasonable at > the time to assert that the ARPA TLD was entirely "technical > use" and then discuss selected subdomains of INT, but it didn't > do that either: AFAICT, it does not call out either TLD by name. > > > That, in turn, creates some interesting questions of authority > over "domains for technical use" or even delegated subdomains > for inverse DNS lookup that might exist in assorted ccTLDs. The > MOU implies that all of those are under IETF control, something > that would come as quite a surprise to assorted RIRs and > countries. Unless there is a plan to update the MOU to make all > of that more clear in a way that would suit today's needs better > (an update that would presumably require signoff from ICANN, > possibly even ICANN during the time of the DOC contract and/or > DOC), we are stuck with what we have. > > Of course, the IETF and ICANN could initiate a new ICANN PDP > with the goal of creating a new MOU and, presumably, a modified > and consistent PTI agreement. If that feels like a good idea, > let's get the PDP started now and, if we are really lucky and > things move at maximum speed, recent experience with ICANN > suggests we will be able to come back to this in five or six > years (more likely longer). > > Consequently, unless you can come up with a definition of > "technical use" that makes the examples above come out as > not-technical while TPC.INT is technical, saying that TPC.INT is > "technical use" and therefore under IETF control seems like more > than a bit of a stretch. > > I think there are ways to accomplish what is actually desired > here (which, in case I haven't said it lately, I'm personally in > favor of doing) without appealing to fuzzy definitions in the > MOU and having to definitively (and maybe retroactively) define > "technical use", figuring out how to update RFC 1591, creating a > clear definition of what it means to make a domain historic, and > scratching other itches and issues that might require boiling a > few oceans before the actions can be properly taken. I'm trying > to work on a clear explanation and a proposal about how to do > that. But I'm convinced that, if we have to invoke > hairsplitting over undefined terms like "technical use", we are > in big trouble. > > john >
- Re: [Last-Call] Last Call: <status-change-int-tld… S Moonesamy
- Re: [Last-Call] Last Call: <status-change-int-tld… Brian Carpenter
- Re: [Last-Call] Last Call: <status-change-int-tld… Joe Abley
- Re: [Last-Call] Last Call: <status-change-int-tld… Ted Hardie
- Re: [Last-Call] Last Call: <status-change-int-tld… John Levine
- Re: [Last-Call] Last Call: <status-change-int-tld… Warren Kumari
- Re: [Last-Call] Last Call: <status-change-int-tld… Warren Kumari
- Re: [Last-Call] Last Call: <status-change-int-tld… John C Klensin
- Re: [Last-Call] Last Call: <status-change-int-tld… Ted Hardie
- Re: [Last-Call] Last Call: <status-change-int-tld… S Moonesamy
- Re: [Last-Call] Last Call: <status-change-int-tld… Brian E Carpenter
- Re: [Last-Call] Last Call: <status-change-int-tld… John C Klensin
- Re: [Last-Call] Last Call: <status-change-int-tld… Brian E Carpenter