[Ianaplan] response to your questions

[Jefsey <[e-mail]>]

Hi! Andrew,
I apologize for the late response. I wanted it to be comprehensive 
and had a few things to address before.

>At 00:13 10/07/2015, Andrew Sullivan wrote:
>Hi,
>Just two things.
>
>On Thu, Jul 09, 2015 at 11:31:50PM +0200, Jefsey wrote:
> > The IESG/IAB appeal process is now finished. It concludes that the RFC 2026
> > process has been rigorously respected.
>[]
> > - along RFC 2026, in trying to ask for them from the ISOC Chair.
>
>I cannot tell whether in the first pair of sentences, the "It
>concludes" means that the appeals conclude that, but that you don't
>agree;

Correct. See below.


>or whether you mean that the appeal process having gone the way
>it did, that conclusion shows that the RFC 2026 process has been
>rigorously respected.

The IAB thinks the RFC 2026 process has been respected.

I think it did not work: otherwise, the IAB conclusions would have 
addressed my questions, either in responding to them or in denying 
their pertinence.

The reason why is that you and me do not consider the RFC 2026 
process at the same level.

1.      IAB looks at the respect of the letter of the RFC 2026 
process, I think the RFC 2026 itself is "inadequate or insufficent to 
the protection of the rights of all parties in a fair and open 
Internet Standards Process."

2.      I have not made up my mind as to why. Is this due to the 
particular case at hand or is it for new reasons resulting from the 
new situation in which the IETF now is?


>If the latter, then you can't ask anything from
>ISOC, because appeal to the ISOC BoT (not the Chair, note) of an IAB
>decision is only permitted on procedural grounds.  This is the
>distinction between sections 6.5.1 and 6.5.2, and section 6.5.3, of
>RFC 2026.  I imagine you know that, but I just wanted to remind
>everyone.

It seems that we may not have the same reading of the RFC 2026 
sentence that I refer to.  Anyway, the point is important because 
this is a case of conflict between the RFC 6852 principles, the RFC 
3935 documented IETF mission and the position irt. NTIA and ICANN 
accepted by the Draft and now consistently documented by the IETF 
Chair and by IAB. We are in the case why I objected  RFC 6852, the 
case it has not addressed. How to resolve/clarify an intercommunity 
technical/political inconsistency.

Roughly, there is no longer any moral/political/"formal" (the word is 
from RFC 6852) authority claim over the use of the catenet by the 
different technologies designed by the different global communities 
(that want to use it along the requirements of their markets). We are 
in the multistakeholder configuration: the evaluation of my RFC 6852 
global community differs from your RFC 6852 global community evaluation.

This seems to be for three reasons:

1. the IAB has relinquished its authority over ICANN (through the 
IANA) giving up a historical claim of leadership over the TCP/IP architecture.

2. In addition, the IETF/IAB has limited itself this authority over 
its technology in accepting to become the ICANN RFC 6852 Global 
Community architectural/technological pole of expertise – other RFC 
6852 Global Communities can compete/coopete/concert with.

3. However, the IETF has helped me identify the wide and widely 
informal LIBRE RFC 6852 global community through the 
<mailto:[e-mail]>[e-mail] mailing list. I have not invested 
enough in the formalization of such a "WI-LIBRE" global community so 
it might adequately contribute. This is something I should do both 
politically (hence an appeal at the peer level with ISOC) and 
technically (hence the analysis, R&D and testing of a catenet partner 
architecture - that might adequately support and contribute to the 
different networking architectures a member of the digital ecosystem 
may have to master).

Since (again this was the reason for my appeal last year) RFC 6852 
has not foreseen any technical conflict resolution/clarification 
mechanism between those adhering to its principles, we are left in a 
limbo situation. My appeal to ISOC should help to understand if (and 
what) the Internet Community and the State Department have foreseen 
should the case arise.

If ISOC were to decline to answer my appeal, it would only mean that 
the US has chosen not to politically interfere anymore in my 
business. This is big news to me after they fired me 30 years ago!


> > includes the "FL" (Free/LIBRE) DNS CLASS testing. This will be an RFC 6852
> > global community experimentation that will adhere to the "Experimentation"
> > section of the ICANN Internet Coordination Policy statement 
> number 3 (quoted
> > below). This is the way I proceeded in 2003/2004 when I conducted the
> > "dot-root" community test-bed.
> >
> > I am certainly willing to coordinate and/or discuss this testing with you
> > and ICANN, as I expect it to provide, potentially everyone, with experience
> > in cooperation/competition operational and normative relations between RFC
> > 6852 Global Communities (such as ICANN and the LIBRE Global Community).
>
>I note that
><http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-2>http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-2
>includes a range of CLASS values, from 65280-65534, that are reserved
>for private use.  This was defined in RFC 6895.  If you perform an
>experiment, I urge you to use those class values, which will relieve
>you of the requirement to do any co-ordinating with anyone outside
>your experiment group.

At this still no-home-root proliferation time, this is certainly my 
only intent. But this situation will not be sustainable, as a 
positive outcome will most probably result in three kinds of root 
files approaches:

- the "Global Community" (like the "IN" IcanN) ones. This is 
something our "WI-LIBRE" (let us call it this for clarity purposes) 
community will certainly target.
- the "VGN" (virtual glocal network) ones, maintained by a VGNIC – 
sorry, these are WILIBRE basic concepts.
- the personal ones: informed users (IUsers) will maintain their own 
glocal root by themselves with the help of specialized tools.


>I will also observe that I think DNSOP would
>very much appreciate data from your experiment regarding how DNAME and
>CNAME work under it, ideally in a parallel namespace (as is claimed to
>be expected by STD 13, anyway).

Certainly. The intent is to document it - English speaking manpower 
permitting - on <http://dnsa.org/>http://dnsa.org. Unfortunately, the 
way the IETF did not full-fledge document and maintain its technology 
(at least for the time being, in only requesting comments on a step 
by step basis) prevents us from participating in the DNSOP debate, by 
the lack of a common understanding, however few we are.

Our priority is, therefore, to build a comprehensive/consistent 
documentation (from existing RFCs) we can use.  This certainly is 
documentation that is necessary for the community effort that we will 
get checked by the DNSOP community, should they want to help.


>Best regards,
>
>A
>
>PS: not only am I speaking for myself, but I also recused myself from
>the appeal consideration because of my previous role in handling the
>document.


I fully understand and appreciate that. This is unfortunately a 
possibility I do not share myself for the time being.

I think the best is to unravel the complication we reached since 
things blocked with me over RFC 923. This seems to be possible, in 
proceeding from the DNS core since the State-Department has also 
identified it as the apex of the debate (it is also where TMs, 
languages and people direct use are bound to the technology).

It could be technically hacked in a few days. However, what we want 
to really test is wider:

- the ability of average informed users to understand it.
- hence the documentation we should produce.
- probably the various software tools involved on the user and operator sides.

This is much more demanding.

Please also note that (in addition to the IUsers) we are to expect at 
least two kinds of operators:

1. the NIC that produces a root and coordinates with TLD managers.
2. the Ledger operator that will support one or several root 
registries and, therefore, several public CLASSes.

You will, therefore, understand that I will take my time. Moreover, I 
am currently focusing on the multi/mecalinguistic issues of all this, 
the local and global catenet oriented citizen use and management as 
well as the discussion of that "WI-LIBRE" global community and 
corresponding license (such a community over networking issues must 
also be free from the Free Software limitations: everyone must be 
openly interconnectable, supported and protected).

My capacity and target is only to spark catalysis.

This seems to be feasible because I eventually understood that the 
whole industry, NSA, I*Core strategy over the last 30 years was based 
upon the BUG bug (trying to Be Unilaterally Global) transformed into 
a temporary feature by the NTIA oversight/tutorship replacing the ITU 
multilateral proposition, itself in parallel with the initial 
"advanced communication technology" (ACT) (everyone being to be 
supported) architecture I had access to and deployed.

In its own way, the NTIA has also identified this situation. My 
priority is, therefore, not anymore to try to prevent the IETF from 
conflicting with  future common interests. My simpler target is only 
to technically, intellectually, legally etc. correct the BUG. If it 
is correct, at its own pace, my fix will proceed on its own.

The only real problem left is that we are in a real-time political, 
economic context. So, I must take care to not poorly interfer with 
the evangelization, consolidation, and experimentations I need. This 
is why I think the ICANN/ICP-3 Experimentation Section makes good 
guidelines. I would certainly be interested in some improvements: I 
started working some years ago on an extensions based on a Brian 
Carpenter's I_D on technical precautions.

jfc