JFC Morfin Appeal to IESG

Un article de Wiki.

The mainly analytical approach of IETF does not appeal to most of the @large Internet lead users who might volunteer there, because they prefer a more systemic approach that will be more in line with their global daily experience and their expectation of a very short time to full and real operations. This means that the innovation, documentation, experimentation mix is to be fully imbricated. This appeal to the IESG and IAB is to be formally answered if the IETF is interested in considering the opportunity this approach and its possible hosting may represent, or not.

.

Preliminary note

This appeal is no ordinary appeal. It supports no particular contribution and is not in opposition to anyone's position. To the contrary, it fully respects the positions of the Members of the WG-IDNABIS, of its Charter, of its Chair Vint Cerf, of its AD Lisa Dusseault and of Russ Housley the IETF Chair. It is precisely because it respects these positions, which fully comply with the IETF rules, and because it is believed that every member of the IETF community will agree with them, that it can raise the probem that certain stances do not permit the IETF to plainly fulfill its RFC 3935 mission "to produce high quality, relevant technical and engineering documents that influence the way people design, use, and manage the Internet in such a way as to make the Internet work better."

This appeal starts from a case that concerns a fundamental issue for the necessary multilateral evolution of the Internet in order to address the diversity of our globally distributed world: multilingualization of the semantic namespace and any multilingual version or usage of the DNS (named here ML-DNS). It turns out that the perfect respect, by all the concerned parties of the IETF rules, leads to a situation where a certain class of contributors are prevented from informing the IETF of the impact on the matter being discussed by their WG of their own parallel exploratory work in the same area but from a wider perspective.

This class of contributors is the class of the Internet lead users, who are also called "@larges" in Internet jargon. This is because that class of contributors does not have the same working method and language, time to implementation, financial sponsoring and motivations as their other fellow Members of the IETF. As a result the IESG Chair himsef, when contacted as part of the appeal process, regrets not being informed of that work and being subsequently confused about it.

This case exemplifies that the IETF, which "has traditionally been a community for experimentation with things that are not fully understood, standardization of protocols for which some understanding has been reached, and publication of (and refinement of) protocols originally specified outside the IETF process" (RFC 3935) should adapt to the evolution of the Internet, and possibly revise its core values, if it is to continue helping the Internet work better.

This adaptation consists in accepting that the design, usage, and management of a global complex system such as the Internet must also be approached on equal footing and in a systemic manner, and not exclusively via the RFC 1958 analytic engineering manner (and thereby along its principle of constant change). The claim is that usage must be given, through the Internet lead users' contribution (@large) and other possible contributions, its full place within the Internet architectural process, with its own characteristics and human, technical, societal, economic, cultural, ethical, political, democratic and polycratic, legal, educational, etc. concerns, rights, and constraints, either within, or in adequate relation with the IETF in order to not split or balkanize the Internet's very structure, while the world evolves towards the people centric information society that was consensually declared by the WSIS (World Summit on Information Society) where we sorely missed the IETF’s participation.

This appeal seeks to make acknowledged that the adaptation of Internet to world evolution must proceed from an iterative concerted process of standardization, experimentation, and innovation, along the same commonly concerted network architectural model. This means that new protocols must be specified as much as possible at the outset within an innovation integrated adapted IETF environment if we want a complex multilateral and semantic Internet that works better.

The need for an ML-DNS

From the inception of the WG-IDNABIS proposition I was uncertain about the IETF target while as an "@large" Internet lead user, I want, and need, the kind of Multilingual Internet that will uphold the form of people-centric Information Society the WSIS has consensually declared.

The core of such a deployment is a true "ML-DNS", that is a non-predetermined open DNS solution to be analysed, discussed, documented, tested, and deployed that will guarantee the same or better QoS, in every script and language, just as the DNS does for ASCII and English.

Either this is the immediate or future target of IDNA, i.e. either IDNA is a step ahead in this direction aiming, minimally or plainly, at allowing International English access to foreign language sites and e-mails, or IDNA is for me a pure strategic waste of time such as discussed by IAB in RFC 3869.

In the second case, however extremely late, IDNA is to be perceived as an ML-DNS first/default fully interoperable option. This means that the ML-DNS development must be rushed in in parallel by the IETF or, if we are in the latter case, as an IGF emergent issue that is clearly out of the IETF scope.

WG-IDNABIS

In every case, we need a clean, simple, robust, and stable IETF/WG-IDNABIS IDNA as soon as possible.

Questions to the Chair about the operational target of the WG deliverable

This is why I asked several other @large users to join the WG-IDNABIS to help to expedite its process. To consensually identify the IDNABIS target we prepared and circulated, among usage oriented and IGF mailing lists, a set of questions that we would pose to Vint Cerf (Chair of the WG-IDNABIS).

His, and the WG-IDNABIS, response was clear. The WG-IDNABIS does not aim at delivering the ML-DNS solution that we need through any form of planned evolution, either now or in the future. Its only target is to describe abetter version of IDNA than the one that was negatively reviewed by the IAB RFC 4960. However, it could create a specialized mailing list in order to explore the ML-DNS concept.

Experience shows that @large cannot afford to discuss the ML-DNS in an IETF way: we just want to use one, who ever specifies it, including ourselves if no one else wants to do it. In that case, for us this means trying to work it out, in our own lead users' way. Therefore, I first reported to the WG in June that we will strive to keep our ML-DNS project IDNA compatible. In particular, we will use the same ISO 3166 basis for country, script, and language name codes, and the very LS 640 Open Source Table that is the basis for ISO 639-6, which is yet to be published. This way we will stay compatible with other ML-DNS gouped or individual efforts that contacted us though our http://ml-dns.org site.

Blocking point, root of this appeal

On July 11, Vint Cerf asked me to stop referring to ML-DNS the way that I did in my second mail on this engaged work.

At 13:28 11/07/2008, Vint Cerf wrote: ML-DNS is not the topic of this Working group. Whatever it may be it is not part of a relevant argument for any particular parsing of IDNA documents. Please do not continue to send emails about ML-DNS on this list.

Positions of the WG-IDNABIS Chair and Applications Area Director

I objected and indicated that I intended to appeal against this demand. I, therefore, communicated with Vint Cerf as the WG-Chairman, Lisa Dusseault as the AD and Russ Housley as the IETF Chair. Their positions are as follows:

Vint Cerf: "The purpose behind charters of WGs is to limit their scope and allow the WG to focus on its work. ML-DNS is NOT within the IDNAbis charter. The methods of IETF say you need to establish visible interest in your topic, e.g. through a BOF at an IETF. If there is sufficient apparent interest, then you can find an Area Director to support the work and develop a charter which will have to be agreed by the prospective working group participants and the IESG. If you don't want to do those things you can try to find another venue. Asking the IESG or the IAB to overturn the scope of a WG makes no sense, given the basic rules of operation of the IETF, in my opinion."

Lisa Dusseault: "If you want to participate in some other activity with the IETF aegis, you are welcome to drum up participation around your proposed activity. You can start a mailing list for ML-DNS and draft a WG charter or submit Internet-Drafts. If you want a more formal organizational relationship with the organization responsible for ML-DNS and the IETF, I informed you that the IAB is in charge of liaison relationships. None of these are dependent on any action from me, I believe. The first two are entirely within your hands, and for the last one you need to contact the IAB."

Russ Housley: "The IETF has a clear process for new work projects. You have approached the Applications AD and been told that the IDNAbis WG is not the place for the work you propose. You have also been told that a demonstration of a constituency for the work and a demonstration of people willing to do the work is necessary. I do not see anything in your note that demonstrates either one of these. Your claim that the ill-defined ML-DNS work is needed is not sufficient justification for anyone else to do the work. I suggest that a BOF is the best way to demonstrate that there is (or is not) a constituency for the work and demonstrate that there are (or are not) people willing to do the work."

Appeal

I wish to appeal this on threeseparate grounds.

1) First:

I agree that ML-DNS is not a part of IDNA because it seems obvious that IDNA is a part of any ML-DNS work, as an option to the whole. I disagree that the rigidity of the IETF Charter genuinely prevents the WG from considering the consequences of some parallel work by some of its members, on the the interoperability and the future usage of what it is working on.

Comment:

This is why the way in which I discussed our ML-DNS work was obviously not to make it specified by the WG-IDNABIS, but rather to make sure that the IDNA as specified by the WG-IDNABIS could be interoperable with any future formulation of any ML-DNS by any working group inside or outside the IETF.

2) Second:

These WG-Chair and AD positions seem fully in line with the IETF process at the WG and Area levels. The comment that was made by the IESG Chair clearly considers the practicalities of the possibility of a new work to be performed in an unpredictable future, along an IETF process, rather than our engaged work that aims at a start of deployment prior to the end of the year, and which may be within a perspective that may differently engage the evolution of Internet usage. However, in the meanwhile:

the IETF is not sufficiently addressing our users' needs, not even in the most simple way that we and the WSIS expressed them.
these needs are not considered as important or urgent enough, after eight years without a proper answer, to adapt the Internet standardization process so as to permit the contribution of lead users
the direct and indirect impacts on the Internet of an ML-DNS that is contributed by the users are not evaluated as making it worthwhile to consider interoperability at the IDNA design stage as is the case with Unicode.
we ourselves do not have the time, resources, interests, and competence to productively engage in an IETF process : we will not have the time, resources, interests, and competences to engage in an external and formal IETF relation establishment and continuation process at the IAB level. We can howerver proceed at specialised WGs and Draft publication level and possibly at a usage architecture level.

This means that the issue is to be addressed by the IESG and IAB. This justifies an appeal in order to have it publicly considered and answered, because " The IETF is always in a state of change." (RFC 4677).

Comments:

a) I object to the concept of "another venue" outside of the IETF.

An ML-DNS technology creep is probable. Our evaluation shows that a smooth transition towards a full Multilingual and Semantic Internet may be obtained through:

(1) complete revamping of most of the Internet building blocks along a new architecture like GENI might be doing.

(2) what we identify as an iterative evolution between usage experience and infrastructural progress. This is what Google is currently organizing in a private industrial manner as a consistent user oriented system. This is what the Community punctually did with NATs, and what IETF tries to do with IDNA: making user level applications/middleboxes to patch architectural lagging.

As a lead user, I consider things from a usage necessity perspective: the diversity of the more or less coordinated ways of surviving and a better use of the "as-is" Internet by each of the 6.5 billion of us, based on our "multi-consensus and living mode". From a user point of view, solutions and/or problems come from the IETF along with many other aspects that may conflict with them, which the IETF is never interested in learning. The IETF Cartesian RFC 1958 analytical approach does not sufficiently consider the Internet as a system (or it only does so in a network-centric manner).

For a user, the Internet is a global system to be considered in a people-centric way. This is why we are not interested in re-engineering the Internet building blocks, one by one, and cannot bear the costs and delays that this represents within the IETF. We just want be able to use them as some of the parts of a much more global and complex system.

This being said, we have no practical problem in creating this so-called "other venue" in order to document the better ways to use the digital convergence, multilateral stabilization, and semantic emergence that the ML-DNS is to support. However, we fully realize that if we are to do this as an interim replacement for the IETF without agreeing on interoperability and technical return for the IETF, this may either lead to a waste of effort, an alternative technology source, or a technology balkanization if others do the same in an effort to address the same imperatives.

We, also, have no specific problem in reporting our work through Draft in an IETF form, but this is not our priority when compared with our current reaserach and development effort. Moreover if this leads to drastic changes in the vision of the same Internet and leads to debate that we cannot sustain in a foreign language.

b) This is why such an @large oriented "other venue" should be organized within the IETF.

It will bring about the Information Society's "people centric" paradigm (WSIS declaration). In 1986, IETF was just that: the gathering of the Internet users community of the time to make their common network of networks work better. Today, this community includes billions of people with their own networks on the network of networks. This community needs to organize itself one step further, in an appropriate manner.

Such an appropriate manner consists, most probably, in:

maintaining a stable yet adaptive Internet ontology of reference
being documented by complementary and closely related special interest groups
working on a multi-consensus basis, i.e. detailing the interoperability between the various consensuses that may exists.
being interested in:
- what the Internet is used for
- the ethical obligations resulting from its technology
- how they are technically met
- which global architectural model is used
being permanently "inter-tested" together with their intergovernance solutions, based on community agreement defining how the internet can be used as its own operational test-bed.

UDHR, Art 27, 1: "Everyone has the right freely to participate in the cultural life of the community, to enjoy the arts and to share in scientific advancement and its benefits". I think it could also be an advisable technical R&D management guideline.

3) Third:

The WG-Chair and AD positions are justified due to the possibility that "another venue" could liaise with the IETF at the IAB level. I perceive the imposed implicit condition ("If there is sufficient apparent interest [in the IETF, not among lead users’ volunteers]) and the lack of formal support in establishing this liaison ("you need to contact the IAB") to be in contradiction with IAB's RFC 3869.

Comments

The motives that @large Internet lead users have in contributing to the Internet Research and Development as non-commercial volunteers are the same as those that are expressed by the IAB in its RFC 3869 along with the desire to assist the community with all of the extensive experience that they may have gathered.

a) In agreement with RFC 3869

"In our current challenging economic climate, it is not surprising that commercial funding sources are more likely to primarily fund research that leads to a direct competitive advantage." (RFC 3969) They want to balance the business centric commercial funding with their unpaid time and non-commercial funding to the advantage of people centric autonomous usages and to protect them from potential unthetical commercial creeps.

"The principal thesis of this document is that if commercial funding is the main source of funding for future Internet research, the future of the Internet infrastructure could be in trouble. In addition to issues about which projects are funded, the funding source can also affect the content of the research, for example, towards or against the development of open standards, or taking varying degrees of care about the effect of the developed protocols on the other traffic on the Internet." [RFC 3869] The principal thesis of this appeal is that lead user contribution is a broad source of expertise and innovation that the future of the Internet could very well depend on and should not be excluded but rather a complement of the number, methods, traveling capacity, and technical culture of the commercially funded participants.

"While it is theoretically possible for there to be too much funding for Internet research, that is far from the current problem. There is also much that could be done within the network research community to make Internet research more focused and productive, but that would belong in a separate document." (RFC 3869) The intent of this appeal is to obtain a formal IETF position on a way to foster of an Internet research and innovation that is more focused and productive.

The expected return of this appeal

This appeal is to ensure that IAB pursues its RFC 3969 request for R&D funding while considering what "practical expertise funding" by dedicated innovative people can contribute in addition to the "moneyfunding" that it difficultly gather. The IESG and IAB answers will then be the so-called "separate document" above.

Their response will state as to how the IETF wants to adequately welcome the help offered by Internet lead users.

This means respecting rather than banning them, trying harder to understand what they are saying, accepting their language diversity as a world reality to be technically supported, learning the specifications of the deliverables from them that they and common users expect, interactively advising the way they build, use, enhance, and operate the real Internet, taking advantage from a common inter-testing that involves real life network user community and WSIS originated governance. This real life context imbricates so many usages and constraints that in turn impact the Internet as well as its technical needs and that the IETF currently, use to disregards. The expected result here would be to permit more demands for adequate and diversified IETF solutions to hit the market in-time in order to be accepted and deployed more easily and broadly.

Their response may alternatively explain how they want to adequately liaise with an @large Internet lead users "other venue" and accordingly assist it to thereby deploy.

Their response may also disregard this offered assistance. This will result in a separate "other venue" that will have to separately engage in ML-DNS documentation, deployment and governance with all the architectural creep that this engineer/user, analytic/systemic, English/Multilingual, unilateral/multilateral dichotomy would necessarily imply and against which I have fought for years but would then have to accept, respecting the IETF IESG/IAB decision.