Appel à l'IAB

Un article de Wiki.

Dear IAB Members,

This appeal follows my appeal to the IESG in Annex A and builds upon the IESG response in Annex B.

.

Sommaire 1 Introduction 2 Response given by the IESG and follow-up 3 Practical inability to cope with RFC 4052 4 Better definition of the concept of user 5 Documenting precaution as an IETF cardinal principle 6 Matter of the appeal

Introduction

The initial appeal to the IESG concerned an IETF structural need at the occasion of a particular case. The need is the practical ability of Internet users to positively contribute to the IETF Internet standardization process. The question was posed in order to find out whether that need was acknowledged by the IETF, if the IETF wanted to see it addressed, and if it wanted to see it addressed within or outside the IETF.

This meant that neither the actions of the concerned WG-Chair nor the concerned AD were directly contested. However, pertinent advice from the AD included an IETF liaison of a possible solution through the IAB. A mutually rewarding establishment of such a liaison (1) required, firstly, the above response in order to determine its framework,(2) conflicted with the fundamental reason for the appeal (the practical, educational, linguistic, and even sometimes cultural inability of Internet users to cope with the IETF/IAB mandatory modus operandi), (3) the need to see the meta-reason for the first point of the appeal fully addressed. This meta-reason is the need for a formal clarification of the IETF "precaution duty", which is implied but not documented by RFC 3935 through the description of the IETF cardinal principles.

Response given by the IESG and follow-up

The response provided by the IESG is twfold:

• it states that the claims are being rejected because they do not identify specific WG decisions or actions that the appellant wishes to have reversed or remedied, and as such the claims are not actionable.
  This is not contested by the appellant. However, the second response that was provided by the IESG sheds new light on its position and creates an actionable point for the IAB regarding the IESG.

• it then states "Although the appeal does not specifically recommend any remedial action, it strongly encourages the IETF to initiate some work. The appellant is directed to RFC 2418 for instructions on how to initiate work in the IETF."

I, along with most of those who supported my appeal in the first place, understand this response as:

• yes, the IESG acknowledges a possible need.
• yes, it wants the response to this need to be investigated inside the IETF.
• in spite of the documented practical, educational, and cultural difficulties, the response to this need should, as much as possible, respect the IETF ways.

As a consequence, I reflected RFC 2418, RFC 2026, RFC 3869, RFC 3935, RFC 3772, etc. I reported that respective reflection to Russ Housley as follows:

"I [] have something consistent to propose: an Internet Users Contributing Group. It could be a mailing list in the General Area as discussed, since the User Area has been closed. It would not be a WG because it would be permanent.

Its first mission would be to define its own charter and a working method, based upon the experience gathered during the first months [in operation] and [be]as much as possible in line with RFC 2418 and 2026. Due to my [work]load I [could only] proceed slowly. Its general mission could be to:

• collect Internet Users contributions and shape [them] together to the benefit of the IETF Working Groups.
• [collectively] comment [during] the IETF Last Calls as [per] the Internet Standard process.
• assist Internet Users in presenting multiconsensual Internet Drafts [by] gathering their suggestions.
• work out and maintain [consolidated] documentation of an Internet usage architecture.
• maintain usage related information tables.

I must file the IAB appeal before [29] Nov. I need it because all of this can only be [seen as] appealing to people if it is here to help apply a "precaution principle" and a "precaution duty" documented by the IAB. This consists in [clearly stating] that,

(1) by precaution Vint Cerf should not have prevented me from referring to the danger of IDNA conflicting with ML-DNS projects.

(2) but since this precaution duty is not included in the Internet standard process, it would be advisable that the IESG finds and implements a mechanic to assist the WG Chairs by informing them of users' remarks.

Such a solution could be the IUCGroup that I am suggesting.

This could be a short document focusing on that point as a need to follow RFC 2418 for the IUCG project concept, with the IESG appeal and response in annex."

The iucg@ietf.org has been approved and installed on Nov 17, 2008. A site is under implementation and is subject to bootstrappers' debate [htt://iucg.org].

Practical inability to cope with RFC 4052

There are three main reasons as to why it seemed that RFC 4052 was not appropriate. The main point of IUCG should be to interface the IETF vision, culture, way of thinking, core values (as per RFC 3935), Internet standardization process, IANA, etc. with "user-diversity" :

• on the users' side, the main difficulty is the lack of resources, time, and, therefore, the stability to participate to the IETF in a proper way. We are hardly able to select and retain a person as a liaison. Moreover, in having no established process to that end, the legitimacy and hence the credibility of such a liaison would probably be challenged.

• the magnitude of user-diversity is probably only met by the magnitude of the possible subject diversity. A single or structurally limited number of liaisons would most probably never be knowledgeable enough to get the users' message and contribution through.

• the whole idea in having the IUCG is also to have the most dedicated users informed and trained so that they might directly contribute to the IETF working groups. An IETF liaison through the IAB would only introduce an artificial barrier. Moreover, on occasion IETF Members might want to directly share a debate on the IUCG side in order to directly better understand the users' needs, constraints, and flexibility.

Better definition of the concept of user

As part of the preparation of the IUCG, I requested the cretation of a closed "atlarge@ietf.org" list. My target was to prevent a confusing alternative request. Russ Housley indicated he was ready to support a list but with a name not leading to believe that IETF supported the AtLarge stuff.

This was carefully considered and debated. The most common advise I received was to consider "users" as a function rather than as a group of person, and - since the IETF was hosting the list - to be more IETF specific to avoid confusion, but also to better participate to the IETF Internet process in considering first the users of the IETF deliverables, which are (RFC 3935) to influence the way people design, use, and manage the Internet in such a way as to make the Internet work better.

The following paragraph has therefore been retain to introduce the IUCG: "The Internet Engineering Task Force (IETF) is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet. It is open to any interested individual. The IETF Mission Statement is documented in RFC 3935. The IUCG extends this community to those users (1) of IETF deliverables, who trust and/or adapt them in order to build, use, and manage their own network solutions and products, and (2) of the global Internet as their common by-product. Because the IUCG is an integral part of the IETF, the following "Note Well" applies."

This means that the IUCG role is not only to contribute with the suggestions of the internet governance and of the lead and end users but also with the comments of the RFC users. This is also considered as a better incentive to maintain intercompatibility between IETF tables and usage related tables.

An additional important suggestion was received and confirmed by several persons, including end users, politics, journalists: the IUCG should develop and maintain one or several well identified models of the Internet and of the digital ecosystem. Once their differences with the legacy IETF model well identified, comments and suggestions might be made easier to understand, discuss and compared when introduced within their contextual framework.

Documenting precaution as an IETF cardinal principle

When IETF was created, its Members were mostly engineers administrating their own machine. For that reason, IETF external documents are of two main different kinds (RFCs by engineers and BCP by users) that are discussed by the same IETF Members. This certainly ensures their common consistency but leaves many inputs pushed aside, which are only considered outside the IETF process and are protected by pattents instead of being made an open standard.

"The IETF 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]

This has resulted in sound solutions but also in lateness and rigidity in delivering solutions that had to be further adapted to the present market conditions, to match further innovation, or to circumvent patents protecting ideas that were first introduced by users. The target of the IUCG in interfacing lead users, and possibly ordinary users (or at least their representatives), with the IETF are:

• a faster and more flexible transmission of external innovative "prior and rough understandings" to the IETF.
• under a "multiconsensual" form. This means that various ways of approaching a subject should be contributed, filtered through sub-group consensuses that have different propositions, and completed by thinking about their mutual interoperability.

Such a fruitful possibility has to be practically permitted. This means that no decision should be made by the IETF that could put at a risk innovative thinking, be misunderstood or missing, constrain usage development, or conflict with possible solution already under exploration or partial operation.

• the IUCG should be one of the ways to make the IETF aware, through its debates, reports, and IETF-Drafts.
• the IETF adheres to the RFC 3935 defined cardinal principles. These principles imply, but do not explicitly state "precaution". There is no guidance on the ways to enforce it.

IUCG will most probably use tools and procedures in line with the common users' ways, such as surveys to gather their contributions and protests and a wiki to articulate "rough multiconsensual prior understandings". It will attempt to present them structured in parallel to the IETF WGs structure and to their benefit. A tool is planned to build IUCG IETF_Drafts reporting on the collected users' contributions. from "IUCG Wiki Pages" (IWP).

A practical way to enforce precaution could be to optionally include in RFCs a "precaution section", just as there is presently a"security section". This section would discuss the RFC in comparison with users' contributions. Experience would tell whether this suggestion, which leaves the Internet standard process unchanged, is of interest and under which conditions.

Matter of the appeal

My IESG appeal, the IESG response, and all of the above being considered, I call upon the IAB in requesting that the IESG is corrected or at least commented on as follows:

• the response to point one of my initial appeal is correct. The WG Chair was, in his own right, calling on a strict respecting of the charter. However, in a global IETF point of view, just as IESG is pushing me to consider, it is inappropriate to impeach a WG, in which the IETF will benefit from side, yet interoperability related, inputs and/or parallel thinking from the Internet community.
  
  Precaution should be accepted among the IETF cardinal principle and therefore supersede the Charter at the WG-Chair or AD decision. In case of doubt, WG should more liberally call for IAB guidance. They could often find a response when wording the terms of a problem that is to be submitted to the IAB.

• the advice I received from the AD about a liaison with the IETF and then from the IESG about a way to address the problem of the contribution of the users to the IETF were pertinent and have been used with the creation of the iucg@ietf.org mailing list and site, as well as the way that this appeal is written. However, to still best address the specifics of this particular case:

• they should be completed by a request to the WG-Chairs to make sure the precaution principle and duty are being considered. This might mean that any matter related to the WG Charter areas, or projects considering direct, indirect, or future interoperability with WG deliverables should be accepted as "on topic". This would be moreover the case,, if they are considered in other IETF working groups, drafts, and mailing lists including the Internet Users Contributing Group . The same WG Chairs should be suggested to consider a section that is dedicated to the precautions taken in order to preserve present and future interoperabilities as well as users' requests.

• WG and IETF Mailing List Chairs could be suggested to help the IUCG to maintain succinct yet comprehensive information for the users and concening their explortation of the architectural and technical issues documented by their Charter.