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> Thu, 20 October 2022 01:04 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 82B4AC15EB28 for <last-call@ietfa.amsl.com>; Wed, 19 Oct 2022 18:04:50 -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 PbjHBiybxpeJ for <last-call@ietfa.amsl.com>; Wed, 19 Oct 2022 18:04:46 -0700 (PDT)
Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 B2A80C15259A for <last-call@ietf.org>; Wed, 19 Oct 2022 17:58:33 -0700 (PDT)
Received: by mail-pg1-x530.google.com with SMTP id h185so17793912pgc.10 for <last-call@ietf.org>; Wed, 19 Oct 2022 17:58:33 -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:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=KY1iPYtBvV2xYuSr55Lns3Bw/Uyd8GfC1Zc5lbgR/ts=; b=eUtnmmTlwZS0Oc1znRU7RYy93SqzjQINvlOYvv75Pa0Yz5H4/jtvAUl1fwIiW15mjE czd4NPSIhtoFUsl6h/2/hXuGiOI6mbGj+YyIpB9nFqrf7cG2BUdkvTxs/rjCEAKZkQqQ jTaa67I+oKbMHz2DLQSbOXQ0OJ7pnNhfuP5wa2IbXoPmRk3oz//jWnwCrczBZ0ssYJZV PIEIrNrPw8Q7KxR6jlpCbDCx0HVVjgZ0xZPLtyC6jY8WKXkCigfqS80bBHSO4fj5qRhM gLdgDHbbcv9Y2aEuGkasxLY9CWRhgd8pt160OTQTsdpkEX/BKADqKmZdX/micrhVEEbG F+KQ==
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:cc: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=KY1iPYtBvV2xYuSr55Lns3Bw/Uyd8GfC1Zc5lbgR/ts=; b=O4YPDwwPoxDlyOPFrhXJp5zFneVyPt6ocR62cn80Dre49Cjnt/DlcsnPVLtJrv3CPZ jBoUcw+FFBAdFuOlt4xaQN4KFSOm4wkKsr+34fOsN3tTH8JiDmgs5puNE/jeKRMmmI+a b0BU5+5awV2Pwr1w55jNRse8Tqpb9oVA1VfzxY5L5CNncxTZup8BW/GzHNqOkQYl1+gR GWuNdq/HSm20XI4BI2w3ZGhafuL6z5tX0VJmmrpROlJl8WTEvDI4uCxOCHJJBbqPGgcF 22xAAQ3OW5i33cJtQcve98JtIB0WrVMHBzY86Gb4PkdcrwkjhJO/V2oS2aSwUYbN//64 w1tA==
X-Gm-Message-State: ACrzQf04tRAveeXz3LeMT5dJ4dT5AfByZgZvt/Yu2QCVNb8KB73a2OLx wLBTl2R6L1lbSqoWXXIYAK0=
X-Google-Smtp-Source: AMsMyM53tGlw1IA73/SCdCy9qFmOKjFPI2tb3LSRQ5iv7pQQ0tnNoG1Wb9YO3Re0RzOujrlAiBt7qw==
X-Received: by 2002:a63:251:0:b0:46e:9da8:1f93 with SMTP id 78-20020a630251000000b0046e9da81f93mr221135pgc.490.1666227512774; Wed, 19 Oct 2022 17:58:32 -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 a4-20020a170902ecc400b0017f92d7fe2csm11483286plh.288.2022.10.19.17.58.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Oct 2022 17:58:31 -0700 (PDT)
Message-ID: <60a5667b-b37c-c991-0f77-e2ce4ecfa3c0@gmail.com>
Date: Thu, 20 Oct 2022 13:58:26 +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: George Michaelson <ggm@algebras.org>, Scott Bradner <sob@sobco.com>
Cc: Toerless Eckert <tte@cs.fau.de>, 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> <CAKr6gn3sxCmZJkagN9-fzPa_c1ssW0yGofXXEROKz3q4JtzLyg@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <CAKr6gn3sxCmZJkagN9-fzPa_c1ssW0yGofXXEROKz3q4JtzLyg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/U_zueu3UJXbBob4VLovVYKtbIIk>
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:04:50 -0000

George,

IANA is part of ICANN. All this does is extricate the IETF for once
and for all from any usage of .int. What happens to .int after that is
no business of the IETF's. This is an informational RFC and the first
sentence of the Introduction is factual information. If there's some aspect
of that that you disagree with, that's between you and ICANN.

In terms of authority, authority over TLDs has resided with ICANN since
1998, except for .arpa and this tiny corner of .int. The IETF is now
documenting what has been a fact for many years: this tiny corner of
.int is totally obsolete.

Personally I'm very grateful to Kim and Amanda for tidying this up
for us.

Regards
    Brian Carpenter

On 20-Oct-22 13:38, George Michaelson wrote:
> So the problem as you state it (if I understand this right) is that
> all this draft does, is disclaim subdomains for use by IETF and
> related bodies, it seeks to make no other alteration to the delegation
> of authority of the domain, or disclaim registrar functions for the
> domain.
> 
> But, it changes language relating to occupancy rules for the domain.
> To me, that demands a "why" question (and answer) and "on whose
> authority or request" and "is this actually necessary"
> 
> I was wrong to suggest it can simply be disclaimed, I didn't realise
> there were other non-IETF occupants to whom some duty of care remains.
> Clearly, if I understand that right, IANA should not simply walk away
> from registrar functions.
> 
> Do I have this right?
> 
> cheers (and thanks for the clarification)
> 
> -George
> 
> On Thu, Oct 20, 2022 at 10:35 AM Scott Bradner <sob@sobco.com> 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
>>
>> 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
>>          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
>>
>> 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
>>