Subject: [DNSOP] Deprecating infrastructure .INT domains

From: Kim Davies <[email-masked]>
Date: Thu, 11 Nov 2021 08:38:06 -0800

Colleagues,

I wanted to draw your attention to an Internet Draft we’ve developed,
its goal is to formally deprecate a number of historic “.int”
domains that were designated for Internet infrastructure purposes
decades ago and appear for all intents and purposes obsolete. After some
limited consultation on developing the approach so far, it would be
useful to get some additional eyes on it so we have greater confidence
there is nothing we’ve missed.

Datatracker link: https://datatracker.ietf.org/doc/draft-davies-int-historic/

It’s a short document, but at its heart we’ve identified the
following domains that are referenced in places but seem to be obsolete:

            atma.int, ip4.int, nsap.int, rdi.int, reg.int, tpc.int

Most of these are not delegated in the int zone any longer, but there
are lingering references to them.

Thanks in advance for any insight, and apologies if you get this message
in duplicate,

kim

---

From: Joe Abley <[email-masked]>
Date: Thu, 11 Nov 2021 11:56:11 -0500

Hi Kim,

I like the idea of cleaning this up.

Choosing nsap.int as an example, I think it would be useful to either update RFC 1706 to make it clear that the advice in section 6 of that document no longer applies, and that no reverse mapping for NSAP is provided in the DNS. I don't think this is a great operational necessity since I imagine the number of people who expect this to work is approximately zero but it seems good to be tidy.

[I'd suggest reclassifying 1706 to historic but that'd also affect the specification for the NSAP RRType; maybe that's a good idea too, but it seems outside the scope of what you are trying to achieve, and I don't know how we would confirm that it's a good idea.]

Similar comment for other domains where there's similar existing advice.

Happy to offer actual text if that seems useful.

Joe

> On 11 Nov 2021, at 11:38, Kim Davies <[email-masked]> wrote:
> 
> Colleagues,
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Bob Bownes -Seiri <[email-masked]>
Date: Thu, 11 Nov 2021 12:19:49 -0500

Kim,

I concur with Joe on this. It would be good practice to tidy up these appendages. 

I too would be happy to contribute text as appropriate. 

Bob

> On Nov 11, 2021, at 11:56, Joe Abley <[email-masked]> wrote:
> 
> Hi Kim,
>

---

From: Petr Špaček <[email-masked]>
Date: Fri, 12 Nov 2021 13:55:12 +0100

> Similar comment for other domains where there's similar existing advice.

FTR I can't see any problems with that, and suggest to do that in one go 
in this document. We have enough RFCs already and wasting more numbers 
(and work) on simple deprecation does not sound useful to me.

Petr Špaček

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 12 Nov 2021 08:20:49 -0500

I agree with Petr here.

On Fri, Nov 12, 2021 at 7:56 AM Petr Špaček <[email-masked]> wrote:

> > Choosing nsap.int as an example, I think it would be useful to either
> update RFC 1706 to make it clear that the advice in section 6 of that
> document no longer applies, and that no reverse mapping for NSAP is
> provided in the DNS. I don't think this is a great operational necessity
> since I imagine the number of people who expect this to work is
> approximately zero but it seems good to be tidy.
> >
> > [I'd suggest reclassifying 1706 to historic but that'd also affect the
> specification for the NSAP RRType; maybe that's a good idea too, but it
> seems outside the scope of what you are trying to achieve, and I don't know
> how we would confirm that it's a good idea.]
> >
> >> Datatracker link:
> https://datatracker.ietf.org/doc/draft-davies-int-historic/
> >>

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 12 Nov 2021 22:27:49 +0900

> following domains that are referenced in places but seem to be obsolete:

That's fine. As the decision is made by IANA/ICANN, not IETF, it is
appropriate that the intended status is not BCP but informational.

But, abstract and introduction should make it explicit that it
is decided by IANA and/or ICANN. Merely stating "IANA shall" in
latter IANA considerations is too late and should confuse most
readers.

						Masataka Ohta

---

From: Joe Abley <[email-masked]>
Date: Fri, 12 Nov 2021 08:46:35 -0500

> appropriate that the intended status is not BCP but informational.

The operational decisions relating to these things have already been made, as I understand it -- the delegations no longer exist. Kim and Amanda's document seems to have two purposes: (1) to document this operational reality, and (2) to update protocol specifications to reflect that operational reality.

I don't see a conflict or expect a difficulty, but I don't think decisions relating to (2) lie solely with PTI; the IETF ought to have a hand in making them, which I think is what Kim and Amanda are trying to facilitate here.

Having said all that I think it's possible that the only domain under INT that has been implicated in standards-track documents is IP6.INT, and that was taken care of long ago. So I am not arguing with you about Informational, which is quite possibly the right thing.

Joe

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 12 Nov 2021 23:08:01 +0900

Joe Abley wrote:

> The operational decisions relating to these things have already been
> made, as I understand it -- the delegations no longer exist. Kim and
> Amanda's document seems to have two purposes: (1) to document this
> operational reality, and (2) to update protocol specifications to
> reflect that operational reality.

I'm afraid (1) should be documented by a separate rfc maybe titled
as "Relationship between IETF and IANA", which should clarify
semantics of "IANA considerations" section of not only this but
also other rfcs, which was not a problem when both of the rfc
editor and IANA was the same person.

Is the "IANA considerations" section just a recommendation from
IETF/ISOC to IANA/ICANN or approved by IANA/ICANN during *modified*
standardization process of IETF?

					Masataka Ohta

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 12 Nov 2021 15:33:19 +0100

On Fri, Nov 12, 2021 at 08:46:35AM -0500,
 Joe Abley <[email-masked]> wrote 
 a message of 25 lines which said:

> made, as I understand it -- the delegations no longer exist.

nsap.int and tpc.int still exist.

---

From: Kim Davies <[email-masked]>
Date: Fri, 12 Nov 2021 13:28:08 -0800

> standardization process of IETF?

These are fair points and hopefully the language can be tweaked to make
it a little clearer. (RFC 2860 does define the relationship between IETF
and IANA, but the role of .INT was modified as a consequence of RFC
3172)

Most of the names in the draft were in the zone when we started the
inventory process a couple of years ago. For those that were lame
for over a year we removed them from the zone because they were
already functionally inoperable. For the remaining two that are in
there, there doesn't appear to be any sign that they are currently
configured to operate as documented. Specifically, {1..9}.tpc.int and
{0..9,a..f}.nsap.int all return NXDOMAIN.

Even if we are perhaps duly empowered to make such an operational
decision regarding these delegations, producing this draft and gaining
additional consensus on these actions I think will produce a better
result given the original delegations eminated from IETF work.

kim

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 14 Nov 2021 21:50:41 +0900

Kim Davies wrote:

> it a little clearer.

No, they are my comments on a possible separate document definitely
*not* *against* your ID.

So, don't modify your ID for them only to introduce weasel wording,
please.

I merely think your draft can be better if it better clarifies
that the decisions are made by not IETF but IANA/ICANN, which
should be *already* accepted by the Internet community including
IETF.

> (RFC 2860 does define the relationship between IETF
> and IANA
But, the rfc says deprecation of some domain under "int" must
be decided by not IANA but IETF, which the Internet community
including IETF is not practical, which should result in your ID.

> but the role of .INT was modified as a consequence of RFC
> 3172)

Rfc3172 certainly, though silently, assumes such consequences,
rfc2860 requires IETF, not IANA, should make them loudly explicit.

But, as the issues are highly operational for which IETF do
not and should not have much to do with, if something is
wrong, it should be rfc2860.

Moreover, as IETF is not governing the operational reality
of the Internet, I don't think it necessary to modify
rfc2860 before making your ID an up-to-date informational
rfc to reflect the operational reality.

					Masataka Ohta

PS

To accommodate operational reality, I think, IANA functionalities
should be divided by three, one for domain name under ICANN, another
for IP addresses under operators community of RIRs and remaining
inoperational ones for IETF/ISOC, which, for formality, requires
modifications to rfc2860.

But, don't interpret it as my objection to your ID. We must move on.