Response to the appeal from Jefsey Morfin dd 7 June 2010

IAB Chair <> Fri, 20 August 2010 17:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 00B783A6AF1; Fri, 20 Aug 2010 10:31:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -100.959
X-Spam-Status: No, score=-100.959 tagged_above=-999 required=5 tests=[AWL=-0.960, BAYES_50=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AVJtQZluJHUI; Fri, 20 Aug 2010 10:31:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 940693A6B0B; Fri, 20 Aug 2010 10:31:12 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 76623E08C1; Fri, 20 Aug 2010 10:31:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I9+KywQknj4a; Fri, 20 Aug 2010 10:31:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id 284DAE0874; Fri, 20 Aug 2010 10:31:43 -0700 (PDT)
From: IAB Chair <>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Subject: Response to the appeal from Jefsey Morfin dd 7 June 2010
Date: Fri, 20 Aug 2010 19:31:40 +0200
Message-Id: <>
To: IETF Announcement list <>, jefsey Morfin <>
Mime-Version: 1.0 (Apple Message framework v1081)
X-Mailer: Apple Mail (2.1081)
Cc: " IAB" <>, The IESG <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IETF announcement list. No discussions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 20 Aug 2010 17:31:18 -0000

On 7 June 2010 the IAB received an appeal from J-F C. Morfin, related to an earlier appeal from Mr. Morfin to the IESG that the IESG rejected on 7 April 2010. The text of the appeal to the IAB can be found at the following URL:

The IAB understands the relevant points to be these:
1.	Mr. Morfin argues that the IESG cannot claim an appeal is "a violation of RFC2026" solely on the grounds of its length, as RFC 2026 requires appeals to "include a detailed and specific description of the facts of the dispute," which might require significant background material to satisfy. 
2.	Mr. Morfin insists that the "underlying principles to support any [linguistic] diversity should be further studied, confirmed, and documented." He believes that the work done by the current round of IDNA is incomplete, and that this has serious consequences for the Internet architecture. By implication, he argues that the IESG erred in rejecting his appeal on the grounds that it was too broad. 
3.	Mr. Morfin argues that there is a gap in the IDNA 2008 work due to the abandonment of the working group "mapping" document (draft-ietf-idnabis-mappings). By implication, Mr. Morfin argues that the IESG erred in rejecting this working group document, and that the IESG erred in rejecting his appeal to reinstate the document in some fashion as a component of the IDNA 2008 work. 
4.	Mr. Morfin calls attention to the apparent conflict "between the positions of the WG (author) and the position of the IESG", in particular reference to the rejection by the responsible AD of the working group item "mapping" draft. He argues that when these conflicts arise, the IAB holds procedural responsibility for dispute resolution, though he cites no process language that supports his specific view. He contends that an IAB "disclaimer" similar to an IESG note might be included in a document to characterize the IESG disagreement with the charter (presumably, with the implication that the document would then proceed despite the IESG objections).   He also suggests that there may be a "conflict between the [IDNABisWG] Charter and the IESG".
5.	Mr. Morfin argues that the architectural implications of the rejection of the mapping document are not well understood by the community - that "the IESG has not mentioned the change of paradigm" and "does not permit the community to become aware of this change." By not publishing the mapping document while approving the remainder of the IDNA 2008 cluster, the IESG "has confused the meaning of this approval." Mr. Morfin thus believes it is incumbent upon someone to explain exactly how IDNA 2008 is supposed to work without this document. Thus, although "the IESG does not direct the work of the IAB," Mr. Morfin rejects the IESG's contention that the IAB may elect to address these internationalization concerns or not as it sees fit - Mr. Morfin insists that they must be addressed. 
6.	Mr. Morfin rejects the IESG's claim that his appeal was not actionable since it requested no clear remedy. He suggests that the IESG has taken several actions already related to the subject of his appeal. He rejects the idea that he should undertake work himself on a new document to fill any gaps in the architecture, insisting that he prefers "to follow the procedure and leave the IAB to decide first" how the architecture should look. He also proposes several changes to IETF process, including the creation of a "user comment" section in RFCs, which he considers potential alternatives to using appeals to raise objections to documents or to call for IAB guidance. 
7.	Mr. Morfin rejects the IESG suggestion that he might request a BoF as another possible avenue to remedy the perceived gaps in IDNA 2008 within the existing IETF process. Again, he argues that it is the responsibility of "the IAB to give the Internet technical community the necessary guidance" and he would rather leave BoFs to "those who are competent in leading the IETF." 

The IAB addresses these points in turn:
1.	The IAB concurs that RFC 2026 does require appellants to "include a detailed and specific description of the facts of the dispute," but the IAB does not find that the IESG treated the length of Mr. Morfin's appeal as grounds for its dismissal. Instead, the IESG "strongly encouraged" appellants "to provide a clear, concise, and focused text." 
2.	The IAB agrees that internationalization should be "further studied, confirmed and documented," and concurs that additional work on internationalization architecture and mapping is required. The IAB looks to the community to further engage in this problem space. As an overseer of this community process, the IAB recently approved draft-iab-idn-encoding for publication as an RFC, which the IAB hopes will help steer work in the internationalization space toward productive directions.  The IAB will continue to provide architectural oversight in the area of internationalization.  Indeed, in the recent IETF plenary the IAB listed internationalization as one of its long-term programs.
3.	While the IAB acknowledges that endpoint implementations of IDNA 2008 require mapping procedures, this does not mean the IESG was obligated to advance any particular mapping document. The IAB finds that RFC 2026 empowers the IESG to reject the products of working groups at its discretion (per Section 6.2, "The IESG is not bound by the action recommended when the specification was submitted"), provided it follows the proper procedure in doing so. Moreover, a mapping document need not progress through the IESG in order to be published as an RFC, nor must it be published as an RFC in order to be used as a mapping procedure by implementations. The IAB observes that a successor document to the abandoned working group item (draft-resman-idna2008-mappings-01.txt) has subsequently advanced through the Independent Submission stream to the RFC-Editor queue, where it will shortly hold Informational RFC status as originally targeted by draft-ietf-idnabis-mappings. 
4.	There are no process grounds for the IAB to insert any sort of disclaimer into an IETF document, nor to intervene in similar fashion in points of disagreement between the IESG and working group participants. However, the IAB does observe that the charter of the IDNAbis working group lists vague milestones that make it unclear what exact documents the IESG intended for the working group to produce, and that this vagueness complicates any disagreement between the IESG and the working group on the acceptance of deliverables. The IAB recommends that the IESG avoid complications of this nature by requiring more specific charter milestones in the future. 
5.	The responsible Area Director for the IDNAbis working group did notify the working group via the IDNAbis mailing list of the decision not to advance draft-ietf-idnabis-mappings (see Consequently, the IAB cannot agree that the IESG "does not permit the community to become aware of the change," as interested members of the community can review this message in the public mailing list archive. However, RFC 2026 Section 6.1.2 does require that "In a timely fashion after the expiration of the Last-Call period, the IESG shall make its final determination of whether or not to approve the standards action, and shall notify the IETF of its decision via electronic mail to the IETF Announce mailing list." Section 4.2.3 further clarifies that the same process applies to documents proposed for Informational RFCs by IETF WGs.  The IAB does not find that the IESG sent this mail to the IETF Announce mailing list, and thus this appeal response hereby directs that the IESG do so.  The IAB also believes that this procedure, once followed correctly, provides the required level of community notice and hence the IAB did not request a delay in the publication of the other documents.  The IAB also observes that the motivation for the IESG decision could have been documented more clearly and explicitly in the existing document tracking tools; while this is not required by any current process, it would have expedited the IAB's appeal process.
6.	The IAB is not empowered to implement any of the process modifications that Mr. Morfin suggests as an alternative to using appeals to raise objections to documents or to call for IAB guidance; any such change to the approval or correction of RFCs would require a broader community consensus.  The normal process for raising objections to documents is via email during the review period; for example, the IETF Last Call announcement states that comments may be sent to or directly to  Similarly, simple requests for IAB guidance can be done via email to without resorting to the appeals process.
7.	The IAB reaffirms the IESG's position that the community must produce the necessary technical work to fill any gaps in the IDNAbis architecture. The community may initiate new work by methods including submitting Internet-Drafts and requesting BoF sessions. 

As Mr. Morfin's appeal concludes with the statement that "in case this appeal is disregarded, I will understand thereby that the IAB does not object to the following understandings of IDNA2008," which introduces some additional pages of claims, the IAB would like to clarify that it takes no position with regard to those subsequent assertions.  

For the IAB,

--Olaf Kolkman
  IAB Chair

This appeal was handled by the voting members of the IAB with the exception of Ross Callon, Russ Housley and John Klensin, who all recused.

The Internet Architecture Board