Subject: Appeal to the IESG concerning the approbation of the IDNA2008 document set.

From: Russ Housley <[email-masked]>
Date: Wed, 10 Mar 2010 17:43:12 -0500

The IESG has received an appeal.  It can be found here:
http://www.ietf.org/iesg/appeal/morfin-2010-03-10.pdf

JFC Morfin included these comments in the cover note:
>
> Basically this appeal documents that IDNA2008 enlight capacities
> and principles that are built in the Internet technology but that
> were not used. This is a great thing. However the IESG has not
> included a disclaimer on top of these documents, nor foreseen how
> and where the necessary IDNA user-side issues are to be discussed
> and documented. This may lead people like me to unpredictably toy
> with them without any established Adminance (governance of the tools
> to be managed by the Governance) arrangement, or organizations like
> ICANN to engage into inappropriate testing.
>
> The document size is impressive. There is three reasons to that:
>
> - the impact on the Internet usage architecture is potentially
> impressive
>
> - the change is not in the technology, but in the way to consider
> the technology and the way it addresses multiplicity. IDNA2008 is
> about pople's multilinguization while IDNA2003 was about Unicode's
> globalization. This is a big change that multilinguists can discuss.
> However, everyone has to understand it simplifies the complexity of
> handling multiplicity (RFC 3439 - principle of simplicity) in
> conformance with RFC 1858 to do it at fringes. RFC 1958 also advises
> to keep the first solution when it works.
>
> - the third reasons is that I do not want to be accused of not having
> checked my rationale for Interplus and further Intersem work. NB. I
> call Interplus is what I think Internet needs to be able to fully
> support the Intersem (that the IDNA2008's approaches simplifies), and
> the Intersem is what IDNA2008 introduces: the capacity for brain to
> brain interintelligibility.
>
> The document is also maintained as a wiki under
> http://iucg.org/wiki/100310_-_JFCM_Appeal_to_the_IESG.

The IESG plans address this appeal in the next few weeks, and the IESG
solicits comments on this appeal from the community.  Please send
substantive comments to the [email-masked] mailing lists by 2010-03-27.
Exceptionally, comments may be sent to [email-masked] instead.

On behalf of the IESG,
  Russ Housley

---

From: Ted Hardie <[email-masked]>
Date: Wed, 10 Mar 2010 15:20:54 -0800

Hi Russ,

The appeal appears to run 145 pages, at least in my PDF viewer.
Attempting to navigate
this, I see "points of appeal", which has the following text:

"This is why this appeal does not concern the IDNA 2008 document set,
as approved by the IESG, which is now of prime stable importance when
considering the Internet architecture from a user perspective, but
also concerning the way the IESG has approved this IDNA2008 document
set, while:

not obtaining and inserting a disclaimer from the IAB in turn warning
the Internet users community about the architectural consequences of
the "unusual" strategy that the IETF adopted in this document set "to
insure interoperability" (cf. Mapping document).

not classifying it as an IESG disclaimer warning for the Internet
users community about the necessary incompleteness of the new
introduced IDNA architecture, when compared to IDNA2003, due to its
open nature on the user side.

in spite of the Working Group Summary statement that: "There was an
impasse relating to the mapping of Unicode characters into other
Unicode characters prior to the generation of a punycode equivalent
string to produce an A-label [please see the Definitions document].
This was resolved by introducing the non-normative “mappings”
document", wherein that Mapping document was not simultaneously
approved, but while it should at least have been acknowledged at the
same level as the Rationale document.

in so doing, in not having considered its precautionary duty enough as
it results from the IETF mission, and introducing confusion that is to
be urgently clarified before its consequences might endanger the
entire Internet system architecture and the operational deployment
unsuitability for the reasons detailed in this appeal."

Trying to combine this with the cover page text as best I can, this
appeal seems to request the IESG to
provide a set of warnings around this document and/or a disclaimer
saying that the technology is not ready
to use.

Is that interpretation a reasonable approximation of your
understanding of the actions requested of
the IESG?

regards,

Ted Hardie

On Wed, Mar 10, 2010 at 2:43 PM, Russ Housley <[email-masked]> wrote:
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Russ Housley <[email-masked]>
Date: Wed, 10 Mar 2010 18:28:57 -0500

Ted:

There is an IESG Telechat tomorrow with 22 documents on it.  Outgoing
ADs are trying to clear as much work as possible for the incoming ADs.
So, frankly, I've been focused on these 22 documents, and I will not be
able to read the 140+ page appeal until the IESG Telechat is over.

Thanks for your reader's digest version.

Russ

---

From: Ted Hardie <[email-masked]>
Date: Wed, 10 Mar 2010 15:34:57 -0800

> Thanks for your reader's digest version.

Fair enough; good luck with the effort to clear.

regards,

Ted Hardie

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 10 Mar 2010 15:42:12 -0800

> this, I see "points of appeal", which has the following text:
...
> saying that the technology is not ready

Folks,

I am increasingly concerned about efficiency in the IETF, given the loads 
everyone is carrying.  One source of inefficiency is having someone create work 
for others, without having already done enough of their own work.

I firmly believe in the importance of the appeals mechanism, but I think there 
are obligations on the person lodging the appeal, as well as on the body 
processing the appeal.

It simply is not reasonable for the body to be forced to make guesses about the 
nature of the appeal or to have to wade through massive documents in order to 
understand the appeal.  At the least, massive and/or confused appeals constitute 
a denial of service attack.

An appeal needs to state its concerns and requirements clearly and concisely. 
That might include masses of reference material, but the appeal statement, 
itself, needs to be short and to the point.

When an appeal is lodged that fails these basic criteria, I strongly suggest 
that it is imprudent to invest valuable IETF management time processing unclear 
text or a mass of text.

The prudent action is to return it to the appellant, stating that it cannot be 
processed until it has been made clear and concise.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: David Kessens <[email-masked]>
Date: Wed, 10 Mar 2010 16:09:55 -0800

On Wed, Mar 10, 2010 at 03:42:12PM -0800, Dave CROCKER wrote:
> 
> The prudent action is to return it to the appellant, stating that it
> cannot be processed until it has been made clear and concise.

I fully support such an approach (and did propose the same strategy to the
IESG while I was a member of the IESG myself).

David Kessens
---

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Mar 2010 13:34:59 +1300

> IESG while I was a member of the IESG myself).

I agree. Our process may be complicated, but a deviation from due process
that requires 145 pages of description is simply not possible. We have
specific rules in RFC 2026 and RFC 2418 (and various updates) and it should
be possible to describe specific alleged deviations from those rules in a
page or two. If the appeal merely reflects the fact that the appellant
disagrees with the WG consensus, that is not a ground for appeal.

I do not believe the IESG is under any obligation to spend its precious
time digesting such a mass of text to discern any actual grounds for
appeal.

   Brian

---

From: [email-masked]
Date: Wed, 10 Mar 2010 17:00:46 -0800 (PST)

> time digesting such a mass of text to discern any actual grounds for

+1

				Ned

---

From: John Levine <[email-masked]>
Date: 11 Mar 2010 05:07:27 -0000

> I do not believe the IESG is under any obligation to spend its
> precious time digesting such a mass of text to discern any actual
> grounds for appeal.

Legal systems have rules about vexatious litigants, people who
repeatedly file meritless actions that waste an unreasonable amount of
time and effort.  The IETF is certainly not a court, but it shares
many of the same issues of process and abuse thereof.

The IETF process including appeams is a means to getting work done,
not an end in itself, and it is reasonable to make rules that protect
the ability to get work done.  You all know what I mean.

R's,
John

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Thu, 11 Mar 2010 08:49:42 +0100

+1

Bert

---

From: Olaf Kolkman <[email-masked]>
Date: Thu, 11 Mar 2010 09:05:53 +0100

> 
> Folks,
> 
> I am increasingly concerned about efficiency in the IETF, given the loads everyone is carrying.  One source of inefficiency is having someone create work for others, without having already done enough of their own work.

> [...]

A few years ago I proposed http://tools.ietf.org/id/draft-kolkman-appeal-support

   Abstract

   RFC 2026 outlines the procedure for appealing decisions or process
   failures to the IESG and the IAB.  This document describes how an
   appellant should first gain support for filing their appeal before an
   appeal is being considered.

I just went back to thread starting at http://www.ietf.org/mail-archive/web/ietf/current/msg43976.html to convince me that dropping the document at that time was done based on lack of support. It seems to me that at the time  there were to many difficult and contentious details that it was not really worth the effort to prioritize on that document. While the gist of the discussion went in the direction to suggest the IAB and IESG that appeals could be returned with a stamp "no merit".  

Ted's mail triggered the thought that appeal support could also go another way. If there are people who think that an appeal is important they can help the appellant to create a concise and direct appeal. 

-- Olaf
   (no hats)  

PS Note the subject change. I am not talking about a (this) specific appeal.

________________________________________________________ 

Olaf M. Kolkman                        NLnet Labs
                                       Science Park 140, 
http://www.nlnetlabs.nl/               1098 XG Amsterdam

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 11 Mar 2010 09:24:38 +0100

On Wed, Mar 10, 2010 at 03:42:12PM -0800,
 Dave CROCKER <[email-masked]> wrote 

> cannot be processed until it has been made clear and concise.

I approve and I also believe that, giving the past interactions with
the appellant, there is a wide consensus inside IETF to process his
appeal very quickly (see John Levine's excellent point about full-time
litigators).

---

From: Eliot Lear <[email-masked]>
Date: Thu, 11 Mar 2010 09:35:15 +0100

On 3/11/10 9:24 AM, Stephane Bortzmeyer wrote:
>   Dave CROCKER<[email-masked]>  wrote

I agree on both counts.

Eliot

---

From: SM <[email-masked]>
Date: Thu, 11 Mar 2010 03:11:42 -0800

>The IESG has received an appeal.  It can be found here:

[snip]

>solicits comments on this appeal from the community.  Please send

I will not be able to reply to off-list comments about this appeal.

The document written by the appellant contains what seems to be 
lengthy background information.  It would have been easier to read if 
the usual guidance for RFC style was followed.  There is a view that 
the probability of the reader understanding the points raised by the 
appellant is inversely proportional to the number of pages in the document.

On Page 2, it is mentioned that "the IESG has failed in its 
precautionary duty".  The argument seems to be the lack of a 
disclaimer of liability in the IDNA2008 specifications.   I have some 
difficulty understanding the notion of "precautionary duty" described 
by the appellant.

On Page 3, it is mentioned that the appeal is from an Internet 
User.  I presume that the appellant means "from an IETF participant".

On Page 6, the argument seems to be about a disclaimer from the 
IAB.  It is hard to say whether the appellant wants an IESG or IAB 
disclaimer.  By the way, the mission statement does not cover 
publication procedures.

On Page 9, ICANN is mentioned with a quote from what looks like press 
release material.  I don't see what the IETF can do to change ICANN's 
point of view.  It may be judicious for the appellant to discuss 
about ICANN issues with ICANN.  The document mentions confusion 
shared by Internet Governance stakeholders.  As neither the IESG nor 
the IAB govern the Internet, I don't see the relevance.  The IETF 
obviously doesn't run the Internet or even believes that it runs the Internet.

I presume that the annexes as from Page 21 are to provide background 
information.

I'll note that there has been a healthy debate within the IDNAbis 
Working Group about the points mentioned in this appeal.  I would 
describe working group participation as unusual and well above the 
average participation as there was representations from people who 
are from several countries; some of which do not have English as 
their native language.  The IDNAbis Working Group brought together 
the expertise, as far as it was practical, to tackle such a difficult 
and delicate subject.  It was a balancing act for the Working Group 
Chair to determine consensus.  In my opinion, it was done in a fair 
and open manner without any hint of exclusion of views that are not 
part of the main stream.

Allowing recourse to an appeal is important as there as "there are 
times when even the most reasonable and knowledgeable people are 
unable to agree".  It is not up to me to judge whether this appeal is 
reasonable or whether the appellant is knowledgeable about the 
subject discussed in the document.  My biased opinion is about the 
document at hand.

After reading and reading the document again, I could not find any 
arguments that points to an Internet Standards Process failure.  To 
say that I am far from convinced about the technical merits of the 
appeal would be an understatement.  If the appellant is asking for an 
IESG or IAB disclaimer, I do not find any technical reason to support 
the inclusion of such a statement in the IDNA20008 document set.

Due to the subjectiveness of presentation layers, I may have missed 
what the appellant is asking for.  I unfortunately cannot solve 
presentation issues that are outside my control.  If the IESG 
encounters such issues with this document, I suggest that it asks the 
appellant to clarify what action is being sought.

Regards,
-sm

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 11 Mar 2010 08:04:47 -0500

It is important to do so in ways that ensure that the insurance
criteria are not breached.

Returning the document is not covered in the rules. But there seems to
be no reason that the IESG could not ask someone (e.g. Ted Hardie who
has already done so) to write up a concise summary.

-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 11 Mar 2010 17:43:34 +0100

+1

	Henrik

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 11 Mar 2010 16:56:30 +0000

>> processed until it has been made clear and concise.

Me too,

Stephen.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 11 Mar 2010 12:16:15 -0500

To the IESG:

> http://www.ietf.org/iesg/appeal/morfin-2010-03-10.pdf

I have read the document, though I cheerfully concede that some of the
text eludes my understanding.  I was an active participant in the
IDNABIS WG.  I supported the WG document set.

As near as I can tell from the PDF, the actual substance of the appeal
is entirely in section 3.  There are scanty arguments in favour of the
substantial appeal items.  The rest of the document comprises a great
deal of background material, and an argument that a lot more work is
needed on IDNA in order to meet real users' needs.

The opening sentence of section 3 says, "This is why this appeal does
not concern the IDNA 2008 document set, as approved by the IESG, which
is now of prime stable importance when considering the Internet
architecture from a user perspective, but also concerning the way the
IESG has approved this IDNA2008 document set . . . ."  As near as I can
tell, that says that it is _not_ an appeal of the document set itself.
It is instead an appeal that the documents were not published with
disclaimers attached.

The bullets following the first sentence seem to support to support my
interpretation.  I think the bullets are preposterous.  If
generalized, they effectively argue that the IESG needs to insert or
obtain disclaimers about a protocol for the architectural consequences
of the protocol, or whenever a protocol is somehow incomplete.  Two
major premises are offered for the conclusion.  First, we have a claim
that the WG failed to reach consensus on a topic on which the
appellant thinks the WG should have done; this is not a generalizable
principle.  Second, the appellant claims that the IESG has a
precautionary duty that makes the disclaimers necessary.

Let us start with the easy premise.  Given that there are sometimes
disclaimers attached to documents, and given that the IESG lies on the
path to publication of documents on the standards track, it is either
trivially true or false that the IESG has a precautionary duty when it
finds that a document that otherwise is the product of IETF consensus
is dangerous to the operation of the Internet.  It is trivially true
in the sense that the judgement of the IESG is exactly what we have an
IESG for, and part of the process of judging is ensuring that a given
document does not entail harm.  It is false in the sense that _any_
change on the Internet has the potential to cause trouble.  If there
is a strong precautionary duty, then in fact every document that makes
any innovation of any kind would need to come with a warning saying
that the innovation has not been tested in ubiquitous deployment on
the public Internet.

It is that "false" meaning that shows the deep confusion underlying
the rest of the appeal.  For the appeal at bottom assumes that RFCs
are near-scriptural in their force, as though the Internet proceeds
from the Word made RFC.  The plain fact is that, if the IESG always
needed to obtain or insert disclaimers whenever there are
architectural consequences or whenever the protocol was incomplete,
then such disclaimers would become new decorations of nearly every
RFC.  It is only when there is significant danger of harm that such
disclaimers are needed, and not at other times.

The standards maturity levels of the IETF are the real mechanism to
provide the indicators the appellant seems to want: new, untested
protocols do not come out as STANDARD, but at less mature levels.
That very lower level of maturity is, all by itself, an indication
that there are possible as-yet-unseen issues with the protocol.  The
only test of whether there will be issues is experience.  In new
protocols, that experience is by definition not there.

This is why the argument from the failure of the IDNABIS WG to reach
consensus on a mappings document does not provide the support the
appellant needs for the conclusions.  If a WG cannot reach consensus
on exactly what to do about a given area, that is nowise proof that
one thing, another thing, or indeed anything ought to be the right
answer.  It is instead evidence that we don't know where to go yet,
and so we have to try things out and learn what the best thing to do
is.  The very idea that protocols should spring fully formed in the
RFC repository is completely mistaken.

Ignoring the background material, the rest of the appeal document is
an argument that more work is needed in the IDNA area.  If more work
is needed, then getting the documents out is an important first step,
and not something to be lamented.  So the "more work needed" argument
does not support a conclusion that publication without a disclaimer is
harmful: anything that is a good foundation for additional work
cannot, by definition, be itself bad for the Internet.

Given all of the above, I believe the IESG should reject the appeal.

Best regards,

Andrew

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 11 Mar 2010 11:28:55 -0800

On 3/11/2010 9:16 AM, Andrew Sullivan wrote:
>  As near as I can

Let us consider careful this sentence.

Andrew expended substantial time an energy to read and analyze the appel.  For 
all that, he is still left having to make guesses about the core aspects of the 
appeal's nature.  Andrew has good command of English and is a diligent guy, so 
we cannot dismiss the exercise having been beyond his capabilities or as due to 
his having been sloppy.

Again, I will contend that this is not a reasonable burden for IETF management, 
or the IETF community.  It must be the work of an appellant to place before the 
IETF an appeal that is clear and concise.

That's not an onerous burden.

d/

ps.  Based on the follow-up postings, my note here might be viewed as what sales 
folk call "selling past the sale", but I thought that Andrew's work provided 
remarkable substantiation of the problem that it was worth explicitly noting it 
for the record.

-- 

   Dave Crocker

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Mar 2010 09:02:53 +1300

Andrew,

Thankyou for spending time on this.

On 2010-03-12 06:16, Andrew Sullivan wrote:
...
> It is instead an appeal that the documents were not published with

Interesting. Since we're being legalistic, all IETF documents carry
the standard disclaimer (by reference in recent RFCs) which says,
among other things:

... DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

That seems to cover most angles. I can't see why the IESG could be
expected to add technical disclaimers to a consensus document. In fact,
doing so would probably be a process violation in itself.

    Brian

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 11 Mar 2010 15:28:27 -0500

> doing so would probably be a process violation in itself.

Well, ok, and yes it probably would be a violation.  But to defend the
appelant, there might be a serious (though in my view totally wrong)
point in the appeal.

I'm extremely uncomfortable speculating about what M. Morfin really
means (yes, I am entering that in the understatement of the year
competition), but I think his substantive point is that the IDNA2008
use doesn't provide regular, non-technical Internet users with a
complete, totally functional, rich experience that is unsurprising to
them given their regular language.  I think the point about
disclaimers is that he thinks the publication premature, given that it
can't provide that experience.  So the documents should come with a
warning that more work is to be done.  That's more specific than the
general and standard disclaimer.

As I argued previously, such a view gets almost completely wrong the
way the IETF standards process works.  If that were the bar we had to
jump, nothing would ever go out without such a warning.  Soon we'd be
plastering our RFCs with warnings about the hot drink inside, and so
on.  Maybe we'd even have to warn people about the possibility of
cookies causing complaints on mailing lists.  One almost anticipates
the day when each addition to the RFC series is actually just new
boilerplate, and nothing else.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 11 Mar 2010 15:58:04 -0500

>>>>> "Andrew" == Andrew Sullivan <[email-masked]> writes:

    Andrew> On Fri, Mar 12, 2010 at 09:02:53AM +1300, Brian E Carpenter wrote:
    >> That seems to cover most angles. I can't see why the IESG could
    >> be expected to add technical disclaimers to a consensus
    >> document. In fact, doing so would probably be a process violation
    >> in itself.

    Andrew> Well, ok, and yes it probably would be a violation.  But to
    Andrew> defend the appelant, there might be a serious (though in my
    Andrew> view totally wrong) point in the appeal.

For what it's worth, I think it is entirely reasonable for the IESG to
add text raising technical concerns to a consensus document.  The IESG
note, unlike the rest of the document reflects IESG consensus, even in
cases where the document is intended to reflect IETF consensus.

Here's a case where I think it would be entirely appropriate for the
IESG to do so.  The current process--both internal IESG procedure and
RFC 2026 requires some level of agreement from the IESG to publish a
document.  If we had a case where it was clear that there was strong
community support for something that the IESG had serious concerns
about, I think it would be far bettor for the IESG to include its
concerns in an IESG note than to trigger a governance problem by
declining the document.  Another option also open to the IESG would be
to write up its concerns in an informational document published later.
Without knowledge of specifics I cannot comment on which I'd favor.

I have not read the current appeal and doubt that adding an IESG note is
the right solution to an appeal on technical grounds about a consensus
document.  I simply don't want a legitimate case where adding an IESG
note to come up years later and people dig through this discussion and
find no objections to the claim that adding such a note would be a
process violation.

--Sam

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Mar 2010 10:18:18 +1300

I agree with Sam, for cases which would otherwise result in an
endless DISCUSS - although normally I'd expect the argument
to be complex enough that a separate RFC would be needed to
explain the dissent.

    Brian

---

From: Douglas Otis <[email-masked]>
Date: Thu, 11 Mar 2010 17:02:04 -0800

> to be complex enough that a separate RFC would be needed to
Brian,

Review the extensive defenses needed to guard against exploits and 
problems due to naming uncertainty.  A document emphasizing these 
concerns might prove productive at instilling early action.

-Doug

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 14 Mar 2010 14:08:03 -0400

I agree with Sam that it might be a sensible modification of the existing
process.

However, it is irrelevant to the current discussion since the IESG is not at
current permitted to make such a statement.

The main argument against modification might well be the very fact that it
would allow appeals of this type.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 15 Mar 2010 09:48:34 -0400

>From RFC 2026

" At all stages of the appeals process, the individuals or bodies
   responsible for making the decisions have the discretion to define
   the specific procedures they will follow in the process of making
   their decision."

Suggest that before anyone suggests modifying process they consider
the fact that the reason we have an appeals process is to be able to
obtain insurance. There are good reasons to tie the IESG hands at
certain points in the process.

Endless DISCUSS is not permitted by RFC 2026: The IESG is required to
deliver a timely decision. If one IESG member was using DISCUSS as a
filibuster the process document makes clear that it is the IESG rules
that have to bend to meet the requirements of the process document.

On Thu, Mar 11, 2010 at 5:18 PM, Brian E Carpenter
<[email-masked]> wrote:
> >     >> That seems to cover most angles. I can't see why the IESG could
> >     >> be expected to add technical disclaimers to a consensus
> >     >> document. In fact, doing so would probably be a process violation
> >     >> in itself.
> >