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

[John C Klensin <[e-mail]>]

(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
<[e-mail]> wrote:

> It appears that Ted Hardie  <[e-mail]> said:
>> -=-=-=-=-=-
>> 
>> 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?
> 
> 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.

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 :-(