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

Toerless Eckert <tte@cs.fau.de> Fri, 21 October 2022 20:32 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 1D39EC1526EF; Fri, 21 Oct 2022 13:32:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.657
X-Spam-Level:
X-Spam-Status: No, score=-1.657 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=no autolearn_force=no
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 zuUkMpBbVZ4X; Fri, 21 Oct 2022 13:32:10 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 5FE93C1524AC; Fri, 21 Oct 2022 13:32:08 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 30509548550; Fri, 21 Oct 2022 22:32:01 +0200 (CEST)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 218DF4EBDCC; Fri, 21 Oct 2022 22:32:01 +0200 (CEST)
Date: Fri, 21 Oct 2022 22:32:01 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: Kim Davies <kim.davies@iana.org>, last-call@ietf.org, draft-davies-int-historic@ietf.org
Message-ID: <Y1MBwTgxxsiF+0uA@faui48e.informatik.uni-erlangen.de>
References: <166621075802.44847.14382611991776479938@ietfa.amsl.com> <371922.1666215280@dyas> <Y1B2KEoXO1fodrqh@KIDA-9190.local> <503014.1666369231@dyas>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <503014.1666369231@dyas>
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/2aPjslrBV1BKtQpG-6COerdBDpk>
Subject: Re: [Last-Call] [Ext] Re: 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: Fri, 21 Oct 2022 20:32:15 -0000

Michael: IANA are services provided by PTI, an affiliate of ICANN.

https://www.iana.org/about

See Policy Remit section. 

Btw: I do remember the discussions back when we introduced IPv6 multicast
if/how we could have "commercial"/RIR based allocation of IPv6 multicast group
addresses, and i was told none of them would want to bother with crap stuff
like that. I can imagine that the answer to why .int would not go commercial
beyond IANA would be based on the same commercial argument: being responsible to
allocating only to international treaty org ... and getting a busines of 170 names
within ca. 20 years - and doing it for free. Thank you, but thank you no.

The commercial model only works when you have a combination of easily automated
allocation (little/no complex checking) and crazy prices for stupid names.

So there is actually a "don't design" area for name spaces requiring registries
that we know could not be succesful commercially AND would be too costly for
IANA to run.

Given the current state of world affairs i'd also wonder if there are going
to be any new registration requests for .int any time soon. I digress.

Cheers
    Toerless

On Fri, Oct 21, 2022 at 06:20:31PM +0200, Michael Richardson wrote:
> 
> Kim Davies <kim.davies@iana.org> wrote:
>     > Quoting Michael Richardson on Wednesday October 19, 2022:
>     >>
>     >> 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?
> 
>     > The .INT domain has been operated as part of the IANA functions and
>     > that will continue as-is. This activity is limited to tidying up some
>     > obsolete second-level domains within .INT.
> 
> It seems like it ought to pass out of IANA hands now, since we aren't using
> it for infrastructure (Assigned Numbers).
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 



> -- 
> last-call mailing list
> last-call@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call


-- 
---
tte@cs.fau.de