Subject: Re: [iucg] [Ianaplan] A draft for your review

From: JFC Morfin <[email-masked]>
Date: Sun, 02 Nov 2014 13:52:05 +0100

Suzanne,

IANAL but I know that contracts are protocols between 
people/organizations. Asking engineers to discuss contracts seems as 
sure as asking lawyers to write a technical standard RFC.

At 16:51 01/11/2014, Suzanne Woolf wrote:
>On the first-- as already pointed out, we've got existing IETF 
>authority (the MoU) and process (RFC 6761, with all the accompanying 
>machinery of writing drafts and making the case for a change in the 
>relevant registry under its rules). We've also got the machinery to 
>change that process if it's inadequate: normal IETF process for 
>updating or obsoleting an RFC, a WG whose charter includes such 
>namespace issues (DNSOP), and an IAB liaison statement sent to ICANN 
>specifically on this topic, also under IETF process and an existing 
>liaison relationship (https://datatracker.ietf.org/liaison/1351/). I 
>can speak as DNSOP co-chair that we're interested in input, because 
>applying RFC 6761 has already proven problematic and people keep 
>writing drafts that attempt it. And I can't speak for the IAB, but 
>response to the liaison statement would probably be welcome too.
>
>If people feel coordination on a specific  "technical use names" 
>issue is needed, there are mechanisms in place today to do it. If 
>people feel better coordination process is needed (such as might 
>follow from a clearer definition of "technical use names"), there 
>are mechanisms in place today to create them too, and even recent 
>suggestions (the DNSOP re-charter, the IAB liaison statement) that 
>people might want to consider invoking them.

I am afraid I do not see in which manner having mechanisms to achieve 
something makes it so that all of this will be achieved. RFC 2860 is 
clear about this: in case of a standing disagreement, RFC 2860 
Section 4.3, Note: "In the event ICANN adopts a policy that prevents 
it from complying with the provisions of this Section 4 with respect 
to the assignments described in (a) - (c) above, ICANN will notify 
the IETF, which may then exercise its ability to cancel this MOU 
under Section 2 above."

This language does not permit ICANN to be accountable concerning the 
NTIA's demand:  "Maintain the security, stability, and resiliency of 
the Internet DNS". The IETF has the ultimate capacity of decision 
and, therefore, responsibility (actually ISOC has it through the 
appeal process).

>At 17:52 01/11/2014, Andrew Sullivan wrote:
>But that didn't happen, which suggests to me that the division of 
>labour, again, is working.

IMHO, to make the past the guarantee of your future is to ensure that 
you will be fooled.

>At 18:53 01/11/2014, David Conrad wrote:
>Given the IETF has delegated administration via RFC 2860, I would 
>have thought it useful to formally include the delegatee in 
>discussions related to the resource (either domain names or IP 
>addresses) being discussed, not just have the decision be solely 
>dependent on the IESG's opinion.

David, is this truly the "status quo" :-)?

If I understand you, what ICANN wants is to control things through RFC 2960bis.

I have 255 classes that I can use and IETF has a few thousand that it 
can freely affect. Perhaps it is time to contract that the ICANN/NTIA 
"IN" Class is the undisputed ICANN one.

If there are too many or buggy TLDs in the root of that class, users 
will know about it and competition will play its role.

jfc

---

From: JFC Morfin <[email-masked]>
Date: Mon, 03 Nov 2014 15:40:39 +0100

At 14:12 02/11/2014, Andrew Sullivan wrote:
>On Sun, Nov 02, 2014 at 01:52:05PM +0100, JFC Morfin wrote:
> >
> > >But that didn't happen, which suggests to me that the division of labour,
> > >again, is working.
> >
> > IMHO, to make the past the guarantee of your future is to ensure that you
> > will be fooled.
>
>I too have read Hume on induction.  It's worth noting that, despite
>his position, he would retire to the Poker Club and play billiards and
>backgammon.

Andrew,
I suppose you are referring to David Hume? I have never cast a glance 
on a page of his, yet. But you are right, I should. I am just basing 
myself on programmer experience. A bug is something which worked and 
does not anymore because of a small change somewhere, and it is 
usually difficult to find as it is in essence unexpected.

Here, the bug seems to be from RFC 2860 Section 4.3 in the context of 
the ICANN reading "IANA" where the NTIA spells "DNS", and the double 
BUG of the USG wanting to Be Unilaterally Global and of the 
oligarchy's dream of a Business Unregulated Governance.

>But anyway, I wasn't looking for a guarantee.

I understand that. And this is what I object to. We are not 
discussing a poker game or a billiards trick shot, but rather the 
stability of the world's economy and more precisely of the protection 
of my users. This is why I am looking for a guarantee, or at least 
the strongest protection I can get.

>I think you'll note
>that my sentence makes assertions in the present tense ("is working").
>It is possible that the future will be quite different; at that point,
>it seems to me, we'd have to respond according to what changed.
>Others seem to hope that they can write down, in advance, a procedure
>for every possible case.  That is, IMO, complete folly.

I agree.

>What we need
>are mechanisms that allow actors to work effectively, which includes
>good incentives to work out differences co-operatively.

I beg to differ with you; here's the WG's thinking here on two points:

1. status quo of an auto-corrected mechanism is not acceptable if you 
remove the correction mechanism (US NTIA)
2. this is why we do not want a mechanism, but a principle. We are 
halfway through from the (Govs) regulation to the (market) 
competition principle. The last remnant of the Govs monopolies is 
supposed to go away. Under those conditions there are two possibilities:

- competition, i.e. several ICANNs and everyone can choose the one 
they think the best.
- new state regulation, i.e. ITU.

The decision is:
- either, as per US/MS oligarchy status quo, in the IETF hands (RFC 
2860 Section 4.3), the IPR owner being the IETF Trust and ultimate 
decision maker ISOC with a few weeks to six months of delays that no 
one can accept.
- either in MYCANN Plug-ins developers (States, ISPs, Business, 
Libre), users (people), sponsors (States).

>The only ways I know to provide those incentives are to provide
>another authority

Yes.

- ITU is the most obvious candidate of the Dubai majority.

- I favor a Libre's fringe to fringe internet use oriented task force.

>or to provide power of independent action.

Yes: the MYCANN Plug-ins.

>Some argue that the NTIA has been serving the former function;
>I think that interpretation is a little fanciful, but I don't have some
>transcendental access to the truth _sub specie aeternitatus_.

 From a 37 years of experience of the international network 
perspective, I partly agree that this is not as direct as "NTIA makes 
it all". In fact, I do not see where the USG is quitting the 
function. I only see a political trick, an actual transfer from an 
NTIA contract to a Congress delegation to the FCC.

I understand that Americans contributors may think NTIA and FCC are 
the same. Still the USG is in the lead, and the same statUS quo is, 
therefore, possible, i.e. the way the Chairs read the Charter.

I am afraid that this cannot work. Not anymore. After RFC 6852, 
Dubai, Snowden, the NDN consortium, SDN works, etc. the FCC cannot be 
the only NTIA's heir. The Multitude with the MYCANN Plug-ins will 
become peoples (Libre plug-ins), nations (States plug-ins) and other 
kinds of global communities (cf. RFC 6852: Google, Apple, Microsoft, 
USCC, etc.?) innovatively competing for better interconnectivity as 
per the modern paradigm for standardization; and WSIS consensus for a 
person centered information society.

>I think
>that the potential of independent action is a more powerful way to
>focus the minds of the various actors in the case of ill behaviour,
>and a meaningless detail when actors are collaborating as well as they
>have been.

Correct.

However, this is not something to happen in the future. This is 
something happening right ***now***, right in ***here***.

1. Either, through Eliot's Draft, the IETF behaves boldly, 
coordinates the collaboration it has established with ICANN and RIRs, 
and tell the world in front of the NTIA and ITU: "trust me, I am the 
boss of my technology and I prove it in standardizing a unique, IANA 
embedded, ICANN fed, multiclass, multitechnology, multilinguistic 
MYCANN Plug-in, and this is my decision as per RFC 2860 Section 4.3., period"

2.  or the focus will be on the effectiveness of independent actions 
in the MYCANN Plug-ins area and a possible upper layers internet use 
task force aggregation.

If the Chairs continue to read the Charter the way Leslie told me, 
whatever the Draft will suggest, the world will decide on its own,

I only hope that the potential of independent action is a more 
powerful way to focus the minds of the various actors in this case, 
that is, if it is ill behavior, or help aggregating a new solution.

This will be to the IESG/IAB to decide if this WG does not want or 
does not succeed in convincing the Libre, State, Business independent 
would-be actors (MYCANN Plug-ins designers, developers, 
disseminators) that the IETF is firmly in the lead.

>At 22:50 01/11/2014, Andrew Sullivan wrote:
> > proposed text. If the IETF (or IESG or IAB) gets too wrapped up in
> > itself, we will screw up.
>
>Certainly true.  But it is surely equally true that, if we allow
>technical needs that we might have to be driven by other groups'
>priorities, we'll have to stop work.

Nowadays, technical requirements are driven by global communities' 
(plural) economics for the good of humanity.  This is RFC 6852 - 
endorsed/signed by many who are on this list.

Please note that I do not disagree with that respective RFC's 
pragmatism, but I appealed it because of its lack of ultimate 
conflict resolution and accountability mechanism that we are facing 
here. Unfortunately, I did not have the time to complete the appeal 
process and submit it to the RFC 6852's convenor (ISOC) before the 
NTIA started using it and ICANN intelligently used the NTIA's 
political wake up call to put technologies in competition (however, 
in contempt to the internet governance's "governees", igniting a 
technical competition between its own proposition and the Libre and 
national capacities).

Best
jfc