Re: [Last-Call] Last Call: <draft-davies-int-historic-04.txt> (Deprecating infrastructure "int" domains) to Informational RFC

George Michaelson <ggm@algebras.org> Thu, 20 October 2022 00:38 UTC

Return-Path: <ggm@algebras.org>
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 07A95C15257D for <last-call@ietfa.amsl.com>; Wed, 19 Oct 2022 17:38:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20210112.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gK45d3GS-IrT for <last-call@ietfa.amsl.com>; Wed, 19 Oct 2022 17:38:46 -0700 (PDT)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FE1CC152578 for <last-call@ietf.org>; Wed, 19 Oct 2022 17:38:45 -0700 (PDT)
Received: by mail-lj1-x230.google.com with SMTP id x18so24306685ljm.1 for <last-call@ietf.org>; Wed, 19 Oct 2022 17:38:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=P1O/RYe2L7Q7t8l5b2mOprppFaDd/sli3yyKGEaW8i4=; b=2nakNh3A1veegjWbDyRkNznhowK0UnLTxuwDbFcBJDCTPa55eS7i1fyEtijQw4mB89 NiSI1fQ0zR/z1UBxRRwJOEoSztZ4KPPqJUeaBg6R54iO6T0lpHiLadeciNuSPbjNprzs MuTKqfR0/+nf/+5UXJ51cG74O8nW17qjQOGlh6SaP8SWFodFemYOg38X2nnYZJW0B3M3 ZwetVzWR3PARtb0Z4jslL6AdsIMNZIRI68wuBC1yWygz1KIuSnXR2hxSLBF6W8NqlHOW utcV6AjHi8aX3q3W6Mr3jufGIZO1tKMSeRYxHGDuBKIn7SYxlYjEqIQdE3pdAS2XXeHV 5jUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=P1O/RYe2L7Q7t8l5b2mOprppFaDd/sli3yyKGEaW8i4=; b=Rd44cOMv2e5E5Tt752unQwNe4lMCJF1I9giqzSsKtz4649WgvyICFv7DrGqmnwV20s oJ3/SrCyD62t3h5MjWCz5vRAU+V4uLG/9T7CRKBD6saI1Vs2DA/KieLFCTc0V6JfYr6+ U+z75vJuOV+OqXr6WMsYHCnEHfgI1Zzhyq8wHpsK9Xafx4TAzbYgF/iprSPXcS5gu440 osh+mvqbA0KPRFnIYhFkivlcDFzMZy48pRV63VJE8nrJoYQODo2GiZ2IY9rW/csBsCTn 79hK5JKtLqQV0a/LlOLTXZANcpAhT/35T+itrIjBvncJ2Wz44W4lwJ53c43HSedSwOHf d6XQ==
X-Gm-Message-State: ACrzQf2GbmwbmYLw0bjbCT3B/mRr+/Rbcg5hd4asw0w63CnRuz6w7E6f EChhIu4KtF61nwGdICAAfu6JSAVsXdr3ZDkrkQkcPw==
X-Google-Smtp-Source: AMsMyM5c4f1ttcuTdWEFcgmnKAjticYDIqlm7Thw9jf7FoTi5ezRLGAbg3Lj4z1Xf7UglbUu3v04YcAEiTYaJIL/IH4=
X-Received: by 2002:a2e:9658:0:b0:26f:d3be:e7b4 with SMTP id z24-20020a2e9658000000b0026fd3bee7b4mr3585107ljh.466.1666226323620; Wed, 19 Oct 2022 17:38:43 -0700 (PDT)
MIME-Version: 1.0
References: <166621075802.44847.14382611991776479938@ietfa.amsl.com> <371922.1666215280@dyas> <Y1B7IPGPfzDcDDxE@faui48e.informatik.uni-erlangen.de> <295948c3-b116-365f-a682-6e286be69ffb@gmail.com> <Y1CCh1XOwkNFafet@faui48e.informatik.uni-erlangen.de> <CAKr6gn127iGBjtB2+Q=80Tydfp8gnU0NOsFskU96D8digL6bUQ@mail.gmail.com> <9BF773D1-DFD2-457E-8E71-5126CCB81FF4@sobco.com>
In-Reply-To: <9BF773D1-DFD2-457E-8E71-5126CCB81FF4@sobco.com>
From: George Michaelson <ggm@algebras.org>
Date: Thu, 20 Oct 2022 10:38:32 +1000
Message-ID: <CAKr6gn3sxCmZJkagN9-fzPa_c1ssW0yGofXXEROKz3q4JtzLyg@mail.gmail.com>
To: Scott Bradner <sob@sobco.com>
Cc: Toerless Eckert <tte@cs.fau.de>, Brian E Carpenter <brian.e.carpenter@gmail.com>, last-call@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/JdW5qG86C03bTGbYi__DXaO98_I>
Subject: Re: [Last-Call] Last Call: <draft-davies-int-historic-04.txt> (Deprecating infrastructure "int" domains) to Informational RFC
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
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, 20 Oct 2022 00:38:50 -0000

So the problem as you state it (if I understand this right) is that
all this draft does, is disclaim subdomains for use by IETF and
related bodies, it seeks to make no other alteration to the delegation
of authority of the domain, or disclaim registrar functions for the
domain.

But, it changes language relating to occupancy rules for the domain.
To me, that demands a "why" question (and answer) and "on whose
authority or request" and "is this actually necessary"

I was wrong to suggest it can simply be disclaimed, I didn't realise
there were other non-IETF occupants to whom some duty of care remains.
Clearly, if I understand that right, IANA should not simply walk away
from registrar functions.

Do I have this right?

cheers (and thanks for the clarification)

-George

On Thu, Oct 20, 2022 at 10:35 AM Scott Bradner <sob@sobco.com> wrote:
>
> .int domain is in use - see, for example, itu.int
>
> the IETF can clearly ask that any .int second level domains that were created by IETF action
> (e.g. tpc.int) be removed but less clearly can the IETF ask that .int second level domains that the IETF had no
> part in creating be removed
>
> .int is run by the IANA because it has always been run by the IANA - Jon at first
> then the IANA when the IANA came into existence
>
> well prior to ICANN being formed there was talk about handing management of .int over to the ITU -
> Jon had proposed that, but told the ITU that he needed some documentation on how .int
> would be run before he would do that (I was in at least two meetings between Jon and an ITU person
> about the topic) - the two documents were
>         1/ a clear statement on who could register in .int
>         2/ a document describing how the ITU would actually operate the servers
>
> but the ITU never produced the documents so the transfer never happened
>
> I was not "in the room" when Jon agreed to put tpc in .int - but Marshall Rose was and
> also I assume Carl Malamud - one could ask them what their argument was
>
> Scott
>
> > On Oct 19, 2022, at 7:23 PM, George Michaelson <ggm@algebras.org> wrote:
> >
> > I agree with what I thik Toerless is saying here.
> >
> > 1) the wording in the draft appears to (re)open the door to use of the
> > domain. This is despite the intent of the draft and I believe the
> > organisation, to remove dependency and use of the domain. Why is this
> > wording being used?
> >
> > 2) why does IANA continue to "operate" the domain, if there is no
> > dependency and no forseen use? The proper way to get shot of a burden,
> > is to give it to somebody else. Re-delegate to ICANN and make them
> > responsible for the registrar decisions about what treaty bodies are
> > allowed to have state in .INT
> >
> > Toerless? Is that a reasonably good take on what you said? It's what I
> > think you said.
> >
> > -G
> >
> > --
> > last-call mailing list
> > last-call@ietf.org
> > https://www.ietf.org/mailman/listinfo/last-call
>