Subject: [Ianaplan] Protocol parameter registries and the ARPA TLD

From: John C Klensin <[email-masked]>
Date: Tue, 11 Nov 2014 02:51:20 -0500

Hi.  I've been trying to avoid this list on the theory that
there are lots of smart people worrying at the issues and that
my limited IETF time is better spent on other things.  I have
been watching the archives periodically and listening to
WG-related sessions at IETF (as well as participating in the
IAB IANA-strategy program) to stay in touch with things.

Monday's discussion of the relationship of the ARPA TLD to this
WG's work touches on something where I had some personal
involvement at critical times, hence my making an exception and
composing this note.  Perhaps it will clear up some confusion
and/or save time.  This is a bit long; please just consider the
length averaged out over the several months in which I've
avoided comments to this list.

First, there are a few reasons to not assume that one can say
"protocol parameters" or "protocol parameter registry" and
assume that the ARPA TLD is included.  One is that it is
managed rather differently from the other registries.  For
example, with most (at least in recent history maybe all) of
the protocol parameter registries, the IESG, directly or as the
interpreter of IETF community consensus, exercises fairly
detailed control of actual parameter values, either telling
IANA to allocate them or designating and overseeing the process
by which they are approved and assigned.  In the case of the
ARPA TLD, the IAB effectively acts as a domain administrator
for an all-delegation domain, determining what delegations are
made, for what purposes, and to whom.  Some of those
delegations, including the reverse mapping zones, date back
many years and involve agreements that cannot be changed
without disrupting the Internet. Others could be more actively
managed, but the general relationships apply to all the
subdomains of the ARPA TLD.  

Second, as mentioned during the WG meeting, because of the
reverse mapping subdomains and a few others the ARPA TLD is an
operational database with expectations of real-time resolution
of names to values.  The protocol parameter registries have
been kept out of that business since long before ICANN (with
strong IETF and the IANA support and agreement): the registries
are databases of record but not expected to be accessed, e.g.,
from a protocol each time that protocol is used.

It is worth noting that the present instructions from NTIA to
ICANN about management of the ARPA TLD are the result of a
real, although now old, issue, not theorizing or
contingency planning.  In the early days of ICANN, the IETF
community and IAB asked IANA to make a change to the ARPA
domain and got back a response from a then ICANN staff member
that indicated he was taking the instruction as advisory and
would consider it and do what he thought appropriate.  For all
of the discussions about difficult changes in IANA operators or
the functions under the IANA umbrella, the only problems we
have actually encountered are ones in which the IANA operator
claimed the right (or obligation) to use its own processes to
determine whether a requested change should be made.  In
today's environment for protocol parameter registries, the MOU
and other documents eliminate that as a problem (as others have
pointed out).

There is at least one more reason.  As Olaf pointed out, the
ARPA TLD is mentioned separately from the protocol parameter
registries in the existing contract.  I believe that is nothing
more than a reflection of the above but it is still significant
if one is trying to make sure that all arrangements in the
contract are adequately covered.

It seems to me that the above simply reflects the status quo
and ongoing procedural models and need not (and should not) be
be discussed in the current document.  The document should
however, at least IMO, be both accurate and precise.  So,
instead of assuming that "protocol parameters" simply includes
the ARPA TLD, we should make statements along the lines of one
of the following fragments:

	"... the protocol parameter registries and the ARPA TLD"

	"... for the purposes of this document, the ARPA TLD can be
	treated together with the protocol parameter registries
	because the administrative arrangements are, to all intents
	and purposes, the same"

	"... the protocol parameter registries including the ARPA
	TLD" 

My instinct is to avoid the third of these because it could be
read as inconsistent with the truth but, for this document, it
might not make much difference.  Note that any of these three
is just a subtle wording adjustment; the substitution should
not be a matter for a large and substantive debate.

There is another issue with the ARPA TLD that may be of concern
to a few of the parameter registries (and perhaps even some
other registries) as well, but I don't think it is properly a
topic for the current document or this WG.  While there would
have been other answers a couple of decades ago, the current
administrative structure for the ARPA TLD rests on an NTIA
assertion of authority.  That assertion of authority has very
little to do with the oversight arrangements that are the
subject of the current discussion and this WG's
responsibilities.  Almost certainly, the topic should not be
called out in the document.  But we should, IMO, pay sufficient
attention to be sure there are no accidental effects or
consequences of the oversight transition that force us to fight
the old battles to establish authority again.  _That_ would be
disruptive to the Internet in ways that the NTIA oversight
transition almost certainly will not be.

     john

---

From: Milton L Mueller <[email-masked]>
Date: Tue, 11 Nov 2014 15:26:01 +0000

Hi, John

> -----Original Message-----
> 
> While there would have been other answers a
> couple of decades ago, the current administrative structure for the
> ARPA TLD rests on an NTIA assertion of authority.  That assertion of
> authority has very little to do with the oversight arrangements that are
> the subject of the current discussion and this WG's responsibilities.

Can you be more specific about what "assertion of authority" you are referring to here?

---

From: Peter Koch <[email-masked]>
Date: Wed, 12 Nov 2014 18:30:19 +0100

> managed rather differently from the other registries.  For

I share this view.  The proposed text (as presented on Monday)
mixes 'zone' and 'domain', but even if looking at the ARPA
zone (sic!), it is hardly a registry that contains parameters.
The online access clearly dominates and in fact sometimes
even duplicates the content of the actual registry.
If there's any doubt, look at "ipv4only.arpa" as per RFC 7050.

> subject of the current discussion and this WG's

Not exactly sure what this is aiming at, but it might be worth noting that
on 30 SEP 2014 the record for the ARPA TLD <http://www.iana.org/domains/root/db/arpa.html>
was changed to now show the IAB (rather than the IANA) as "sponsoring organization".

-Peter

---

From: John C Klensin <[email-masked]>
Date: Wed, 12 Nov 2014 14:29:03 -0500

--On Tuesday, November 11, 2014 15:26 +0000 Milton L Mueller
<[email-masked]> wrote:

>> couple of decades ago, the current administrative structure
>> for the ARPA TLD rests on an NTIA assertion of authority.
>> That assertion of authority has very little to do with the
>> oversight arrangements that are the subject of the current
>> discussion and this WG's responsibilities.
> 

Milton, 

Nothing earthshaking and, indeed, nothing we haven't discussed
before.

Prior to the mid-to-late 90s, IANA functioned as a trust-based,
collaborative, and consensual operation, and not in general as
an "authority" with a formal reporting structure or delegations
of power.  The details of many protocol parameter allocation
decisions, specific address assignments, and TLD were kept
isolated from, e.g., the IAB and IESG, partially to provide some
protection against antitrust issues and partially for some of
the same reasons why, again e.g., many cities are run on a day
to day basis by professional managers with elected politicians
providing only policy supervision.   Various pieces of the US
government (different ones at different times) may have had the
ability to intervene about details but they didn't and
discussions of whether and how they could or might would have
been considered to be, at most, of theoretical interest only.

When the decisions that were later documented in RFC 3172 were
made, NTIA clearly had the authority to tell ICANN to do things
(in this case, how to handle the administrative authority for
the ARPA TLD) because they had a contract that said so.  That
authority, ICANN itself, and the basis for the contract rested
on an assertion of authority by the US Government that was
generally accepted, although not without dissent (whether one
believes it was legitimate or not is not at issue here).  

IANA's authority still rests to a considerable degree on the
consent of the community, not on NTIA (or some other
governmental body) telling people they have to follow whatever
rules the IANA registries imply.  I trust everyone reading this
list understands that no legal authority prevents  someone from
implementing and deploying a protocol that uses an unregistered
parameter, squatting on an address range not allocated by an RIR
or its delegate, or even setting up an alternate DNS root with a
different collection of TLDs and that none of those things are
especially hard.  In none of those cases will either the
Protocol Police or some US Government body (or a UN or
interplanetary one) sweep in and perform arrests.  There may be
more or less bad consequences in terms of interoperability with
others, but those are technical effects of how the network
works, not something that depends on an externally-designed or
designated authority.

It is perhaps a slightly different topic, but I think one of our
main goals in this process should be sure that, whatever is done
with/about the NTIA oversight of the  ICANN administration of
IANA, we shouldn't accidentally do anything that upsets that
careful balance of community consensus relationships.  The worst
possible outcome from the standpoint of a successful and global
Internet would be multiple sets of registry arrangements with
different groups or regions follow different, conflicting,
registries.  That would be a horrible outcome regardless of the
particular oversight or "governance" relationships that applied
to any particular set of them.  Similarly, regardless of
oversight arrangements, it is probably vitally important that we
avoid anything that encourages a recurrence of some of the
organizational arrogance of ICANN's early days (whether by
ICANN, a possibly-restructured IANA, or something else).   That
organizational arrogance led, not only to the specific NTIA
instructions about the ARPA TLD (IMO, a good outcome, but it was
unfortunate it was necessary) and the sometimes-suspicious,
defensive, and difficult relationship between ICANN and several
ccTLDs that persists to this day.   We don't need a repetition
and might not be able to survive one.

     john

---

From: Jefsey <[email-masked]>
Date: Thu, 13 Nov 2014 19:55:59 +0100

At 20:29 12/11/2014, John C Klensin wrote:
>In none of those cases will either the Protocol Police or some US 
>Government body (or a UN or interplanetary one) sweep in and perform arrests.

John,

I suppose you understand that this internet state of the political 
art is in violation of several national laws, for example protecting 
TMs and Copyrights. The transfer of the internet from an NTIA 
oversight to the FCC jurisdiction resolves the issue in the US. This 
is what has already happened in 1977. At that time, however, 
telecommunications were, worldwide, subject to monopolies. So the 
responses of other Govs was to copy the US solution and to (1) 
transfer the packet switch services under the control of their 
national FCC equivalents and (2) articulate their own form of 
national/cultural/economical deregulation.

Today the affirmed target of the US strategy is to change the 1977 
Govs/monopolies scenario and replace Govs by "stakeholders" 
(including by chance also the Govs as GAC members) selected as being
-  either statusholders (IETF, ICANN, RIRs, ISOC, W3C, etc.) mostly 
subject to the US jurisidction
- TM holders
-  or significant stockholders of the co called "global internet 
community", in order to have the consumers of the world under direct 
commecial relation with the edge providers (among which the US edge 
providers would disseminate the FCC lobbied good word).

This US Gov's being unilaterally global (BUG) strategy is smart, 
cleverly introduced (more US law presented as a US NTIA removal), and 
could lead to a deregulated by competition BUG (business unregulated 
governance) context.

Unfortunately, in most of the countries of the world people tend to 
think that their Govs is the institution they pay for protecting them 
from such scheems (like TPP/TIPP), and many tend even to label this 
as a "multislaveholder" approach - feeling that the RFC 6852 global 
communities being something akin to Internet Reservations. This does 
not predict political stability over the Internet Governance.

This is why:
- the more such a strategy has chances to be imposed by dominance and 
money the higher the risk of confusion.
- I presume that risk and try to understand how we can adapt it 
pêacefully to the three tiers universal equilibrium (1/3 order, 1/3 
adaptation to a new order, 1/3 chaos).
- If we miss political global stability I wish I have a local 
technical stability to survive.

This calls for contractual, transparent, formal, accountable, strict 
relations among the stakeholder to preserve their unity.IMHO we face 
a "private" demonstrations/endemic cyberwars endangering the global 
critical infrastructure until the world unanimously calls for the 
ITU/UN to step in. My interest lies in an intelligent use 
architecture protecting me and my users from this I*war, like in 
I*rak. Big lies (Mass Destruction Weapons/Unique Authoritative Root) 
leading to years of instability.

The problem is that the later this happen, the stricter the decisions 
because we will have not the time and capacity to test and convince.

jfc

---

From: John C Klensin <[email-masked]>
Date: Thu, 13 Nov 2014 14:34:08 -0500

--On Thursday, November 13, 2014 19:55 +0100 Jefsey
<[email-masked]> wrote:

>> In none of those cases will either the Protocol Police or
>> some US  Government body (or a UN or interplanetary one)
>> sweep in and perform arrests.
> 
> John,
> 
> I suppose you understand that this internet state of the
> political art is in violation of several national laws, for
> example protecting TMs and Copyrights.

When it comes to "violations" of such national laws, I know/
understand no such thing.  Part of that is the result of not
being any sort of lawyer much less one who would have a
competent opinion on the subject.    I am aware that some people
have tried to make the case that the DNS itself (not merely
particular names used in labels at various levels) is in
violation of various national laws but, as far as I know and
those people's passionate beliefs aside, none of them have
actually succeeded in convincing competent courts with
appropriate jurisdiction of the validity of that argument.

> The transfer of the
> internet from an NTIA oversight to the FCC jurisdiction
> resolves the issue in the US. This is what has already
> happened in 1977.

I have no idea what you are talking about, in part because I'm
fairly confident that the NTIA had no authority over anything
Internet-ish to transfer to anyone in 1977. 

>...
> Unfortunately, in most of the countries of the world people
> tend to think that their Govs is the institution they pay for
> protecting them from such scheems (like TPP/TIPP), and many
> tend even to label this as a "multislaveholder" approach -
> feeling that the RFC 6852 global communities being something
> akin to Internet Reservations. This does not predict political
> stability over the Internet Governance.

Neither the above, nor any of the rest of your note, appears to
have anything relevant to do with the rather narrow issue of
removing the NTIA oversight of IANA.  It would be, IMO, entirely
appropriate for you to propose a different oversight mechanism
to see if it would get traction here or elsewhere.  If you
expect NTIA to accept it, that mechanism would presumably also
have to meet NTIA's criteria, which exclude, e.g.,
intergovernmental bodies.   Similar, it would be entirely
appropriate for you to propose alternate standardization and/or
"governance" mechanisms.  But not, IMO, here. 

If you dislike the current arrangements and structure or wish to
challenge the legitimacy of NTIA's current role and hence the
mechanisms by which they wish to consider changing it, I think
that is fine (whether I agree or not).   But that is a different
discussion from the one before this WG and you should probably
find a different and more appropriate place to have it.

best,
   john

---

From: JFC Morfin <[email-masked]>
Date: Fri, 14 Nov 2014 01:05:43 +0100

>find a different and more appropriate place to have it.

Dear John,

this is the IETF. What I (and activists, gurus, or politicians) may 
***think*** or be familiar with is of strickly no interest. What 
counts is the way things ***are*** and what ***users*** will think, 
demand and pay for. And what laws and contracts permit. The points I 
raised (whatever I may think about them) are things one may argue 
over the impact, but not about the reality.

The purpose of this WG is not to subjectively guess, hope, wish, 
think, etc. it is to objectively plan how to make sure that - 
whatever the users, money, industries, Govs and other stakeholders 
will do - the IETF will  still be able to best contribute to the real 
whole world's TCP/IP oriented needs, so the internet keeps working better.

I do not see that plan being discussed, analyzed, and documented.

This means that your suggestion to discuss it at a "different and 
more appropriate place" may become a necessity

However, unless we want to take the ***risk to fragment the network 
middle layers (end to end)***, such a (or several)  WG replacement or 
IETF fork need to be:

(1) triggered by this WG (it seems this is going to be a non full 
consensus the case),
(2) reviewed by an IETF Last Call,
(3) and confirmed by the IESG,
(4) the IAB,
(5) and then ISOC to make sure everyone is in argeement.

The NTIA has decided it could not delay such a risk any more, has 
decided to engage in its initially decided 2000 strategy to prevent 
it, and asked stakeholders a plan, this WG is to contribute from an 
IETF point of view (cf. Charter).

I supposed all of us wished and responsibly wish (cf. the RFC 3935 
definition) to keep this risk under realistic and reasonable control. 
Unfortunately, this is not what I observe.

I will carefully review the version 03 of the proposed draft, but I 
fear I will be obliged to oppose it as supporting/discussing only one 
strategy, based upon an incomplete assessment of the reality (we 
mutually documented it), that/what IMHO contradicts our Charter and 
is neither in the best interest of the IETF, nor of the technology, 
of the users and therefore of humanity.

This is worrying.

jfc