Re: [tlp-interest] Proposed Policy on Rights in IANA Parameter Registry Data

"R. Atkinson" <> Fri, 18 September 2020 12:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3427C3A0A35 for <>; Fri, 18 Sep 2020 05:58:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id k0hHEm4DG6IL for <>; Fri, 18 Sep 2020 05:58:01 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0A0C63A09BD for <>; Fri, 18 Sep 2020 05:57:56 -0700 (PDT)
Received: by with SMTP id q5so5920440qkc.2 for <>; Fri, 18 Sep 2020 05:57:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+fZFiRLk5FErs4k+xLTokru8Xo6KRWn6V3ldUAQ7zAQ=; b=ZZsH1cnq5o5FavXTrwKJEo6LMAbfrckABIDNgbI+/WWux0n5QyKEADLJ9vQxHDGYAy LDucpEDU5/WKxU0mvq4+eWRzhXfK56LZmGrcG/qKyN9IH58QLuXrUvfO2tz4o67r5iJz GrNZHpWD77kvPlOQOkqc8/tFrzOKN7NaEJ+onl4YIZEDzM67hU4o54qjjS7rLpCcxyN1 Gaqwsrs+O3xud6blHHLdT2xNuFfe5TDUx1r2kxBemNQua+FJ9d1DENF50UnkZUfsZxTl aLPNlK9HzdQYF5bTg03kSnUCxTWiKdi87HwU85/0zc2eMKX8e6p+QZZhhR3bkD0Xvq5v ZOtA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+fZFiRLk5FErs4k+xLTokru8Xo6KRWn6V3ldUAQ7zAQ=; b=GL2iIqski4DnDS4pH67xCctApPX+AL9UvcE3Y/FkGL0raQve64xNZYtR/5jPAxOZ30 84xPi4me1zfgfInUurRyRqPbOPpXhZauYAFIhtJMr16vB0wsGcMLwc66PWm0FGzKQcjt muAPkkYDcCcdb2tl+GIHZak/s/4b//po8suL4g8OI2yReG0RQqN8ppukgf+gMIB3XtU4 jKZufmhXtwjTpYvOP4yjkNwXHpVB6PdB5uEgGy+CZ4cIICDTHlp2mczLrJ6oX15JL2nj 3AcHyWSKiqeiJXVkGIqlLalqxv+eaynf3DxfUgBP3P2+S0FRlrqSAu92vOVXdrv9Y+rl vp1w==
X-Gm-Message-State: AOAM5339yZjMOxW9pJ+gcaNPxgjXB8UQqQ5kgzMBtzmyxIshFLnLnbHy DXNBhjVeKuwWU5XifAeO5IiCbaKwzdM=
X-Google-Smtp-Source: ABdhPJx3OJJfDsoOY34oHvYRagurMr8cgF0Fh59yyWll1gTXsgYmC22+hyw6YzA7FhkjvSOMIGE3Lw==
X-Received: by 2002:a05:620a:1ef:: with SMTP id x15mr31785225qkn.182.1600433875988; Fri, 18 Sep 2020 05:57:55 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id s192sm1897458qke.50.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Sep 2020 05:57:55 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\))
From: "R. Atkinson" <>
In-Reply-To: <>
Date: Fri, 18 Sep 2020 08:57:54 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Joel Halpern <>
X-Mailer: Apple Mail (2.3445.104.15)
Archived-At: <>
Subject: Re: [tlp-interest] Proposed Policy on Rights in IANA Parameter Registry Data
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of proposed revisions to the Trust Legal Provisions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 18 Sep 2020 12:58:07 -0000

> On Sep 17, 2020, at 20:20, Joel M. Halpern <> wrote:
> On the one hand, it is clearly not the trust's intention to change the IANA policies for any of the allocation.

In my view, that ought to be made much more clear — and it ought to be tightly
coupled in words with any declaration (CC0 or some edited version of CC0) 
for avoidance of confusion or doubt.  It needs to be crystal clear and totally 

> On the other hand, with the existing understanding of policy (that we are trying to formalize) anyone can copy the IANA data to their own site, and then ad entries claiming other values on their site.  I do not know of any way we can sensibly change the terms to prevent that.

The goal would be to avoid the situation where someone mis-read the (CC0 or
whatever new) statement to mean that anyone now is permitted to make valid 
allocations/assignments to IANA registries without following the IETF/IANA 

Is that more clear as a statement of concern ?