ietf
[Top] [All Lists]

Re: Guiding the Evolution of the IANA Protocol Parameter Registries

2014-03-12 15:08:05
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



On Mar 12, 2014, at 3:51 PM, Geoff Huston <gih(_at_)apnic(_dot_)net> wrote:

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






Principles Guiding the Evolution of the IANA Protocol Parameter Registries

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.


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.



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.

unchanged


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

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


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.


more or less the same


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


unchanged

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.

change "its direction and stewardship" to "management"


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.



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



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.


unchanged


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.


this was the second principle

[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