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

Toerless Eckert <tte@cs.fau.de> Mon, 24 October 2022 18:21 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 4D36DC14CE22; Mon, 24 Oct 2022 11:21:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.657
X-Spam-Level:
X-Spam-Status: No, score=-6.657 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_HI=-5, 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
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 8dlprOP3C4SC; Mon, 24 Oct 2022 11:21:02 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.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 B5381C14CF00; Mon, 24 Oct 2022 11:21:00 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff: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 A03DB54857D; Mon, 24 Oct 2022 20:20:54 +0200 (CEST)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 954E94EBE12; Mon, 24 Oct 2022 20:20:54 +0200 (CEST)
Date: Mon, 24 Oct 2022 20:20:54 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Warren Kumari <warren@kumari.net>, emo-dir@ietf.org
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, Kim Davies <kim.davies@iana.org>, last-call@ietf.org, draft-davies-int-historic@ietf.org
Message-ID: <Y1bXhpdfF9LjjmiU@faui48e.informatik.uni-erlangen.de>
References: <166621075802.44847.14382611991776479938@ietfa.amsl.com> <371922.1666215280@dyas> <Y1B2KEoXO1fodrqh@KIDA-9190.local> <503014.1666369231@dyas> <Y1MBwTgxxsiF+0uA@faui48e.informatik.uni-erlangen.de> <632740.1666418207@dyas> <CAHw9_iKOaVPFVhu8+HRDYgvpdSRzRiPR+4nJzJROS+LrL3LxBA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAHw9_iKOaVPFVhu8+HRDYgvpdSRzRiPR+4nJzJROS+LrL3LxBA@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/Ug5AYPH24SNQQEsqJ8ug45JAK8U>
Subject: [Last-Call] emo-dir ? Re: [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: Mon, 24 Oct 2022 18:21:07 -0000

Warren:

a) Thanks for the insights.

b) At the risk of getting mugged by nice IANA people in a dark alley
   because i am shoving work their way:

Hereby copying emo-dir to suggest that something like what you wrote
below with more explanations//background could IHO be a great talk by
an IANA person under the title of "What is IANA doing". Maybe also
helpful for IANA itself when it includes section like 
"How NOT to write IANA considerations" or the like...

(and shame on me if this actually did happen in the recent years and i overlooked it).

Cheers
    toerless

On Mon, Oct 24, 2022 at 11:11:56AM -0700, Warren Kumari wrote:
> On Sat, Oct 22, 2022 at 1:56 AM, Michael Richardson <mcr+ietf@sandelman.ca>
> wrote:
> 
> > Toerless Eckert <tte@cs.fau.de> wrote:
> >
> > Michael: IANA are services provided by PTI, an affiliate of ICANN. https:/
> > /www.iana.org/about
> >
> > Yes, I forgot that IANA and ICANN are so close.
> >
> 
> Yup.
> 
> In the IETF we naturally think of the IANA as "those nice people who hand
> us the next code point in the Foozle Whatzit registry when we ask, and also
> keep careful track of which ones are already assigned, etc." - but they
> actually much more than this, and have more "customers".
> 
> For example, the IANA is "operate[s] and maintain[s] a number of key
> aspects of the DNS, including the root zone, and the .int and .arpa
> domains."[0], and well as being the "operator of the Key Signing Key"[1]
> and running the "Key Signing Ceremonies"[2], as well as the arpa servers.
> 
> They also "managing Internet number resources is to provide pools of
> unallocated IP addresses and AS numbers to Regional Internet Registries
> (RIRs)"[3], and also maintain the "Time Zone Database (often called tz or
> zoneinfo) contains code and data that represent the history of local time
> for many representative locations around the globe"[4], etc.
> 
> The protocol registries (https://www.iana.org/protocols) that we usually
> associate with "the IANA" is only a small part of their function.
> 
> (I'm sure I've summarized / worded some of the above poorly)
> 
> >
> >
> But, I was imagining that it would be passed by ICANN to some like the UN,
> > if not the actual UN. But, as has also been pointed out, it's not our
> > business.
> >
> 
> Yup. The way that I was viewing the document, it all basically boils down
> to:
> 
> "We used to put subdomains under .int, but we are no-longer using them. For
> the last many years, when we need these sorts of infrastructure names, we
> put them under .arpa."
> 
> The color of this particular bikeshed, who should paint it, and who is
> allowed to store bikes in it,  is, thankfully, not really our concern.
> 
> Amanda and Kim started this whole document quite a while back, and it's a
> housecleaning / tidying up / documenting current realities document.
> As Brian said: "Personally I'm very grateful to Kim and Amanda for tidying
> this up for us."
> 
> 
> W
> 
> [0]: https://www.iana.org/domains
> [1]: https://www.iana.org/dnssec
> [2]: https://www.iana.org/dnssec/ceremonies
> 
> [3]: https://www.iana.org/numbers/allocations/
> [4]: https://www.iana.org/time-zones
> 
> 
> 
> I agree with some comments that we should have no text about what .int is
> > for, just deprecate our usage of it.
> >
> > --
> > 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