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

From: Russ Housley <[email-masked]>
Date: Thu, 17 Sep 2020 11:56:37 -0400

The second paragraph of the document  Introduction is fine for the Internet-Draft.  After community discussion, what do you plan to say here?  Just deleting the second paragraph would leave an incomplete section.  I would prefer to see a proposal for the final Introduction and a paragraph that is to be deleted by the RFC Editor prior to publication that talks about providing the background to inform discussion.

In Section 2, you might point to the message by Steve Crocker at ICANN Chairman during the IANA Transition.  That message affirms the stated intent, and IANA was a department of ICANN at the time.

Section 4.1, number 2:  It seems wrong to capitalize "You".

Russ

> On Sep 16, 2020, at 10:09 PM, The IETF Trust <[email-masked]> wrote:
> 
> The IETF Trust is asking for community input on a Proposed Policy on Rights in IANA Parameter Registry Data as explained in Draft-halpern-trust-ianapolicy  (https://www.ietf.org/id/draft-halpern-trust-ianapolicy-00.html).
> 
> Background:  The IANA Parameter Registry Data is not subject to copyright, and is intended to be freely and openly usable by adopters.  However, no formal notice of this appears on the IANA Parameter Registry Data and the absence of a formal notice has caused confusion for some adopters which has resulted in many emails to IANA seeking guidance.    This proposed policy by the IETF Trustees is intended to clarify the situation by providing a formal declaration that the material is to be considered in the Public Domain as detailed in the Creative Commons Zero (CC0) declaration.   
> 
> The IETF Trustees believe that this assertion is in keeping with the current and historic intention for the material, and that this declaration neither adds nor removes any compliance restrictions to the open and free use that is intended for the data in the IANA Parameter Registry.  This proposed policy is merely a means to clarify the intended usage rules to those whom have been confused by the absence of a formal declaration.
> 
> This has been developed by the IETF Trustees with input from the IETF Trust’s legal counsel, and with engagement with IANA. 
> 
> Please read the draft for specifics of the proposal, the legal aspects behind it, and the motivation for the policy before commenting as the draft attempts to address what are anticipated to be common questions on the proposal.
> 
> This consultation will last for 30 days.
> 
> Please send comments [email-masked] before October 17,2020
> 
> Thank you,
> Glenn Deen,    IETF Trust Chair on behalf of the IETF Trustees

---

From: "John Levine" <[email-masked]>
Date: 17 Sep 2020 14:13:19 -0400

In article <[email-masked]> you write:
>The second paragraph of the document  Introduction is fine for the Internet-Draft.  After community discussion, what do you
>plan to say here?  Just deleting the second paragraph would leave an incomplete section.  I would prefer to see a proposal
>for the final Introduction and a paragraph that is to be deleted by the RFC Editor prior to publication that talks about
>providing the background to inform discussion.

I think our intention is to add it to the set of licenses that the Trust offers at

https://trustee.ietf.org/licenses.html

R's,
John

>In Section 2, you might point to the message by Steve Crocker at ICANN Chairman during the IANA Transition.  That message
>affirms the stated intent, and IANA was a department of ICANN at the time.

A reference would be helpful.  Can't find it after a few minutes of googlage.

R's,
John

>Section 4.1, number 2:  It seems wrong to capitalize "You".

It's a quote from existing boilerplate.

---

From: Russ Housley <[email-masked]>
Date: Thu, 17 Sep 2020 14:50:36 -0400

> On Sep 17, 2020, at 2:13 PM, John Levine <[email-masked]> wrote:
> 

https://mailarchive.ietf.org/arch/msg/internetgovtech/eQOImpFWe-umTZje0_3Ih8-XtGU/ <https://mailarchive.ietf.org/arch/msg/internetgovtech/eQOImpFWe-umTZje0_3Ih8-XtGU/>

Russ

---

From: Saeid Hob Shoar <[email-masked]>
Date: Fri, 18 Sep 2020 00:03:58 +0430

I'm sorry, if your time is taken by the software, I will try to increase
the internet speed of my system, but it will reach 12 megabytes, because
now it is finally 7 megabytes.

‫‪Russ Housley‬‏ <‪[email-masked]‬‏> در تاریخ پنجشنبه ۱۷ سپتامبر ۲۰۲۰
ساعت ۲۳:۲۰ نوشت:‬

> In Section 2, you might point to the message by Steve Crocker at ICANN
> Chairman during the IANA Transition.  That message
> https://mailarchive.ietf.org/arch/msg/internetgovtech/eQOImpFWe-umTZje0_3Ih8-XtGU/
>
> Russ
>
> _______________________________________________
> tlp-interest mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tlp-interest
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 17 Sep 2020 18:13:39 -0400

One aspect that I am not sure is clear.  Unless the community wants this 
as an RFC for some reason, the trust does not plan to publish it as an 
RFC.  The purpose of publishing the draft is to give the community an 
opportunity to comment on the planned policy statement.

Yours,
Joel

On 9/17/2020 2:50 PM, Russ Housley wrote:
> 
>> On Sep 17, 2020, at 2:13 PM, John Levine <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>> In Section 2, you might point to the message by Steve Crocker at 
>>> ICANN Chairman during the IANA Transition.  That message

---

From: "R. Atkinson" <[email-masked]>
Date: Thu, 17 Sep 2020 19:37:20 -0400

> On Sep 16, 2020, at 22:09, The IETF Trust <[email-masked]> wrote:
> This proposed policy by the IETF Trustees is intended to clarify the situation by providing a formal declaration that the material is to be considered in the Public Domain as detailed in the Creative Commons Zero (CC0) declaration.   

Hi,

I think it likely that such a formal declaration would cause people to believe
that anyone can use OR allocate — any value (including values which are
reserved or otherwise not yet formally assigned by IANA) for any purpose
they wish.

From a protocol interoperability perspective, it is important that the current
situation where defined policies guide IANA and IANA controls what is in
the IANA registries remain under IETF & IANA control.

The alternative to the current policy-driven IANA management of the IANA
registries is likely to be chaos and increased non-interoperability.

It might be (not sure) that this concern could be resolved by some declaration 
other than CC0 or by adding additional words as an integral part of some 
declaration (to be written by Trust lawyers) in the style of CC0 but explicitly 
reserving IANA control over registry allocations (in accord with the various 
allocation policies which have been defined and will be defined in future).

Yours,

Ran

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 17 Sep 2020 20:20:19 -0400

On the one hand, it is clearly not the trust's intention to change the 
IANA policies for any of the allocation.

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.

Was that the abuse case you had in mind Ran, or were you considering 
some other kind of problem?
Yours,
Joel

---

From: "John Levine" <[email-masked]>
Date: 17 Sep 2020 20:37:30 -0400

>IANA policies for any of the allocation.

Right, that's controlled by agreements between the IETF and PTI.  Nothing
changes there.

>site, and then add entries claiming other values on their site.  I do not 

Unless they claim they are IANA or the IETF, in which case there could
be trademark issues, we couldn't if we wanted to. 

This document says nothing about trademark, only copyright. The list
of parameters is a collection of facts, which we believe are not
subject to copyright in the U.S. (See a court decision called Feist
vs. Rural Telephone.)

The reason we're doing the CC0 license is that we keep hearing from
companies with (over-)cautious lawyers who are worried that someone
might object if they use the IANA parameters in any way at all. We
don't think they need permission, but under the circumstances it's
easier to say "yes, you have permission" than to say "no, you don't
need permission."

R's,
John

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 18 Sep 2020 11:08:02 +1000

Perhaps unsurprisingly, I support this - thanks!

Q: Is the policy going to be enacted in 30 days, or when the draft becomes an RFC (does it need to?), or...?

Cheers,

> On 17 Sep 2020, at 12:09 pm, The IETF Trust <[email-masked]> wrote:
> 
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

--
Mark Nottingham   https://www.mnot.net/

---

From: Sawai Somnuek <[email-masked]>
Date: Fri, 18 Sep 2020 08:18:05 +0700

[email-masked]​

Sawaisomnuek.com

ในวันที่ ศ. 18 ก.ย. 2020 08:08 น. Mark Nottingham <[email-masked]> เขียนว่า:

> > The IETF Trust is asking for community input on a Proposed Policy on
> Rights in IANA Parameter Registry Data as explained in
> Draft-halpern-trust-ianapolicy  (
> https://www.ietf.org/id/draft-halpern-trust-ianapolicy-00.html).
> >
> > Background:  The IANA Parameter Registry Data is not subject to
> copyright, and is intended to be freely and openly usable by adopters.
> However, no formal notice of this appears on the IANA Parameter Registry
> Data and the absence of a formal notice has caused confusion for some
> adopters which has resulted in many emails to IANA seeking guidance.
> This proposed policy by the IETF Trustees is intended to clarify the
> situation by providing a formal declaration that the material is to be
> considered in the Public Domain as detailed in the Creative Commons Zero
> (CC0) declaration.
> >
> > The IETF Trustees believe that this assertion is in keeping with the
> current and historic intention for the material, and that this declaration
> neither adds nor removes any compliance restrictions to the open and free
> use that is intended for the data in the IANA Parameter Registry.  This
> proposed policy is merely a means to clarify the intended usage rules to
> those whom have been confused by the absence of a formal declaration.
> >
> > This has been developed by the IETF Trustees with input from the IETF
> Trust’s legal counsel, and with engagement with IANA.
> >
> > Please read the draft for specifics of the proposal, the legal aspects
> behind it, and the motivation for the policy before commenting as the draft
> attempts to address what are anticipated to be common questions on the
> proposal.
> >

---

From: "R. Atkinson" <[email-masked]>
Date: Fri, 18 Sep 2020 08:57:54 -0400

> On Sep 17, 2020, at 20:20, Joel M. Halpern <[email-masked]> 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 
unambiguous.

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

Is that more clear as a statement of concern ?

Thanks,

Ran

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 18 Sep 2020 14:20:31 +0000

I fully support this.

---

From: "R. Atkinson" <[email-masked]>
Date: Fri, 18 Sep 2020 13:51:55 -0400

Joel,

Here is some candidate text which would resolve my concerns:

       “For the avoidance of doubt, 
        (a) nothing in this statement changes any IETF policy,
        (b) nothing in this statement changes any IANA policy, 
        and
        (c) the IANA official web site remains the exclusive official and
        authoritative source for information maintained in IANA registries.”

Yours,

Ran

---

From: "John Levine" <[email-masked]>
Date: 18 Sep 2020 18:28:55 -0000

In article <[email-masked]>,
>Is that more clear as a statement of concern ?

I understand the words, but I don't understand what the problem is.

As it stands now, if someone is under the mistaken impression that
they can put stuff in an IANA registry, they write to IANA and say put
this value in the foo registry, and IANA writes back and says No.

Nothing we are planning changes that in the least.

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: Brian E Carpenter <[email-masked]>
Date: Mon, 21 Sep 2020 09:22:01 +1200

Hi,

I support this in general, but have a few comments:

1) I would like to be reassured that ICANN has no problems with this. It seems quite consistent with history and current practice, but ICANN actually operates the IANA service and the public registries, so I don't think we can declare the policy without informing them.

As a reminder, the IETF/IANA MoU says:

       4.4. The IANA shall make available to the public, on-line and free of
       charge, information about each current assignment, including contact
       details for the assignee.

2) I believe that the text should note that most domain registrations are not concerned by this, but that the "technical" domain registrations are. And the same applies to the "specialised" address block assignments. We surely "own" names like .localhost., example.com, in-addr.arpa and address blocks like 64:ff9b:1::/48.

As a reminder, the IETF/IANA MoU says:

       4.3. Two particular assigned spaces present policy issues in addition
       to the technical considerations specified by the IETF: the assignment
       of domain names, and the assignment of IP address blocks. These
       policy issues are outside the scope of this MOU.

       Note that (a) assignments of domain names for technical uses (such as
       domain names for inverse DNS lookup), (b) assignments of specialised
       address blocks (such as multicast or anycast blocks), and (c)
       experimental assignments are not considered to be policy issues, and
       shall remain subject to the provisions of this Section 4...

Regards
   Brian Carpenter

---

From: "John Levine" <[email-masked]>
Date: 20 Sep 2020 17:50:22 -0400

In article <[email-masked]> you write:
>1) I would like to be reassured that ICANN has no problems with this. It seems quite consistent with history and
>current practice, but ICANN actually operates the IANA service and the public registries, so I don't think we can
>declare the policy without informing them.

Good point.  We've sent this to PTI and asked them if they have any concerns.

>2) I believe that the text should note that most domain registrations are not concerned by this, but that the
>"technical" domain registrations are. And the same applies to the "specialised" address block assignments. We
>surely "own" names like .localhost., example.com, in-addr.arpa and address blocks like 64:ff9b:1::/48.

This is about the parameters in the protocol registry. That includes
the names in Special-Use Domain Names registry but we don't treat that any
differently than any other registry.

For IP addresses the tables mix stuff we've reserved and stuff IANA
has allocated and I would not want try to pick apart who does (not)
own what there.

R's,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 21 Sep 2020 10:34:21 +1200

> differently than any other registry.

Yes, agreed, but mentioning this is in the "avoidance of doubt" category.
 
> has allocated and I would not want try to pick apart who does (not)

Indeed it is a bit mixed up, and copyright of actual numbers, whether
binary, decimal or hexdecimal is a nonsense anyway. I must confess that
I can't invent sensible wording about this.

Regards
    Brian

---

From: "Deen, Glenn" <[email-masked]>
Date: Sun, 20 Sep 2020 23:13:21 +0000

________________________________
From: tlp-interest <[email-masked]> on behalf of Brian E Carpenter <[email-masked]>
Sent: Sunday, September 20, 2020 3:34 PM
To: John Levine; [email-masked]
Subject: Re: [tlp-interest] Proposed Policy on Rights in IANA Parameter Registry Data

> Good point.  We've sent this to PTI and asked them if they have any concerns.

[GD] I’ll add to what John said, that it was IANA that first brought the situation to the Trust’s attention, and we discussed this approach them before moving forward with the consultation with the broader community.  The Trustees intention is that this gets as many eyes looking at this as reasonably possible.

> differently than any other registry.

| Yes, agreed, but mentioning this is in the "avoidance of doubt" category.

[GD] The technical domains and specialized address blocks are not affected by this as this policy declaration does not change how those things are created, managed, or recognized.     The only thing that is being done is to acknowledge that the published lists of these items are not subject to copyright and the Trust is using the CCO declaration to inform users of these lists about their status.     Keep in mind that even without the formal statement the Trust is making,  these lists are already not subject to copyright.   It’s a little subtle in that the rights to the lists are not changing here, it’s just a formal way of declaring the existing state.

[GD] My worry in trying to add material that addresses “avoidance of doubt” is that we can easily and unintentionally introduce more confusion, or misinterpretations by readers.  The current statement is simply about copyrights of the lists of parameters. It does not address or mention anything about the data in the lists such as how they are created, how they are used, who can edit them.  It’s limited to the simple declaration that the list itself is declared to be a CC0 public domain asset.

[GD] Keep in mind,  the readers of this whole declaration are primarily lawyers and in that world sticking to strict facts without any additional rhetoric is better as it does not open the door where the clarification can be misinterpreted, or worse in the event of a court case – misinterpreted by a judge or arbitrator.

[GD] Ultimately there are two common ways to write these declarations: (1) Keep it simple and minimal, sticking to just the declaration; (2) Attempt to identify the various edge cases, and interpretations and attempt to address as many a practically possible.      The keep is simple approach (1) works well for legal statements such as this, while the approach of attempting to recognize edge cases (2) and address what’s practical works well for code – but can dig you into new areas of trouble you didn’t expect in legal matters.

-glenn

---

From: "John R Levine" <[email-masked]>
Date: 20 Sep 2020 20:34:31 -0400

> [GD] My worry in trying to add material that addresses “avoidance of 
> doubt” is that we can easily and unintentionally introduce more 
> confusion, or misinterpretations by readers.  The current statement is 
> simply about copyrights of the lists of parameters. It does not address 
> or mention anything about the data in the lists such as how they are 
> created, how they are used, who can edit them.  It’s limited to the 
> simple declaration that the list itself is declared to be a CC0 public 
> domain asset.

I'm with you, particularly for registries which we do not control.  While 
I think I know what IANA and ICANN's policies are about the domain name 
and IP address registries, it would be nuts to try to explain or paraphase 
them.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 21 Sep 2020 14:18:20 +1200

> and IP address registries, it would be nuts to try to explain or paraphase 

I can't possibly disagree. I don't actually care what we say about copyright
in these items; I just want to be sure that we don't create doubt about our control
over them by omission.

   Brian

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 21 Sep 2020 11:48:30 +0100

> Please send comments [email-masked] before October 17,2020
This sounds like a good idea and is long overdue!