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

Michael StJohns <mstjohns@comcast.net> Thu, 20 October 2022 01:41 UTC

Return-Path: <mstjohns@comcast.net>
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 67680C15257D for <last-call@ietfa.amsl.com>; Wed, 19 Oct 2022 18:41:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.108
X-Spam-Level:
X-Spam-Status: No, score=-7.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_HI=-5, 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=comcast.net
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 sBhfjA7lrRYX for <last-call@ietfa.amsl.com>; Wed, 19 Oct 2022 18:41:09 -0700 (PDT)
Received: from resqmta-a1p-077437.sys.comcast.net (resqmta-a1p-077437.sys.comcast.net [96.103.146.56]) (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 D69E0C1524D0 for <last-call@ietf.org>; Wed, 19 Oct 2022 18:41:08 -0700 (PDT)
Received: from resomta-a1p-077060.sys.comcast.net ([96.103.145.238]) by resqmta-a1p-077437.sys.comcast.net with ESMTP id lApQoNFtEmUF8lKWYo6Rg3; Thu, 20 Oct 2022 01:39:06 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1666229946; bh=FoMx7LGYWQ3SpOEuNLl3lw/AF2ieYFL80tSAdk+4Qk8=; h=Received:Received:Message-ID:Date:MIME-Version:Subject:To:From: Content-Type; b=FqdNUpTsfKESD/S9IyfRuHhu1bM0E4rrBF9HzHUkWmwtfp9E+kAHIUZMIv6Zaiw/L p3HcFTp5iFcujqXTHORPcCUHJ3TdW3heXlHkrmv8hLGWb+QJLyc4EE3LRfxNO4vEPf iivXRLCJ/mKiE+djLzV/5RIJ7T9weHrUsZWQzwtRHXR/Gyg7Goke5lQvU9okNcc9rk b+zusGvlLb9ZcT3dVFTREkpC2scmhl7EnXd7KH8nrSV5QkmHNdnrq/ODawS5s0ese4 OgAp4OCTZbDf2FgNQkDUfeOK6g1MPyvhZP6DTqFneVY9MLoJa5PAbeWRLIyIqY60xq 8fiJ8o9A32y/Q==
Received: from [192.168.1.23] ([108.31.156.76]) by resomta-a1p-077060.sys.comcast.net with ESMTPSA id lKW5oRNbVbG4ylKW6oAzbW; Thu, 20 Oct 2022 01:38:42 +0000
X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgedvfedrfeelhedghedtucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuvehomhgtrghsthdqtfgvshhipdfqfgfvpdfpqffurfetoffkrfenuceurghilhhouhhtmecufedtudenucenucfjughrpefkffggfgfuvfhfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpefoihgthhgrvghlucfuthflohhhnhhsuceomhhsthhjohhhnhhssegtohhmtggrshhtrdhnvghtqeenucggtffrrghtthgvrhhnpeejfeekjeetheekkeduvefhieeffeffveekgeegffelveeuheeufeejkedtfeefkeenucffohhmrghinhepihgrnhgrrdhorhhgpdhivghtfhdrohhrghenucfkphepuddtkedrfedurdduheeirdejieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopegludelvddrudeikedruddrvdefngdpihhnvghtpedutdekrdefuddrudehiedrjeeipdhmrghilhhfrhhomhepmhhsthhjohhhnhhssegtohhmtggrshhtrdhnvghtpdhnsggprhgtphhtthhopedupdhrtghpthhtoheplhgrshhtqdgtrghllhesihgvthhfrdhorhhg
X-Xfinity-VMeta: sc=0.00;st=legit
Message-ID: <ebddbd5e-cc0e-4353-0260-c162fc12b720@comcast.net>
Date: Wed, 19 Oct 2022 21:38:37 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.3.3
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> <295948c3-b116-365f-a682-6e286be69ffb@gmail.com> <Y1CCh1XOwkNFafet@faui48e.informatik.uni-erlangen.de> <CAKr6gn127iGBjtB2+Q=80Tydfp8gnU0NOsFskU96D8digL6bUQ@mail.gmail.com> <9BF773D1-DFD2-457E-8E71-5126CCB81FF4@sobco.com>
From: Michael StJohns <mstjohns@comcast.net>
In-Reply-To: <9BF773D1-DFD2-457E-8E71-5126CCB81FF4@sobco.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/V1_gIUS26_o2O5wsmAKSI89ZptQ>
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: Thu, 20 Oct 2022 01:41:13 -0000

On 10/19/2022 8:35 PM, Scott Bradner wrote:
> .int domain is in use - see, for example, itu.int
>
> the IETF can clearly ask that any .int second level domains that were created by IETF action
> (e.g. tpc.int) be removed but less clearly can the IETF ask that .int second level domains that the IETF had no
> part in creating be removed
>
> .int is run by the IANA because it has always been run by the IANA - Jon at first
> then the IANA when the IANA came into existence

*laugh* Not exactly.  Jon came to me at DDN (during the IETF meeting at 
MITRE - july 1987)  and told me that DARPA had asked for its creation - 
and I think nato.int was the first registration. I approved the creation 
of .INT (I owned the NIC contract at the time and for some reason I 
ended up the decider for new non CC TLDs), but required that the 
management of it not be at the NIC.  ISI ended up running the servers, 
and DARPA ended up owning the zone - E.g. - it was a delegated zone 
owned by DARPA run by ISI under a DARPA contract, but not part of the 
IANA stuff exactly.

I was later hoist by my own petard as I had this white elephant I had to 
deal with when I got to DARPA in 92 and took over the ISI contract.  I 
seem to remember pushing .INT over to the InterNic and NSF  as DOD 
*really* wanted nothing to do with non-DOD internet.  I think that's 
where it was when ICANN/IANA stood up.

>
> well prior to ICANN being formed there was talk about handing management of .int over to the ITU -
> Jon had proposed that, but told the ITU that he needed some documentation on how .int
> would be run before he would do that (I was in at least two meetings between Jon and an ITU person
> about the topic) - the two documents were
> 	1/ a clear statement on who could register in .int
RFC1591 had about the simplest statements - international treaty orgs 
and international databases were permitted.  I do remember the talks, 
but I seem to remember that ITU wasn't playing all that nice with the 
Internet folk and we mostly gave up.
> 	2/ a document describing how the ITU would actually operate the servers
>
> but the ITU never produced the documents so the transfer never happened
>
> I was not "in the room" when Jon agreed to put tpc in .int - but Marshall Rose was and
> also I assume Carl Malamud - one could ask them what their argument was

Steve Wolff would probably be a reasonable source as well as this was 
well into the InterNic transition period.

tpc.int fell under the "international" databases prong and that would 
have been enough for Jon or whoever to approve the registration without 
referral for further approval. https://www.iana.org/domains/int/policy 
has more on the current structure (hard to believe its been 20+ years 
since databases were deprecated here).

Later, Mike


>
> Scott
>
>> On Oct 19, 2022, at 7:23 PM, George Michaelson <ggm@algebras.org> wrote:
>>
>> I agree with what I thik Toerless is saying here.
>>
>> 1) the wording in the draft appears to (re)open the door to use of the
>> domain. This is despite the intent of the draft and I believe the
>> organisation, to remove dependency and use of the domain. Why is this
>> wording being used?
>>
>> 2) why does IANA continue to "operate" the domain, if there is no
>> dependency and no forseen use? The proper way to get shot of a burden,
>> is to give it to somebody else. Re-delegate to ICANN and make them
>> responsible for the registrar decisions about what treaty bodies are
>> allowed to have state in .INT
>>
>> Toerless? Is that a reasonably good take on what you said? It's what I
>> think you said.
>>
>> -G
>>
>> -- 
>> last-call mailing list
>> last-call@ietf.org
>> https://www.ietf.org/mailman/listinfo/last-call