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

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 31 March 2022 20:06 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 106383A07F6 for <last-call@ietfa.amsl.com>; Thu, 31 Mar 2022 13:06:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6h-FeA0PSMT for <last-call@ietfa.amsl.com>; Thu, 31 Mar 2022 13:05:57 -0700 (PDT)
Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E72773A08C2 for <last-call@ietf.org>; Thu, 31 Mar 2022 13:05:27 -0700 (PDT)
Received: by mail-pg1-x52b.google.com with SMTP id q19so639343pgm.6 for <last-call@ietf.org>; Thu, 31 Mar 2022 13:05:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=eHw66bWuO9UYlwylr4miPaUiMCP9n++lOxN5qe7jsZQ=; b=AuppblSxJpxIVBfcEbKNkhmlmd/FfdNf5HUru3l6K3ZNtroy+60o4DhyYnoekEs22H rZC+fDY4Goe7pMRUsMVoZoZd53lmeqbl/lCvUWUOIS/1V6n6/zKDp2GQnadEk2v2hXav kZjIS+PaxENIevwwHVTjvGBY68la3+Ma2gOqL4hK9RBWtXQWcBRzDb6540diDArOgmXt s38WMSNK4Vu6/iZVbZkKbAp7UlkDWsdM9kjhWcnxOdvQN4OLaZ5fr2bbq/1vYauDrJmc w4eMFOapWRU28b/KBX0TGOU/Qd7+gaRB1K5Mqlmresy2FWd+IGd221j3wfqf+gjxmOUU XO5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=eHw66bWuO9UYlwylr4miPaUiMCP9n++lOxN5qe7jsZQ=; b=t/RlWLnttLIWuiIonGFmNH39TGtj/f5U/cAm86nCPIDjhaEQNiHZ3+ixCTc33nltVI mWbuG0mOC9Xm9poSN/XGeln5tak9VTykNMOXE9uj7NlPjoGYaSIx8ojwQLmatJZLp2dd ufkg2oBslyG3lB03yaCrxVmnljGiMNh44Vtse+qIhsPbRQZKLFMorNDU6kK4KdoVjUnK N1pO9sqwa21Ed4pntLVSZQCaMdT8JzJjcmVj9Zedgz3uB2KG7uQuvL7QwnJ3s++rWCw8 7ErO9EgpxaLyMDNkn/VcVQ83XdUc+Rjjr4WzG3vXI0U7lDkKygvjHHJylDmfUsAC1ZWR CjHg==
X-Gm-Message-State: AOAM530X5NLmCf0PyWctrZ1MDpPVwWjhsbQM+wxroeaLmDc8zEaReQAX 1P4zk9enUVP6TNBygDlln3/IrkZkn4OUrw==
X-Google-Smtp-Source: ABdhPJwK0nMdx2z/C5J9ysruCVWSuJtywBVmA4fULa8KaXpC4QQyGD4+Rr6e5b+/6StDGgRIa1jCYw==
X-Received: by 2002:a62:cf82:0:b0:4fa:e33e:4225 with SMTP id b124-20020a62cf82000000b004fae33e4225mr7164419pfg.25.1648757126679; Thu, 31 Mar 2022 13:05:26 -0700 (PDT)
Received: from ?IPv6:2406:e003:1005:b501:80b2:5c79:2266:e431? ([2406:e003:1005:b501:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id r4-20020a638f44000000b0038105776895sm166017pgn.76.2022.03.31.13.05.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 31 Mar 2022 13:05:26 -0700 (PDT)
To: S Moonesamy <sm+ietf@elandsys.com>, Joe Abley <jabley@hopcount.ca>, last-call@ietf.org
References: <6.2.5.6.2.20220330004724.07d61520@elandnews.com> <D224B6D3-762A-4254-883E-BAB7C8712048@hopcount.ca> <6.2.5.6.2.20220331063526.07f88b38@elandnews.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <5eb63308-94dc-b3dc-b251-9e90a8676c32@gmail.com>
Date: Fri, 1 Apr 2022 09:05:23 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <6.2.5.6.2.20220331063526.07f88b38@elandnews.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/Wy5qFZdxDQTPEdJGW30H8jAnTT0>
Subject: Re: [Last-Call] Last Call: <status-change-int-tlds-to-historic-00.txt> (Moving TCP.INT and NSAP.INT infrastructure domains to historic)
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 31 Mar 2022 20:06:03 -0000

On 01-Apr-22 03:18, S Moonesamy wrote:
> 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.

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.

> 
>> 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.

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

> 
> Regards,
> S. Moonesamy
>