Subject: Re: [Last-Call] Last Call: <status-change-int-tlds-to-historic-00.txt> (Moving TCP.INT and NSAP.INT infrastructure domains to historic)

From: S Moonesamy <[email-masked]>
Date: Wed, 30 Mar 2022 01:12:39 -0700

Hello,
At 08:04 AM 29-03-2022, The IESG wrote:
>The IESG has received a request from the Internet Engineering Steering Group
>IETF (iesg) to consider the following document: - 'Moving TCP.INT and
>NSAP.INT infrastructure domains to historic'
>   <status-change-int-tlds-to-historic-00.txt>

The IESG sent a request to itself.  That looks odd.

It took me a few minutes to figure out whether "tcp.int" existed or 
not.  There may be a typo in the initial request.

The policy for the subdomain is specified in RFC 1530.  Can the IETF 
override that policy?

The statement invoked by the IESG is for the reclassification of a 
RFC.  If I am not mistaken, it was not intended for the reclassifying 
subdomains.

Regards,
S. Moonesamy

---

From: Brian Carpenter <[email-masked]>
Date: Wed, 30 Mar 2022 22:01:57 +1300

Hi SM,

Under the IETF's basic agreement with ICANN, the IETF has authority over
domain names used for technical purposes, such as these two. We included
that provision back in 2000 for exactly this sort of situation.

Regards,
    Brian Carpenter
    (via tiny screen & keyboard)

On Wed, 30 Mar 2022, 21:19 S Moonesamy, <[email-masked]> wrote:

> --
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call
>

---

From: Joe Abley <[email-masked]>
Date: Wed, 30 Mar 2022 11:04:02 +0200

For some reason I didn't see the original message, and searching datatracker.ietf.org for "status-change-int-tlds-to-historic" reveals no documents. So I am replying to what I have, but perhaps matters have been overtaken by events.

On Mar 30, 2022, at 10:19, S Moonesamy <[email-masked]> wrote:

> [...]
> It took me a few minutes to figure out whether "tcp.int" existed or not.  There may be a typo in the initial request.

Yes, it seems possible to me too that the domain the document is talking about is TPC.INT ("The Phone Company"). TPC.INT is still delegated from the INT zone, and it has functional nameservers.

> The policy for the subdomain is specified in RFC 1530.  Can the IETF override that policy?

I suspect the IESG can declare its published documents relating to that domain to be historic which will aid the administrators of the INT domain in making decisions about the remaining delegations. At least some of the names attached to the TPC.INT project are still eminently contactable and it seems entirely plausible to me that a friendly consensus could be reached amongst everybody concerned.

The purpose of the INT domain has been a bit ambiguous for various periods of its existence. There have been several ad-hoc projects attached to it over time, including well-known examples like IP6.INT and perhaps more obscure examples like IP4.INT and NSAP.INT. The general trend seems to have been to unify the policy around .INT for the purpose of serving international treaty organisations, its nominal purpose.

> The statement invoked by the IESG is for the reclassification of a RFC.  If I am not mistaken, it was not intended for the reclassifying subdomains.

It is not uncommon for there not to be an obvious single point of policy administration when the closer you get to the root of the namespace, especially when you stir in ideas and services conceived in a gentler, more informal era.

I don't think it's necessary for the IESG to claim or try to exert policy control over the INT or TCP.INT domains for a measure such as I imagine this document might be taking to be useful.

Joe

---

From: Ted Hardie <[email-masked]>
Date: Wed, 30 Mar 2022 11:46:30 +0000

I do not think this last call is well-formed.  There is no link to the
document and it is not available via the datatracker.  It's difficult to
see how the community can successfully give advice on a matter with no
document (and not even an abstract).

May I ask that the IESG consider re-issuing this last call with the
appropriate pointers?

thanks,

Ted Hardie

On Tue, Mar 29, 2022 at 4:08 PM The IESG <[email-masked]> wrote:

> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2022-04-26. Exceptionally, comments
> may
> be sent to [email-masked] instead. In either case, please retain the
> beginning
> of the Subject line to allow automated sorting.
>
> Abstract
>
>
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/status-change-int-tlds-to-historic/
>
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

---

From: "John Levine" <[email-masked]>
Date: 30 Mar 2022 13:03:36 -0400

It appears that Ted Hardie  <[email-masked]> said:
>-=-=-=-=-=-

At the very least, it should say TPC.INT, not TCP.INT.

What they're proposing is reasonable but it needs a better paper
(electronic?) trail.

R's,
John
-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Warren Kumari <[email-masked]>
Date: Wed, 30 Mar 2022 13:02:23 -0700

> May I ask that the IESG consider re-issuing this last call with the

This is probably my fault - we don't do very many status-changes, and
figuring out how to drive the datatracker for this is hard — the DT usually
sucks in the Abstract automatically and populates the Last Call text, but
because a status-change document isn't *really* a document it didn't seem
to do so…

With that said, this is **just** the Status-Change document, and there is a
link to:
https://datatracker.ietf.org/doc/status-change-int-tlds-to-historic/

This notes that this document is the status-change (as suggested by
https://www.ietf.org/about/groups/iesg/statements/designating-rfcs-historic-2014-07-20/
and
will be replaced when the "actual" document is published):
"At some point, it is sent to an appropriate AD to request publication. The
AD creates a status-change document, with an explanation that points to the
I-D. The I-D and the status-change are then last-called together, after
which the IESG evaluates and ballots on both."

The **actual** document (which is also in Last Call) is
https://datatracker.ietf.org/doc/draft-davies-int-historic/

So, this just notes that draft-davies-int-historic
<https://datatracker.ietf.org/doc/draft-davies-int-historic/> is making
some documents historic, and that you should read that. This whole change
process is somewhat baroque, especially if there is a draft doing it —
someone writes a draft, it gets last-called, and you *also* have a
status-change document which also gets last-called, and then the
status-change document disappears in a poof of smoke and the ID replaces it
when it becomes an RFC….

Anyway, I'll try abort this LC, and restart it with 1: TCP fixed to TPC
(assuming that I can stop my fingers from autocorrecting it) and 2: the
status-change text (
https://datatracker.ietf.org/doc/status-change-int-tlds-to-historic/)
copied into the Abstract / LC text…

Wheee, are we having process fun yet? :-P
W

---

From: Warren Kumari <[email-masked]>
Date: Wed, 30 Mar 2022 13:13:30 -0700

> because a status-change document isn't *really* a document it didn't seem

Ah, I may have found an odd datatracker interaction — I went to restart the
IETF LC, and when I clicked "Reset to template text" it generated a much
more useful last call text:

"
The IESG has received a request from an individual participant to make the
following status changes:

- RFC1706 from Informational to Historic
    (DNS NSAP Resource Records)

- RFC1528 from Experimental to Historic
    (Principles of Operation for the TPC.INT <http://tpc.int/> Subdomain:
Remote Printing --
    Technical Procedures)

The supporting document for this request can be found here:

[email-masked] mailing lists by 2022-04-27. Exceptionally, comments may

The affected documents can be obtained via
https://datatracker.ietf.org/doc/rfc1706/
https://datatracker.ietf.org/doc/rfc1528/

IESG discussion of this request can be tracked via
https://datatracker.ietf.org/doc/status-change-int-tlds-to-historic/ballot/
"

This is what I was expecting the DT to send — hopefully this makes the
entire thing more clear. This Last Call was only supposed to be a support
document for https://datatracker.ietf.org/doc/draft-davies-int-historic/ and
not actually *do* anything itself…

Anyway, I'll restart the IETF LC on this status change document with a
clarified LC text…

W

> With that said, this is **just** the Status-Change document, and there is
> a link to: https://datatracker.ietf.org/doc/
> status-change-int-tlds-to-historic/
>
> https://www.ietf.org/about/groups/iesg/statements/
> designating-rfcs-historic-2014-07-20/ and will be replaced when the
> "actual" document is published):
> "At some point, it is sent to an appropriate AD to request publication.
> The AD creates a status-change document, with an explanation that points to
> the I-D. The I-D and the status-change are then last-called together, after
> The **actual** document (which is also in Last Call) is https://
> datatracker.ietf.org/doc/draft-davies-int-historic/
>
> status-change text (https://datatracker.ietf.org/doc/
> status-change-int-tlds-to-historic/) copied into the Abstract / LC text…
>

---

From: John C Klensin <[email-masked]>
Date: Wed, 30 Mar 2022 19:46:49 -0400

(I just saw Warren's note and the new Last Call before sending
this.  I've adjusted this note somewhat but don't want to delay
it further, so, if there are comments that no longer seem
applicable, please ignore them.)

--On Wednesday, March 30, 2022 13:03 -0400 John Levine
<[email-masked]> wrote:

>> I do not think this last call is well-formed.  There is no
>> link to the document and it is not available via the
>> datatracker.  It's difficult to see how the community can
>> successfully give advice on a matter with no document (and
>> not even an abstract).
>> 
>> May I ask that the IESG consider re-issuing this last call
>> with the appropriate pointers?
> 
> What they're proposing is reasonable but it needs a better
> paper (electronic?) trail.

Yes.  And agree with "ill-formed" as well (more on that below).

Noting that this document normatively and procedurally depends
on draft-davies-int-historic (even more clearly in today's
version) and that the actions it does (or does not) specify
depend on that other draft, these comments are addressed
partially to the other draft.  However, in addition to pointing
out the deficiencies of that I-D, it identifies specific issues
that make this one even less well-formed and more incomplete.

Additional nit-picking:  

(1) If the plan is to get rid of TPC.INT and its uses,
draft-davies-int-historic (referred to as "the I-D" below) or
some other document should also address RFC 1703.  Without doing
something about that radio paging document, the domains cannot
possibly be made historic (whatever that means) because there
would still be an active spec for which the IETF or IAB
presumably have (or would claim) responsibility that uses the
domain.    FWIW, that is something I found by doing a simple
search or grep on the ASCII form of the RFC Index [1], a type of
exercise I would recommend to the author of the status change
document and the authors of the I-D..    Having those sorts of
loose ends in this document and process is, IMO, even worse than
the "TCP.INT" problem that has now been fixed.

(2) The I-D says, in Section 3.2, "...should be deemed historic
given the transfer of these functions to the "arpa" top-level
domain [RFC3172]".  But 3172 does not transfer anything.  Its
Section 5 merely says that infrastructure domains not already in
"arpa" should follow its requirements and that 'consideration
should be given to migrating them into "arpa" as and when
appropriate.'  Section 3.2 of the I-D, if correct, is close to
meaningless in the absence of addressing the move in a
meaningful way and the process(es) that were followed in making
them, presumably including additional references.  Probably that
should reference a publicly-available copy of "Purchase Order
No. 40SBNT067020" and/or the letter from Karen Rose that appears
as Appendix A of 3172 (not just a vague "guess what we are
actually referring to" pointer to the whole of 3172), and
whatever documentation exists of ICANN and IAB correspondence
about making the move.   Preferably there should also be a
report on the completion of that work [2] (and see (4) below).
And, again, if those changes have not been made, the premise
behind moving some domains to historic is just not plausible.

(3) RFC 3172 also does not say a word about "international
databases".   If this I-D intends to use that term as a synonym
for "infrastructure domain", as defined in RFC 3172, it should
either say so or use 3172's terminology.   I don't know what an
"international database" is although I can makes guesses. Most
things to which I might apply that term have nothing to do with
either the INT or ARPA TLDs.  I also note that, while I assume
the IETF would not create a subdomain of ARPA that did not have
relevance in multiple countries, I can find nothing in 3172 that
would prohibit that so "international" is just justified by any
documents I have been able to find.

(4) Now, if a significant fraction of this confusion is due to
actions being held in abeyance until the I-D is ready for
publication and the action specified in this Last Call ready to
be taken, situations like that are nothing new to the I-D
collection or the RFC Series.  We insert explanatory paragraphs
in documents with advice to the RFC Editor to remove them
at/before publication.  We explain in the Last Call
announcement.  And/or we do other things.  We do not leave it to
those trying to participate in a Last Call to guess or to be
generally confused.  To me, that suggests that not only this
proposed action statement (even in the new version) and the I-D
are, borrowing words from Ted, ill-formed.

(5) I don't remember seeing earlier examples in which a phrase
like "should be deemed historic" is considered an "update" to a
prior document.  Unless there are enough such examples to
establish a precedent, I suggest that I-D, having explained why
those domains and the defining documents are obsolete,  simply
obsolete them on the theory that they are of no further use.
If someone believes that the use of "historic" provides more
value to older documents than making them obsolete, either the
I-D or this proposed action and Last Call notice should make
that clear. 

Conclusion:   The I-D is not nearly ready for publication.
Obviously, if it is not, the Last Call on declaring some domains
Historic (again, whatever that means), is premature.   At
minimum, there should be a revised version of the I-D that is
carefully proofread, creates or points to the "paper
(electronic?) trail" John Levine suggests, and responds to any
input he or the RPC have on "make historic" as a form of
"updates".  My first four comments above are certainly part of
the paper trail issue.  And, preferably, to avoid wasting the
time of the community, both Last Calls should be stopped until
that revised draft (or another plan) is available.   A new Last
Call (or pair of them) can then be initiated.

I have some additional, possibly more serious, concerns, but
that note may take a few more days to complete.

best,
   john

[1] While a search or grep on the old-style rfc-index.txt works,
putting "TPC.INT" (or '"TPC.INT"') into the online version at
https://www.rfc-editor.org/ (which claims to support search
phrases) yields error messages.  Drawing a message from that is
certainly out of scope for this note.

[2]  Assuming it has been completed -- I note that there are
still delegation records for TPC.INT and, fwiw, that they are
inconsistent with the WHOIS records for that domain.  If you
(the other John) or I did that, and the registry were adhering
to the spirit of ICANN requirements, they would be sending us
nasty notes.  I hope we can look forward to seeing a note from
the TLD registry operator (IANA) to the SLD operator (perhaps
also IANA) suggesting some effort... or, of course, a report on
such a note.  Unfortunately, probably too late for either the
correspondence or the report to be posted or summarized two days
from now :-(

---

From: Ted Hardie <[email-masked]>
Date: Thu, 31 Mar 2022 08:31:24 +0000

Hi Warren,

This new text is much more useful, thanks for the follow-up.  The only
thing I noted that still wasn't quite working was the link here:
https://datatracker.ietf.org/doc/status-change-int-tlds-to-historic/ballot/
That gives me a 404.  It may be that it doesn't create the actual page
until you push the buttons, but it might be worth a quick test once you
reach that point, just to make sure there isn't another odd incantation
needed here.  It also might be the case that this should be a pointer to
the ballot for https://datatracker.ietf.org/doc/draft-davies-int-historic/

regards,

Ted

On Wed, Mar 30, 2022 at 9:13 PM Warren Kumari <[email-masked]> wrote:

> Ah, I may have found an odd datatracker interaction — I went to restart
> the IETF LC, and when I clicked "Reset to template text" it generated a
> much more useful last call text:
>
> "
>> a link to:
>> https://www.ietf.org/about/groups/iesg/statements/designating-rfcs-historic-2014-07-20/ and
>>>> [email-masked] mailing lists by 2022-04-26. Exceptionally,
>>>> comments may

---

From: S Moonesamy <[email-masked]>
Date: Thu, 31 Mar 2022 07:18:53 -0700

Hi Joe,

Thanks to Brian for the pointer.

At 02:04 AM 30-03-2022, Joe Abley wrote:
>For some reason I didn't see the original message, and searching 
>datatracker.ietf.org for "status-change-int-tlds-to-historic" 
>reveals no documents. So I am replying to what I have, but perhaps 
>matters have been overtaken by events.

I was able to reproduce the problem described above.

>I suspect the IESG can declare its published documents relating to 
>that domain to be historic which will aid the administrators of the 
>INT domain in making decisions about the remaining delegations. At 
>least some of the names attached to the TPC.INT project are still 
>eminently contactable and it seems entirely plausible to me that a 
>friendly consensus could be reached amongst everybody concerned.

The documents relating to the domain are not IESG-approved 
documents.  They are not covered by the agreement which supplements 
the ICANN-IETF MoU signed between the IETF Administration LLC and the 
Internet Corporation for Assigned Names and Numbers.

>It is not uncommon for there not to be an obvious single point of 
>policy administration when the closer you get to the root of the 
>namespace, especially when you stir in ideas and services conceived 
>in a gentler, more informal era.

Yes.

>I don't think it's necessary for the IESG to claim or try to exert 
>policy control over the INT or TCP.INT domains for a measure such as 
>I imagine this document might be taking to be useful.

The IESG will be asserting policy control by moving forward.

Regards,
S. Moonesamy

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 1 Apr 2022 09:05:23 +1300

> Internet Corporation for Assigned Names and Numbers.

That doesn't matter. The domain names concerned are in the category
of "assignments of domain names for technical uses" defined in the
basic MoU, which are explicitly "not considered to be policy issues"
and remain under the IETF's control.

> The IESG will be asserting policy control by moving forward.

No, they are "technical uses" and not a matter of policy.
The wording in the MoU was designed explicitly for such cases.
(I was the main document editor as well as a signatory.)
This whole matter is IETF business.

Regards,
     Brian

---

From: John C Klensin <[email-masked]>
Date: Thu, 31 Mar 2022 22:29:29 -0400

--On Friday, April 1, 2022 09:05 +1300 Brian E Carpenter
<[email-masked]> wrote:

>> documents.  They are not covered by the agreement which
>> supplements the ICANN-IETF MoU signed between the IETF
>> Administration LLC and the Internet Corporation for Assigned
>> Names and Numbers.
 
> That doesn't matter. The domain names concerned are in the
> category of "assignments of domain names for technical uses"
> defined in the basic MoU, which are explicitly "not considered
> to be policy issues" and remain under the IETF's control.

Brian,

I had planned to save this for another day but, while I think it
is easy to categorize NSAP.INT that way, I wonder on what basis
you justify subdomains of TPC.INT as "technical use".  It is an
SLD that has a rather-odd looking subdomain structure, one that
(deliberately if I remember the discussions at the time
correctly) does not require any special handling in the DNS
itself. Beyond that, it is, as far as the DNS is concerned,
rather ordinary, with some applications-level protocols using
the DNS to simply map names (however odd-looking the might be to
addresses.  

Let me illustrate with a few examples and accompanying questions:

Suppose I were running a circus with several touring companies,
each of which had several carriages and wagons for different
types of performers, wagon numbers for each performer type, and
each wagon contained one or more hosts that I wanted to
identify. I also got together with other circus operators,
plunked down my money, and got an appropriate TLD. To avoid
arguments about who got which names, I numbered the companies,
the carriages, and the computers, ending up a DNS structure
looking like 

<host>.<carriage>.<performer-type>.<company>.johns-big-top.circus.
I'd then have FQDNs that looked like
    2.1.1.3.johns-big-top.circus.
and that were used for plain, ordinary, host name to address
mapping.

Is that a "technical use" even though the TLD would have to be
allocated by ICANN?  If it is not, what distinguished it from
the domain names of TPC.INT?  Number of labels aside, they look
pretty much alike once one get below the SLD?  Both are used for
name to address mapping -- no special RRs or odd interpretations
of the DATA portion of the DNS records. 

Second example:

Suppose ITU concluded that the TPC.INT numbering scheme was
really interesting and that they have a good use for it
(although probably pointing to servers belonging National
Administrations or numbering databases rather that privately
operated hosts.  They set that up using precisely the same
reversed-number labeling structure as that used by TPC.INT only
subsidiary to E164.ITU.INT.  Would that make that E164 subtree a
"technical use"?  If so, would their decision to create that
subtree suddenly put all of ITU.INT a domain under IETF control,
overriding whatever arrangements exist between ITU and IANA
because of the words in the MOU?

Third example: 

Suppose, when the ideas that led to the TPC activity came along,
it had been registered, not in INT, but in NET, but otherwise
with exactly the same structure and protocols being supported.
(The reason why it ended up in INT is a piece of history I don't
know and suddenly find interesting, but, if I had to guess, it
might be along the lines of "because they could" or "it was
free".)   Would that make it "not a technical use" just because
of the TLD used to house/anchor it?

Although I can think of several reasons why it would have been a
bad idea, the MOU could have defined "domain for technical use"
by either an enumerated list of such domains or as anything that
was not on an enumerated list of intergovernmental-type bodies.
It didn't.  It also could have said "Other than  in ARPA, ICANN
gets to decide what is or is not a technical use subdomain".  Or
it could say that with the IETF in charge or established some
sort of procedure for making the determination.  It didn't do
any of those things either.   It would have been reasonable at
the time to assert that the ARPA TLD was entirely "technical
use" and then discuss selected subdomains of INT, but it didn't
do that either: AFAICT, it does not call out either TLD by name.

That, in turn, creates some interesting questions of authority
over "domains for technical use" or even delegated subdomains
for inverse DNS lookup that might exist in assorted ccTLDs.  The
MOU implies that all of those are under IETF control, something
that would come as quite a surprise to assorted RIRs and
countries.  Unless there is a plan to update the MOU to make all
of that more clear in a way that would suit today's needs better
(an update that would presumably require signoff from ICANN,
possibly even ICANN during the time of the DOC contract and/or
DOC), we are stuck with what we have.   

Of course, the IETF and ICANN could initiate a new ICANN PDP
with the goal of creating a new MOU and, presumably, a modified
and consistent PTI agreement.  If that feels like a good idea,
let's get the PDP started now and, if we are really lucky and
things move at maximum speed, recent experience with ICANN
suggests we will be able to come back to this in five or six
years (more likely longer).

Consequently, unless you can come up with a definition of
"technical use" that makes the examples above come out as
not-technical while TPC.INT is technical, saying that TPC.INT is
"technical use" and therefore under IETF control seems like more
than a bit of a stretch.

I think there are ways to accomplish what is actually desired
here (which, in case I haven't said it lately, I'm personally in
favor of doing) without appealing to fuzzy definitions in the
MOU and having to definitively (and maybe retroactively) define
"technical use", figuring out how to update RFC 1591, creating a
clear definition of what it means to make a domain historic, and
scratching other itches and issues that might require boiling a
few oceans before the actions can be properly taken.  I'm trying
to work on a clear explanation and a proposal about how to do
that.  But I'm convinced that, if we have to invoke
hairsplitting over undefined terms like "technical use", we are
in big trouble.

     john

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 1 Apr 2022 16:11:03 +1300

On 01-Apr-22 15:29, John C Klensin wrote:
> you justify subdomains of TPC.INT as "technical use".  

Agreed that it's a strange beast with a strange history. And to
be frank, if ICANN came back and said 'No, it isn't just a
"technical use"' I'd be happy enough to say 'OK' and move on.

So it's my personal opinion that it would fall under "technical
use", but if it doesn't, and somebody else wants to obsolete it
instead of the IETF doing so, I would be perfectly content.

(Whether it should have been added to .int in the first place
is an interesting historical question, but I don't believe
it has any current impact.)

Rgds
    Brian

> It is an