Subject: Re: [Internetgovtech] Guiding the Evolution of the IANA Protocol Parameter Registries

From: "Chip Sharp (chsharp)" <[email-masked]>
Date: Mon, 3 Mar 2014 17:30:55 +0000

Dear Russ,

Thank you for sharing for review.  I will not be at IETF, but have some comments below for consideration.

I've noticed that a number of people involved in various discussions on this issue don't seem to understand the connection between the IETF and the IANA.  I'm concerned that this could result in collateral damage to functions important to IETF and IETF's role.  Therefore I support efforts at educating those involved in the current Internet Governance debate regarding the IETF's role and position regarding the IANA.  

In general I believe the principles below need to be strengthened to assert IETF's role regarding managing the Protocol Parameter registry.  The principles below seem to leave open the possibility that the IANA's operation of the Protocol Parameter Registry could be modified without the involvement of the IETF (or IRTF).

Question for clarification, is the Time Zone database operated under RFC2860?  I think so, but want to check.

Other comments below. 

Consider moving item 6 up to at least item 2 

On Feb 24, 2014, at 12:28 PM, IAB Chair <[email-masked]> wrote:

> Existing IETF and IAB consensus concerning Internet registry functions
> and IANA are documented in a variety of RFCs and IAB communications
> [RFC2860,RFC6220,IAB1,IAB2].  Since registry functions and IANA are
> likely to be the subject of discussion in a number of venues outside the
> IETF over the coming months and years, the IAB is seeking community
> feedback about operating principles to use when they find themselves
> involved in those discussions.
> 
> While dealing with these issues the IAB has consistently approached the
> issues from a set of (implicit) principles.  Since the registry functions
> are subject of discussion in various fora, the IAB has tried to make
> these operating principles explicit and seeks to confirm these with the
> community.
> 
> The IAB are planning to use part of the time in the IGOVUPDATE session at
> IETF 89 (6 March 2014, 17:00-18:30 GMT) for a discussion of such operating
> principles.  But we wanted to kick-start that discussion with a few
> thoughts about principles that the IAB and IETF have articulated in
> various documents already and some that have emerged over time but may
> not have been written down.  What we are interested in is an articulation
> of what the IETF community values.  What other parties (ICANN, RIRs,
> governments, etc.) value when they think about registry functions is
> interesting, but we want to focus this discussion on the IETF and not
> those other parties.
> 
> This is a first cut of making the principles more explicit for which we
> seek your views.
> 
> Some of these might seem a bit generic, but it is difficult to predict
> the nature of future discussions in which IETF and IAB leaders might find
> themselves, so generality helps in that regard.
> 
> On behalf of the IAB,
>  Russ Housley
>  IAB Chair
> 
> = = = = = = = =
> 
> Principles Guiding the Evolution of the IANA Protocol Parameter Registries

Item 6 and Item 4 with proposed modifications should be moved to the top of this list.  The principles should start out with a clear statement of the controlling documents and process for any changes.

> 1. The IETF protocol parameters function has been and continues to be
> capably provided by the Internet community.

Here and through the rest of the principles I recommend using the term "Protocol Parameters Registries" or "Protocol Parameter Registry functions" instead of "protocol parameters function".  This maps more closely to the terminology in RFC6220 and on IANA's web site and emphasizes the role as a registry.

> 
> The strength and stability of the function and its foundation within the
> Internet community are both important given how critical protocol
> parameters are to the proper functioning of IETF protocols.
> 
> We think the structures that sustain the protocol parameters function
> needs be strong enough that they can be offered independently by the
> Internet community, without the need for backing from external parties.
> And we believe we largely are there already, although the system can be
> strengthened further, and continuous improvements are being made.

> 
> 2. The administration of the protocol parameters function by ICANN is
> working well for the Internet and the IETF.
> 
> We are pleased with the publication and maintenance of the protocol
> parameter function and the coordination of the evaluation of
> registration requests through the IANA function provided by ICANN.
> 
> 3. The IETF protocol parameters function requires openness,
> transparency, and accountability.
> 
> Existing documentation of how the function is administered and overseen
> is good [RFC2860,RFC6220], but further articulation and clarity may be
> beneficial. It is important that the whole Internet community can
> understand how the function works, and that the processes for
> registering parameters and holding those who oversee the protocol
> parameter function accountable for following those processes are
> understood by all interested parties. We are committed to making
> improvements here if necessary.
> 
> 4. Any contemplated changes to the protocol parameters function should
> use the current RFCs and model as the starting point.
> 
> The protocol parameters function is working well, and as a result
> wholesale changes to the role of the IETF vis a vis the function are not
> warranted. The IETF/IANA Memorandum of Understanding [RFC2860] is a good
> model to work from in the event that other parties do want to contemplate
> changes. Put quite simply: evolution, not revolution.

This statement should be strengthened to be more assertive and should be moved to the top.
RFC2860 is not just a "good model to work from", it is the controlling document for the IANA's Protocol Parameter Registry operation along with RFC6220.  Item 4 should state that any contemplated changes to the IANA functions should respect current RFCs and agreements with the IETF (especially RFC 2860) and any changes to the operation of the Protocol Parameter Registry should be done through the IETF as per RFC 2860 and RFC 6220.  And don't forget about the IRTF.

Below is possible replacement text:

4. Contemplated changes to the protocol parameters registry function should respect agreements between IETF, IRTF and ICANN as per RFC2860, the IETF's processes and the relevant RFCs (e.g., RTF 6220).

The IANA protocol parameters registry function is working well, and as a result
wholesale changes to the role of the IETF, IRTF [and the IANA] vis a vis the function are not
warranted. The Memorandum of Understanding between IETF, IRTF and IANA [RFC2860] defines "the technical work to be carried out by the Internet Assigned Numbers Authority on behalf of the Internet Engineering Task Force and the Internet Research Task Force." Modifications to the protocol parameters registry function should be made via the IETF process updating RFC 6220 and other relevant RFCs.  Put quite simply: evolution, not revolution.

> 
> 5. The Internet architecture requires and receives capable service by 
> Internet registries.
> 
> The stability of the Internet depends on capable provision of not just
> IETF protocol parameters, but IP numbers, domain names, and other
> registries. Furthermore, DNS and IPv4/IPv6 are IETF-defined protocols.
> Thus we expect the role of the IETF in standards development, architectural
> guidance, and allocation of certain name/number parameters to continue.
> IP multicast addresses and special-use DNS names are two examples where
> close coordination is needed.  The IETF will continue to coordinate with
> ICANN, the RIRs, and other parties that are mutually invested in the
> continued smooth operation of the Internet registries. We fully
> understand the need to work together.

I don't disagree with this statement, but it mixes the DNS and IP address functions with the Protocol Parameter Registry functions and could be confusing.

> 
> 6.  The IETF will continue its direction and stewardship of the protocol
> parameters function as an integral component of the IETF standards
> process and the use of resulting protocols.
> 
> RFC 6220 specifies the role and function of the protocol parameters
> registry, which is critical to IETF standards processes and IETF
> protocols.  We see no need to revisit or reconsider our current approach
> with regard to protocol parameters, including the ability to delegate
> operational responsibility for registries to other organizations.

As mentioned previously, I recommend moving this up to the top.

> 
> [RFC2860] http://www.rfc-editor.org/rfc/rfc2860.txt
> [RFC6220]  http://www.rfc-editor.org/rfc/rfc6220.txt
> [IAB1] http://www.iab.org/wp-content/IAB-uploads/2011/03/2009-06-08-IAB-NTIA-NOI-final.pdf
> [IAB2] http://www.iab.org/wp-content/IAB-uploads/2011/07/IANA-IAB-FNOI-2011.pdf

Thanks,
Chip

** I am employed by Cisco Systems, Inc, but these comments reflect my own opinion and not any position of Cisco. **

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 04 Mar 2014 07:09:03 +1300

I agree with Chip's comments, and in particular:

On 04/03/2014 06:30, Chip Sharp (chsharp) wrote:
...

>> 4. Any contemplated changes to the protocol parameters
>> function should use the current RFCs and model as the
>> starting point.
>> 
>> The protocol parameters function is working well, and as a
>> result wholesale changes to the role of the IETF vis a vis
>> the function are not warranted. The IETF/IANA Memorandum of
>> Understanding [RFC2860] is a good model to work from in the
>> event that other parties do want to contemplate changes.
>> Put quite simply: evolution, not revolution.
> 
> This statement should be strengthened to be more assertive
> and should be moved to the top. RFC2860 is not just a "good
> model to work from", it is the controlling document for the
> IANA's Protocol Parameter Registry operation along with
> RFC6220.  

Agreed; it's a binding document today and should remain so.
In fact, no changes to the IETF's IANA function that we
delegated to ICANN can be made without IETF consent; that is
an intended side-effect of the existing MoU.

If other SDOs wanted to contract with ICANN-IANA for services
it would be a model for *them* to work from, but as far as the
IETF is concerned it's a done deal. Maybe that was the intended
meaning, but that isn't clear from the text.

   Brian

---

From: JFC Morfin <[email-masked]>
Date: Wed, 05 Mar 2014 19:39:51 +0100

Dear Russ,

I thank you for this confirmation of the IAB/IETF determination irt. 
the Internet end to end parameters after the ambiguous publication of 
the OpenStand RFC 6852 which does not define a common referent after 
the inclusion of ISOC, IEEE and W3C as a common readers of the 
economic requirements of the global communities.

As personnally trying to clarify the terms of the multistakeholder 
governance of global information both for IUsers and multitechnology 
VGN individual, private and public operators I understand that there 
is a consensus of my interlocutors to trust, rely on, respect, and 
enforce the IETF structural parameters, and the IETF repartition of 
operational parameters.

The intent is to channel the technical concerns via the IUCG and 
cooperate through the VGNICS experimental enhanced cooperation 
proposition under formalization (http://vgnics.net) and its MDRS 
(http://vgnics.net/mdrs) for the collection, validation and diffusion 
of fringe to fringe information made avaliable to VGNIC managers and 
DNS services operators. The intent is also to keep IAB  informed of 
the efforts of documentation consolidation and/or translation.

We certainly understand the importance - up to now illustrated by the 
US and a few other Governements - to be able to organize the Internet 
operations both in global continuity and in taking into account 
national needs, in particular in case of catastrophe or critical 
situations. The strategy wich seems to be demanded is a neutrality of 
information on a neutral end to end global network, of which the 
higher layers will be kept transparent to any fringe to fringe technology.

Best regards.
jfc

At 18:28 24/02/2014, IAB Chair wrote:
>[IAB1] 
>http://www.iab.org/wp-content/IAB-uploads/2011/03/2009-06-08-IAB-NTIA-NOI-final.pdf
>[IAB2] 
>http://www.iab.org/wp-content/IAB-uploads/2011/07/IANA-IAB-FNOI-2011.pdf
>
>_______________________________________________
>Internetgovtech mailing list
>[email-masked]
>https://www.iab.org/mailman/listinfo/internetgovtech

---

From: Russ Housley <[email-masked]>
Date: Fri, 7 Mar 2014 07:58:21 -0500

> Question for clarification, is the Time Zone database operated under RFC2860?  I think so, but want to check.

The Time Zone database does fall under RFC 2860, but it have a special set of policies that govern updates.  Much is delegated; however, the IESG is the body that would handle an appeal if someone felt that the processes were not being followed.

Russ

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 07 Mar 2014 14:51:34 +0000

> The Time Zone database does fall under RFC 2860, but it have a special set of policies that govern updates.  Much is delegated; however, the IESG is the body that would handle an appeal if someone…

There are, I think, a few other parameters that are sort of "corner
cases", like "IDN Practices Repository" that IANA list under "Domain
Names" <http://www.iana.org/domains/idn-tables> but if I understand
correctly is operated on direct request from ICANN (I might be
completely wrong here on how that registry was set up).

   Patrik

---

From: "Chip Sharp (chsharp)" <[email-masked]>
Date: Fri, 7 Mar 2014 15:13:27 +0000

Patrik, Russ,

Thanks for your clarifications.  I'm sure there are things like the IDN stuff that I'm not aware of.

Another thing I don't hear mentioned in this discussion is IRTF.
I believe RFC2860 and supplements cover the IRTF as well.

BTW, is it possible to publish the supplement to RFC2860 as an RFC?
That would make it a lot cleaner and easier to reference.

Chip

---

From: S Moonesamy <[email-masked]>
Date: Fri, 07 Mar 2014 23:50:29 -0800

Hi Patrik,
>completely wrong here on how that registry was set up).

It is not part of the IETF Protocol Parameter Registry.

There is the "Special People Numbers Registry" ( 
http://www.iana.org/assignments/special-registry 
).  It is mentioned that it is not operated by the IETF.

Regards,
S. Moonesamy

---

From: Eric Brunner-Williams <[email-masked]>
Date: Sat, 08 Mar 2014 08:06:08 -0800

Had a recommendation of the of the IAB Character Set Workshop of April, 
1997, "to create a research group to explore the open issues of 
character sets on the Internet " resulted in work product, or had the 
request of the authors of the tsconf draft been adopted (for 
intermediate tables) achieved "hum" in the affirmative sense resulting 
in work product, or similar, then there could be one or more entries in 
the IETF Protocol Parameter Registry corresponding to character sets.

As others have noted, the IDN (in applications) Practices Repository 
arises from third-party acts.

Eric

On 3/7/14 11:50 PM, S Moonesamy wrote:
> http://www.iana.org/assignments/special-registry ).  It is mentioned 
> that it is not operated by the IETF.
>
> Regards,
> S. Moonesamy
>
>

---

From: IAB Chair <[email-masked]>
Date: Tue, 11 Mar 2014 17:47:06 -0400

Existing IETF and IAB consensus concerning protocol parameter registry
functions and IANA are documented in a variety of RFCs and IAB
communications [RFC2860,RFC6220,IAB1,IAB2].  Since these functions and
IANA are likely to be the subject of discussion in a number of venues
outside the IETF over the coming months and years, the IAB sought
community feedback about operating principles to use in these
discussions.  This note incorporates the comments from the mail list
discussion and the IGOVUPDATE session at IETF 89.

The IAB recognizes significant community support for these principles.

Some of these principles might seem a bit generic, but it is difficult to
predict the nature of future discussions in which IETF and IAB leaders
might find themselves, so generality helps in that regard.

On behalf of the IAB,
  Russ Housley
  IAB Chair

= = = = = = = =

These principles must be taken together.  Ordering is not significant.

1.  The IETF protocol parameter registry function has been and continues
to be capably provided by the Internet technical community.

The strength and stability of the function and its foundation within the
Internet technical community are both important given how critical
protocol parameters are to the proper functioning of IETF protocols.

We think the structures that sustain the protocol parameter registry
function needs be strong enough that they can be offered independently by
the Internet technical community, without the need for backing from
external parties.  And we believe we largely are there already, although
the system can be strengthened further, and continuous improvements are
being made.

2. The protocol parameter registry function requires openness,
transparency, and accountability.

Existing documentation of how the function is administered and overseen
is good [RFC2860,RFC6220].  Further articulation and clarity may be
beneficial.  It is important that the whole Internet community can
understand how the function works, and that the processes for registering
parameters and holding those who oversee the protocol parameter function
accountable for following those processes are understood by all
interested parties.  We are committed to making improvements here if
necessary.

3. Any contemplated changes to the protocol parameter registry function
should respect existing Internet community agreements.

The protocol parameter registry is working well.  The existing Memorandum
of Understanding [RFC2860] defines "the technical work to be carried out
by the Internet Assigned Numbers Authority on behalf of the Internet
Engineering Task Force and the Internet Research Task Force."  Any
modifications to the protocol parameter registry function should be made
using the IETF process to update RFC 6220 and other relevant RFCs.  Put
quite simply: evolution, not revolution.

4. The Internet architecture requires and receives capable service by 
Internet registries.

5. The IETF will continue management of the protocol parameter registry
function as an integral component of the IETF standards process and the
use of resulting protocols.

RFC 6220 specifies the role and function of the protocol parameters
registry, which is critical to IETF standards processes and IETF
protocols.  The IAB, on behalf of the IETF, has the responsibility to
define and manage the relationship with the protocol registry operator
role.  This responsibility includes the selection and management of the
protocol parameter registry operator, as well as management of the
parameter registration process and the guidelines for parameter
allocation.

6. The protocol parameters registries are provided as a public service.

Directions for the creation of protocol parameter registries and the
policies for subsequent additions and updates are specified in RFCs.
The protocol parameters registries are available to everyone, and they
are published in a form that allows their contents to be included in
other works without further permission.  These works include, but are
not limited to, implementations of Internet protocols and their
associated documentation.

An important observation: The administration of the protocol parameter
registry functions by ICANN is working well for the Internet and the
IETF.  We are pleased with the publication and maintenance of the
protocol parameter registries and the coordination of the evaluation of
registration requests through the IANA function provided by ICANN.

---

From: Geoff Huston <[email-masked]>
Date: Thu, 13 Mar 2014 06:51:31 +1100

Hi,

In reading this was was interested to understand what changed from the presentation at the ietf (http://www.ietf.org/proceedings/89/slides/slides-89-igovupdate-0.pdf) and what stayed (more or less) the same? So what follows below is my take on the edits following the IETF session in order to understand how the feedback from the meeting was incorporated into this announcement.

Principle 6 is almost there, but I still find myself voicing a note of dissent - in so far as it avoids mentioning copyright or any similar term relating to intellectual property but instead states their availability and the ability to include registry contents into other works without permission.

My concern rests in observations related to previous handovers of this function in past times. Relating this to today, in my understanding were the IAB to exercise its ability under RFC6220 and re-designate a protocol parameter registry operator it is logically necessary for the previous registry operator to cooperate and synchronise the movement of registry to the new operator. It's hard to set this out this obligation as a principle, but any observer of the first few months of operation of Network Solutions taking over the registry role from the  previous operator back then in the early 90's would've been painfully aware of a certain hiatus in service. 

Now all this could be finessed (in my view) by a stronger statement in principle 6 about the intellectual property of the contents of the protocol parameter registries, and the principle that while the registry operator is given license to modify these registries in line with the directions from the IETF, the contents of these (modified) registries remains the intellectual property of the IETF and not the property of the registry operator. 

But I have the sense that assertions of copyright and intellectual property appear to be concepts that are too "strong" for this enumeration of principles. Why is this?

Kind regards,

  Geoff

> the system can be strengthened further, and continuous improvements are

unchanged

removed:
The administration of the protocol parameters function by ICANN is working well for the Internet and the IETF.

We are pleased with the publication and maintenance of the protocol parameter function and the coordination of the evaluation of registration requests through the IANA function provided by ICANN.

> interested parties.  We are committed to making improvements here if

unchanged

> should respect existing Internet community agreements.

(was: ... should use the current RFCs and model as the starting point.)

> quite simply: evolution, not revolution.

more or less the same

> understand the need to work together.

unchanged

> use of resulting protocols.

change "its direction and stewardship" to "management"

> parameter registration process and the guidelines for parameter

this is altered wording

(used to read: "RFC 6220 specifies the role and function of the protocol
parameters registry, which is critical to IETF standards processes
and IETF protocols. We see no need to revisit or reconsider our
current approach with regard to protocol parameters, including the
ability to delegate operational responsibility for registries to other
organizations."_

> associated documentation.

unchanged

> registration requests through the IANA function provided by ICANN.

this was the second principle

---

From: Steve Crocker <[email-masked]>
Date: Wed, 12 Mar 2014 16:07:31 -0400

Geoff, et al,

I made a statement in the igovupdate session and I’ll reiterate here in the spirit of using the list as the definitive record and not the face to face session.

ICANN has NO intellectual property interests in the material it publishes.  My understanding of copyright law is that copyright attaches to the creator of content, irrespective of whether they register that copyright.  (There is utility in registering copyrights  I am not enough of expert to expound on those details, nor do I think they’re relevant to this discussion.)

During the discussion in the igovupdate session I heard brief mention of possible issues regarding various RFCs and registries over the years.  These pertained to various government agencies and others, but did not involve ICANN.

If the community desires a formal document saying what I’ve said above, I will personally shepherd it through our system.

Let me address two other points, one that is mentioned below and one that is entirely separate.

I believe the scenario of moving the protocol parameter registries to another operator has already been explored.  I am given to understand that the IETF has conducted exercises that mirror these registries.  I am not familiar with the details.  The IAOC is probably the best group to say more about this.  In any case, I don’t think would be problematic and as a matter of good business practice we will cooperate with any reasonable exercise or demonstration to provide that assurance.

Something that occurred to me during the discussion which I have not seen mentioned before is the following.  All of us follow the principle that the information created by the IETF is available to anyone, anywhere, without cost.  What would happen if the IETF changes its position and requires IANA to either restrict its distribution of information and/or charge for it?  I think we’d have to think carefully about that.  Would the IETF be willing to assert as part of its principles that it won’t do such a thing?

Thanks,

Steve Crocker
Chair, ICANN Board of Directors

---

From: Geoff Huston <[email-masked]>
Date: Thu, 13 Mar 2014 07:50:28 +1100

Hi Steve,

Firstly I should reiterate that this is not about ICANN. I agree wholeheartedly with the "important observation" in Russ's posting, and I am very heartened to read your undertaking relating to ICANN having no intellectual property interests in the material it publishes in this role as protocol parameter registry operator. For me, it was very welcome as a statement at the meeting, and equally welcome as a statement here, and, while I can only speak personally, I would like to sincerely extend my thanks for making this undertaking.

My posting was not about the specific, but about the principle. I believe it to be incumbent on the IETF to clearly state the principle, namely that the operator of a protocol parameter registry is doing so at the specific behest of the IETF, and as an agent of the IETF. All intellectual property rights in the content of the registries remains that of the IETF, and does not vest with the registry operator. This is desire that I believe is entirely consistent with your undertaking that ICANN as a protocol parameter registry operator makes no such claim, however I suppose I am wanting this to be a principle that applies generally.

As to folk changing their mind in the future, its true that the future is a constant source of surprise to us, and statements that include terms such as "never" or "forever" are constantly being mocked by the unfolding of time. But I don't think we need to cross every bridge here - we can at best set forth our values and principles on the day and hope that our successors at least consider what we were trying to achieve and why we thought it to be important as they make their changes to suit their world. These principles appear to be an earnest effort in that direction.

kind regards,

   Geoff

---

From: Steve Crocker <[email-masked]>
Date: Wed, 12 Mar 2014 16:56:08 -0400

Geoff,

Thanks.  No argument.  It was interesting to me as I was speaking during the session and asserting that we have no claim to the intellectual property that we (ICANN) might find ourselves having quite strong feelings if we were told we had to implement restrictive policies.  It’s not a scenario that, to my knowledge, has ever come up before, but I think it fits into your general framework of espousing principles.

Steve

---

From: Eliot Lear <[email-masked]>
Date: Wed, 12 Mar 2014 22:13:51 +0100

Geoff,

Thanks for your comments.  so that we understand what we are talking
about, here is the principle in question:

> The protocol parameters registries are provided as a public service.
>

Your specific complaint is that we mention neither copyright or
trademark.  To me those two legal points are implementation of the above
principle.  We should do what is necessary to see that the parameters
are published so that all are free to use them.  Whether that implies
copyrights, trademarks, contracts, or what have you is for the lawyers
to sort.  What I like is that Steve is carrying forward in his words and
actions this idea that anyone can access this stuff, a point that he
worked with others to establish in the RFC series.  That's leadership!

Eliot

---

From: Jari Arkko <[email-masked]>
Date: Wed, 12 Mar 2014 23:44:30 +0200

> principle. 

This is how I read it as well.

Jari

---

From: <[email-masked]>
Date: Wed, 12 Mar 2014 21:59:47 +0000

> All intellectual property rights in the content of the registries remains that of the IETF,

Since IETF is an ISOC activity, and ISOC is the organisation that will be involved in intellectual property disputes (see RFC2031) isn't that really ISOC ownership?

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: ietf [[email-masked]] On Behalf Of Geoff Huston [[email-masked]]
Sent: 12 March 2014 20:50
To: Steve Crocker
Cc: [email-masked]; [email-masked] Mailing List
Subject: Re: Guiding the Evolution of the IANA Protocol Parameter Registries

Hi Steve,

kind regards,

   Geoff

---

From: Pindar Wong <[email-masked]>
Date: Thu, 13 Mar 2014 07:16:29 +0800

see

http://trustee.ietf.org/docs/IETF-Copyright-FAQ.pdf

p.

On Thu, Mar 13, 2014 at 5:59 AM, <[email-masked]> wrote:

> Since IETF is an ISOC activity, and ISOC is the organisation that will be
> involved in intellectual property disputes (see RFC2031) isn't that really
> ISOC ownership?
>
> Lloyd Wood
> Firstly I should reiterate that this is not about ICANN. I agree
> wholeheartedly with the "important observation" in Russ's posting, and I am
> very heartened to read your undertaking relating to ICANN having no
> intellectual property interests in the material it publishes in this role
> as protocol parameter registry operator. For me, it was very welcome as a
> statement at the meeting, and equally welcome as a statement here, and,
> while I can only speak personally, I would like to sincerely extend my
> thanks for making this undertaking.
>
> My posting was not about the specific, but about the principle. I believe
> it to be incumbent on the IETF to clearly state the principle, namely that
> the operator of a protocol parameter registry is doing so at the specific
> behest of the IETF, and as an agent of the IETF. All intellectual property
> rights in the content of the registries remains that of the IETF, and does
> not vest with the registry operator. This is desire that I believe is
> entirely consistent with your undertaking that ICANN as a protocol
> parameter registry operator makes no such claim, however I suppose I am
> wanting this to be a principle that applies generally.
>
> As to folk changing their mind in the future, its true that the future is
> a constant source of surprise to us, and statements that include terms such
> as "never" or "forever" are constantly being mocked by the unfolding of
> time. But I don't think we need to cross every bridge here - we can at best
> set forth our values and principles on the day and hope that our successors
> at least consider what we were trying to achieve and why we thought it to
> be important as they make their changes to suit their world. These
> principles appear to be an earnest effort in that direction.
>
> kind regards,
>
>    Geoff
>
>
> > I made a statement in the igovupdate session and I'll reiterate here in
> the spirit of using the list as the definitive record and not the face to
> face session.
> >
> > ICANN has NO intellectual property interests in the material it
> publishes.  My understanding of copyright law is that copyright attaches to
> the creator of content, irrespective of whether they register that
> copyright.  (There is utility in registering copyrights  I am not enough of
> expert to expound on those details, nor do I think they're relevant to this
> discussion.)
> >
> > During the discussion in the igovupdate session I heard brief mention of
> possible issues regarding various RFCs and registries over the years.
>  These pertained to various government agencies and others, but did not
> involve ICANN.
> >
> > If the community desires a formal document saying what I've said above,
> I will personally shepherd it through our system.
> >
> > I believe the scenario of moving the protocol parameter registries to
> another operator has already been explored.  I am given to understand that
> the IETF has conducted exercises that mirror these registries.  I am not
> familiar with the details.  The IAOC is probably the best group to say more
> about this.  In any case, I don't think would be problematic and as a
> matter of good business practice we will cooperate with any reasonable
> exercise or demonstration to provide that assurance.
> >
> > Something that occurred to me during the discussion which I have not
> seen mentioned before is the following.  All of us follow the principle
> that the information created by the IETF is available to anyone, anywhere,
> without cost.  What would happen if the IETF changes its position and
> requires IANA to either restrict its distribution of information and/or
> charge for it?  I think we'd have to think carefully about that.  Would the
> IETF be willing to assert as part of its principles that it won't do such a
> thing?
> >
> > Thanks,
> >
> > Steve Crocker

---

From: Geoff Huston <[email-masked]>
Date: Thu, 13 Mar 2014 16:23:56 +1100

Weaving the web of wording around various RFCs and the distinctions between the IASA, the IAOC and the IETF, I have absolutely no idea whether a) the IETF itself is an ISOC activity per se and b) issues about the intellectual property rights associated with the protocol parameter registry contents vest with any of the preceding bodies. But I thought we were talking principles, and the principle I was espousing was that all intellectual property rights in the content of the protocol parameters registries remains with the IETF, and does not vest with the registry operator. I guess I'm treading on the toes of an historic US position that in the past appeared to be that the intellectual property rights of the IANA protocol parameter registries that were operated under the terms of contracts with variously ARPA, DARPA and the NSF vested with the USG in some fashion, and its a question that we appear to want to avoid as there has never been any statements from the NTIA that expressly disclaim this, and noone appears to want to press the point.

I personally am in favour of a stronger statement of principle from the IETF in this area, but I'm just one voice, and I sense from the posts for Jari and Eliot that they are unwilling to head further in this direction - fair enough.

regards,

  Geoff

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 13 Mar 2014 06:40:48 +0100

> I personally am in favour of a stronger statement of principle from the IETF in this area, but I'm just one voice, and I sense from the posts for Jari and Eliot that they are unwilling to head furt…

FWIW, I support Geoff here, given the history we have seen not only in
direct IETF history but also in other Internet related registries (for
example various TLD-registries).

That said, I at the same time agree with Jari and Eliot that the over
all goal is in the principles. That finding a solution "is implementation".

So, I just would like to have a stronger statement so this is not forgotten.

The copyright for a parameter and its assigments should stay with
whatever organization "owns" that parameter. Not belong to whoever acts
as the care taker of the registry.

That ICANN also say they do not have any interest as the operator in IPR
for the registry is good, but if the registry operator changes, IPR
issues I absolutely would like to see in the agreement(s).

I am because of that of course sort of happy with what Jari and Eliot
stated. This can be found in the principles.

Just do not forget about it...

   Patrik

---

From: Pindar Wong <[email-masked]>
Date: Thu, 13 Mar 2014 13:47:35 +0800

fwiw also be mindful of

http://en.wikipedia.org/wiki/Sui_generis_database_right

p.

On Thu, Mar 13, 2014 at 1:40 PM, Patrik Fältström <[email-masked]> wrote:

> > I personally am in favour of a stronger statement of principle from the
> IETF in this area, but I'm just one voice, and I sense from the posts for
> Jari and Eliot that they are unwilling to head further in this direction -
> fair enough.
>

---

From: Eliot Lear <[email-masked]>
Date: Thu, 13 Mar 2014 07:34:42 +0100

Pindar,

> http://en.wikipedia.org/wiki/Sui_generis_database_right

Indeed.  But I do think there is probably an additional word or two we
can say about seeing that any intellectual property that exists in the
parameters stays with the IETF, for the purpose of making it available
to all.

Eliot

---

From: Pindar Wong <[email-masked]>
Date: Thu, 13 Mar 2014 14:49:07 +0800

On Thu, Mar 13, 2014 at 2:34 PM, Eliot Lear <[email-masked]> wrote:

> Indeed.  But I do think there is probably an additional word or two we can
> say about seeing that any intellectual property that exists in the
> parameters stays with the IETF, for the purpose of making it available to
> all.
>

Agreed. I merely raise this to support both Geoff and Patrik's point that
perhaps extra clarity at the level of principle might be especially helpful
in this  inherently muddy area that comprises the territorially demarcated
Intellectual Property  space.

In turns out that after some 7 years of operational experience with the
then Creative Commons licence suite --  that 'Sui generis database rights'
were particularly unhelpful (when you're actually trying to legally licence
your rights away) and one of the principle drivers behind the development
of the Creative Commons (4.0) Licence suite.  The gory details fwiw are
here:-

http://wiki.creativecommons.org/4.0/Sui_generis_database_rights

p.

---

From: S Moonesamy <[email-masked]>
Date: Thu, 13 Mar 2014 00:46:05 -0700

Hi Geoff,
At 22:23 12-03-2014, Geoff Huston wrote:
>Weaving the web of wording around various RFCs and the distinctions 
>between the IASA, the IAOC and the IETF, I have absolutely no idea 
>whether a) the IETF itself is an ISOC activity per se and b) issues 
>about the intellectual property rights associated with the protocol 
>parameter registry contents vest with any of the preceding bodies. 
>But I thought we were talking principles, and the principle I was 
>espousing was that all intellectual property rights in the content 
>of the protocol parameters registries remains with the IETF, and 
>does not vest with the registry operator. I guess I'm treading on 
>the toes of an historic US position that in the past appeared to be 
>that the intellectual property rights of the IANA protocol parameter 
>registries that were operated under the terms of contracts with 
>variously ARPA, DARPA and the NSF vested with the USG in some 
>fashion, and its a question that we appear to want to avoid as there 
>has never been any statements from the NTIA that expressly disclaim 
>this, and noone appears to want to press the point.

I'll comment about (b).  There is a RFC published in 2011 which 
states that the intellectual property rights of IETF protocol 
parameter assignment information is held by the IETF Trust.  There 
isn't any (formal) agreement about the intellectual property 
rights.  There is, as mentioned above, the legacy stuff.  The bottom 
line is that the legal aspect is unclear.

Regards,
S. Moonesamy

---

From: <[email-masked]>
Date: Thu, 13 Mar 2014 08:12:39 +0000

Ah, RFC 6620 and RFC 4748. 

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: S Moonesamy [[email-masked]]
Sent: 13 March 2014 07:46
To: Geoff Huston; Wood L  Dr (Electronic Eng)
Cc: [email-masked]
Subject: Re: Guiding the Evolution of the IANA Protocol Parameter  Registries

Hi Geoff,

Regards,
S. Moonesamy

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Mar 2014 22:01:23 +1300

> parameters stays with the IETF, for the purpose of making it available

For everything assigned since the IETF/IANA MoU was ratified in
March 2000, we could certainly make that assertion, and presumably
vest the IPR in the IETF Trust. For assignments prior to March
2000, I think things are less clear. IANAL.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Mar 2014 23:38:45 +1300

Not 6620, so which one do you mean?

Regards
   Brian

---

From: Jefsey <[email-masked]>
Date: Thu, 13 Mar 2014 01:54:59 +0100

At 21:50 12/03/2014, Geoff Huston wrote:
>But I don't think we need to cross every bridge here - we can at 
>best set forth our values and principles on the day and hope that 
>our successors at least consider what we were trying to achieve and 
>why we thought it to be important as they make their changes to suit 
>their world. These principles appear to be an earnest effort in that direction.

Geoff,
as such I am afraid they do not belong to the internet. RFC 1958 
defines the principles of the Internet architecture. The first of 
these principles is the principle of constant change: "The principle 
of constant change is perhaps the only principle of the Internet that 
should survive indefinitely".

It seems that this principle invalidates your entire claim as what 
you want to protect (IETF protocols) is based on the idea that they 
are published to be continously adapted. This puts them outside of 
any copyright (as something being used, supported, parametered, etc.) 
but fully subject to initial author rights?
jfc

---

From: S Moonesamy <[email-masked]>
Date: Thu, 13 Mar 2014 08:00:55 -0700

Hi Llyod,
>Ah, RFC 6620 and RFC 4748.

Yes.  There might be a typo for RFC 6220.

Regards,
S. Moonesamy

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Mar 2014 06:55:16 +1300

> Yes.  There might be a typo for RFC 6220.

Thanks. Which indeed states that rights belong to the IETF Trust.
But that is only a statement in an Informational RFC. Good luck
in court.

   Brian

---

From: S Moonesamy <[email-masked]>
Date: Thu, 13 Mar 2014 12:32:11 -0700

Hi Brian,
>But that is only a statement in an Informational RFC. Good luck

In a previous message I mentioned that there isn't any (formal) 
agreement about the intellectual property rights.  I spent a few 
minutes thinking about the matter.  It is like opening Pandora's box [1].

Regards,
S. Moonesamy

1. a source of many troubles

---

From: Michael StJohns <[email-masked]>
Date: Fri, 14 Mar 2014 16:49:08 -0400

At 01:23 AM 3/13/2014, Geoff Huston wrote:
>. But I thought we were talking principles, and the principle I was espousing was that all intellectual property rights in the content of the protocol parameters registries remains with the IETF, and does not vest with the registry operator. I guess I'm treading on the toes of an historic US position that in the past appeared to be that the intellectual property rights of the IANA protocol parameter registries that were operated under the terms of contracts with variously ARPA, DARPA and the NSF vested with the USG in some fashion, and its a question that we appear to want to avoid as there has never been any statements from the NTIA that expressly disclaim this, and noone appears to want to press the point.

There's this legal concept of a "quitclaim" that might be useful here.  It can be used by anyone, especially in cases where there may be an appearance of (legal) interest, but where the actual facts aren't firmly established.

Webster has it as:

>
>quit·claim
>
>
>
>transitive verb \ kwit- kl m\
>:  to release or relinquish a legal claim to; especially :  to release a claim to or convey by a quitclaim deed 
> quitclaim noun 

Maybe the right answer is to simply ask for quitclaims from the US Gov't, and from ICANN, (and others?) with respect to any and all IPR, copyright claims, etc they may hold, if any,  in the protocol parameters registry to be resolved or transferred to or for the benefit of the IETF trust.  At least then we'd know rather than continuing to dance around it.  The quid pro quo might be a quitclaim from us for similar interests in the DNS and IP registries.

Mike