Skip to main content

Appeal to the IESG Concerning the Way At Large Internet Lead Users Are Not Permitted To Adequately Contribute to the IETF Deliverables (JFC Morfin; 2008-09-10) - 2008-09-10
Appeal - 2008-09-10

                       APPEAL TO THE IESG

CONCERNING THE WAY AT LARGE INTERNET LEAD USERS ARE NOT PERMITTED
TO ADEQUATELY CONTRIBUTE TO THE IETF DELIVERABLES

                         BY JFC MORFIN

Abstract

The mainly analytical approach of IETF does not appeal to most of the
@large Internet lead users who might otherwise volunteer there, because
these users prefer a more systemic approach that would be more in line
with their global daily experience and their expectations of a very
short implementation time until full and real operations. This means
a fully imbricated innovation, documentation, and experimentation mix
which the IETF does not support today, trusting instead to external
innovation (RFC 3935).

The question posed to the IESG and IAB by this appeal, at the occasion
of a typical case, is to obtain a formal answer from the IETF stating
whether it is interested in considering the opportunity of such a mix,
and if so, how, or whether it is not, so that it be developed
elsewhere.

.

Acknolwedgments

I hope that this appeal will be helpful to the IETF and to the Internet
community. I wish to thank all those who contributed to it and
especially Vint Cerf, Lisa Dusseault and Russ Housley who took the time
to discuss the question with me (of course an appeal should properly be
against them, but this one certainly is not). I will not name anyone
else since this is an appeal, but the IESG is to know that it is the
outcome of positive contribution from a relatively large number of
people and that it was proposed for review by an even larger number via
several distribution lists.


Contents

  1. Preliminary note

1.1. Respecting the rules
1.2. Rules out a class of contributor
1.3. an IETF adaptation could address the issue
1.4. An adaptation which seems necessary to the IETF progress

  1. The need for an ML-DNS as a back-ground case

2.1. WG-IDNABIS
2.2. Questions to the Chair about the operational target of the WG
deliverable
3.3. Blocking point, root of this appeal

  1. Positions obtained during the preparation of this appeal

3.1. WG-IDNABIS Chair: Vint Cerf
3.2. Application Area Director: Lisa Dusseault
3.3. IESG Chair: Russ Housley
3.4. Comments

  1. APPEAL

4.1. First: over rigidity
4.2. Second: over disregarding the users needs

    4.2.1. I object to the concept of "another venue" outside of 
           the IETF. 
    4.2.2. This is why such an @large oriented "other venue" should 
           be organized within the IETF.

4.3. Third: over inconsistency with the IAB request for sponsoring

  1. The expected return from this appeal

  1. Preliminary note

This appeal is not an appeal against anything. It is an appeal to raise
a question and to obtain an answer. 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.

1.1. Respecting the Rules

 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 problem 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 and 
 systemic perspective.

1.2. Rules out a class of contributors

 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 himself, 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.

1.3. An IETF adaptation could address the issue

 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, linguistic, 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.

1.4. An adaptation which seems necessary to the IETF progress

 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.
  1. The need for an ML-DNS as a back-ground case

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 which 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.

2.1. WG-IDNABIS

 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 documented 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.

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

2.2. 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. In order 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 a better version of IDNA than the one that 
 was criticized 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, whoever 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.

2.3. 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."
  1. Positions obtained during the preparation of this appeal

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:

3.1. WG-IDNABIS Chair: 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."

3.2. Application Area Director: 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."

3.3. IESG Chair: 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."

Comments

 All these answers go along the same current IETF line: although 
 you cannot do it and do it another way, you are most welcome to 
 care about our common stuff with us and in our own way. This is a 
 positive attitude, but we need a step further towards 
 interworkability.

 I acknowledge that if I were a paid employee of a large Internet 
 stakeholder, I might follow this advice, possibly gather a small 
 WG, travel the world to attend a few IETF meetings, propose a 
 score of Drafts, publish within three to four years a few RFCs 
 documenting a solution that could deploy over the coming two 
 decades. However, like hundreds of Internet lead users with a 
 certain technical understanding of usage needs, and therefore, if 
 non concerted, of a certain technical nuisance capacity, I am not 
 a paid employee of a large internet stakeholder, yet I am a 
 network reality.

 This kind of documentary approach is necessary, however its 
 efficiency without a internal innovative impulse seems to be 
 reduced if one considers the reality test.

 For example, all these response and the comments received from 
 IETF participants considered that they needed a Draft on ML-DNS 
 before being able to discuss it with others and decide if there 
 was any interest in it. They had real  difficulty understanding 
 that ML-DNS is not a recipe with a single Draft but a target that 
 can change the whole internet, such as several small teams have 
 been discussing and testing it within the ICANN ICP-3 Part 5 
 framework that implies a virtual authoritative root file. We are 
 not trying to convince anyone of its need but are trying to avoid 
 proposition conflicts between impatient people and to render their 
 R&D strategies complementary. Four visions have already been 
 suggested:

 - multilingual domain name support 
 - multi-ledger domain name system 
 - multi-localisation digital name scalars/system/support 
 - markup-language for decentralized naming security

 To illustrate the difference in proceeding as compared to IETF: 
 after having considered these visions (without too advanced Drafts 
 rigidifying them into propositions) and how they can fit in with 
 my own semantic addressing reflection, I hope to suggest a 
 simplified syntax that could support all of them, including the 
 current DNS namespace, as a wiki page where other visions will be 
 able to proceed in parallel and to try to maintain systemic 
 interoperability.
  1. APPEAL

This is why my appeal aims to address three separate issues.

4.1. First: over rigidity

 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 issue of 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.

4.2. Second: over disregarding of the users' needs

 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 task to be performed in an unpredictable 
 future, along an IETF process, rather than our engaged work that 
 aims at the start of deployment before the end of the year, and 
 which may be within a perspective that may differently engage the 
 evolution of Internet usage. However, in the meantime:

    - 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 to so as to enable 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, nor 
      competence to productively engage in an IETF process : we 
      will not have the time, resources, interests, nor competences 
      to engage in an external and formal IETF relation 
      establishment and continuation process at the IAB level. We 
      can however proceed at the 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 to have it be publicly considered and 
 answered, because "The IETF is always in a state of change." (RFC 
 4677).

 Comments:

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

      A 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) or 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 ever evolving 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 Drafts in an IETF form, but this is not our priority 
      when compared with our current research and development 
      effort. Especially if this leads to drastic changes in the 
      vision of the same Internet and leads to debates that we 
      cannot sustain in a foreign language.

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

      It would 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.

 Universal Declaration of Human Rights, 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 this could also be an 
 advisable technical R&D management guideline.

4.3. Third: inconsistency with the IAB request for sponsoring

 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 acquired.

      "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 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 unethical 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 so as to foster Internet research and 
      innovation in a more focused and productive manner.
  1. The expected return from 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 "money
funding" that it gathers with difficulty. The IESG and IAB answers will
then be the so-called "separate document" above.

Their response will state 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 common inter-testing
that involves real life network user communities and WSIS originated
governance. This real life context imbricates a great many usages and
constraints that in turn impact the Internet as well as its technical
needs which the IETF currently 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.

Jean-François C. MORFIN
jefsey@jefsey.com

http://ml-dns.org