[Ianaplan] Response to my IANAPLAN Draft appeal.

[Jefsey <[e-mail]>]

Dear IAB Members,

I have read your response to my appeal. Be sure that I understand the 
difficulty you faced and I wish to thank Ted Hardy for his work. I 
will analyze it with great care over next two months, as he expected it.

Please note that this is not to waste time. It is actually to save 
some future time. One has to give time to the stakeholders to stay 
abreast of the situation as the IETF Chair Jari Arkko's blog has 
shown yesterday.

The IESG/IAB appeal process is now finished. It concludes that the 
RFC 2026 process has been rigorously respected. It implies that it 
was able to provoke questions that could and still can be pertinently 
discussed at the WG/IANAPLAN, but that the IETF process cannot 
authoritatively address.

I, therefore, understand that I must look for authoritative responses 
to these pertinent and urgent questions:

1) either in understanding and fixing the reasons for this inability 
- at least for the LIBRE RFC 6852 Global Community I documented in my appeal;

2) and/or,

- along RFC 6852, in obtaining them from markets.
- along RFC 2026, in trying to ask for them from the ISOC Chair.
- along this essential component of the Internet vitality that is 
responsible experimentation.

My intent is to explore these four venues. As explained before, this 
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).

Best regards,
jfc morfin


<quote>

ICANN ICP/3 Experimentation section the LIBRE GC adheres to.

Experimentation has always been an essential component of the 
Internet's vitality. Working within the system does not preclude 
experimentation, including experimentation with alternate DNS roots. 
But these activities must be done responsibly, in a manner that does 
not disrupt the ongoing activities of others and that is managed 
according to experimental protocols.

DNS experiments should be encouraged. Experiments, however, almost by 
definition have certain characteristics to avoid harm: (a) they are 
clearly labeled as experiments, (b) it is well understood that these 
experiments may end without establishing any prior claims on future 
directions, (c) they are appropriately coordinated within a 
community-based framework (such as <http://www.ietf.org>the IETF), 
and (d) the experimenters commit to adapt to consensus-based 
standards when they emerge through the ICANN and other 
community-based processes. This is very different from launching 
commercial enterprises that lull users into a sense of permanence 
without any sense of the foregoing obligations or contingencies.

Moreover, it is essential that experimental operations involving 
alternate DNS roots be conducted in a controlled manner, so that they 
do not adversely affect those who have not consented to participate 
in them. Given the design of the DNS, and particularly the 
intermediate-host and cache poisoning issues described in Section 1 
above, special care must be taken to insulate the DNS from the 
alternate root's effects. For example, alternate roots are commonly 
operated by large organizations within their private networks without 
harmful effects, since care is taken to prevent the flow of the 
alternate resource records onto the public Internet.

It should be noted that the original design of the DNS provides a 
facility for future extensions that accommodates the possibility of 
safely deploying multiple roots on the public Internet for 
experimental and other purposes. As noted in 
<http://www.rfc-editor.org/rfc/rfc1034.txt>RFC 1034, the DNS includes 
a "class" tag on each resource record, which allows resource records 
of different classes to be distinguished even though they are 
commingled on the public Internet. For resource records within the 
authoritative root-server system, this class tag is set to "IN"; 
other values have been standardized for particular uses, including 
255 possible values designated for "private use" that are 
particularly suited to experimentation.10

As described in a recent proposal within the IETF,11 this "class" 
facility allows an alternate DNS namespace to be operated from 
different root servers in a manner that does not interfere with the 
stable operation of the existing authoritative root-server system. To 
take advantage of this facility, it should be noted, requires the use 
of client or applications software developed for the alternate 
namespace (presumably deployed after responsible testing), rather 
than the existing software that has been developed to interoperate 
with the authoritative root. Those who operate alternate roots for 
global commercial purposes, however, have not followed this course.

In an ever-evolving Internet, ultimately there may be better 
architectures for getting the job done where the need for a single, 
authoritative root will not be an issue. But that is not the case 
today. And the transition to such an architecture, should it emerge, 
would require community-based approaches. In the interim, responsible 
experimentation should be encouraged, but it should not be done in a 
manner that affects those who do not consent after being informed of 
the character of the experiment.

<unquote>