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@xxxxxxxxxxxx>
> wrote:
>
> > Toerless Eckert <tte@xxxxxxxxx> 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@xxxxxxxxxxxx>, Sandelman Software Works
> > -= IPv6 IoT consulting =-
> >
> > --
> > last-call mailing list
> > last-call@xxxxxxxx
> > https://www.ietf.org/mailman/listinfo/last-call
> >
--
---
tte@xxxxxxxxx
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
