Subject: Re: [iucg] Comments on appeal to the IESG concerning the approbation of the IDNA2008 document set.

From: jefsey <[email-masked]>
Date: Thu, 11 Mar 2010 22:07:45 +0100

At 18:16 11/03/2010, Andrew Sullivan wrote:
>To the IESG:
>On Wed, Mar 10, 2010 at 05:43:12PM -0500, Russ Housley wrote:
> > The IESG has received an appeal.  It can be found here:
> > http://www.ietf.org/iesg/appeal/morfin-2010-03-10.pdf
>
>I have read the document,

Dear Andrew,

Thank you for being the first to acknowledge it.

>though I cheerfully concede that some of the text eludes my understanding.

accepted.

This is not a dispute, this is to try to avoid the harm that I might 
cause to the Internet now IDNA2008 gives me the network architecture 
I longed for years.

However please keep in mind that your comments can only bear on what 
you understood.
- either what I say does not make sense in the current Internet, so 
no harm should proceed from it, and disregarding it is no more 
problem than disregarding IPv8.
- or what I say makes sense, and the real harm will precisely result 
from - what you say is your case - the Internet community and IETF 
are not ready for it, not understanding it. This is the matter of the 
appeal. And, due to the matter and the context, disregarding the 
appeal if I am right will affect the Internet far more than NATs.

I am personally neutral on the matter. Show me wrong, and I will 
gladly accept it. However, I am afraid I am not. I am worried, 
nothing else or more. This is why I carefully documented. So no one 
can tell I did not informed the community governance before 
practically engaging in the transition started by IDNA2008.  Please 
note that I will not be alone, but it seems that I am the only one 
thinking that the Internet should still be concerted at the IETF, 
rather than a political tool or a money making machine.

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

Correct.

Dean Anderson spotted a typo due to my computer crash on 9/3 which 
made things crazy. I reported that some other typos could exist and 
will be corrected on the IUCG wiki (so a list can be maintained). The 
text should read:

"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_concerns_the_way_the_IESG has approved this IDNA2008 document set

An appeal is not a controversy. It is a regular form of work towards 
a consensus.

>The bullets following the first sentence seem to support to support my
>interpretation.  I think the bullets are preposterous.

The way you harp on usual cases requests they are preposterous indeed.
The case is unusual because the Working Group Summary reports that 
the entire WG went to an impasse that was only solved through a 
consensual document. That document,

1. underlined the "unusual" character of the _scope_ of the document 
as being outside of the IETF scope
2. conflicts with the IAB current position on the matter, in that it 
permits a user architecture the IAB objects.

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

???
The argument is the opposite. It is that we reached a consensus over 
the Mapping document. Actually twice since the AD wanted to check. 
The argument is that the IESG position is lame. It accepts documents 
(WG Summary) that were only made consensual due to a consensual 
document the IESG does not approve. The appeal is to know where the 
IESG position stands:

- by its own?
- in agreement with IAB?
- in agreement with the WG?

>Second, the appellant claims that the IESG has a
>precautionary duty that makes the disclaimers necessary.

I note that you focus on the two minor bullets. They are important 
only in relation to the two major ones which are that the IDNA 
architecture is lame as long as IDNA2008 has not been completed on 
the user side (and conflicts with IAB), and that IDNA2008 implies 
architectural principles the Internet community is not practically 
ready to receive (for example, the unique virtual root matrix I use on my PC).

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

Correct.

This confirms that appealing the IESG when this judging process is 
not exercised is the right thing to do.

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

This is part of the IESG judging responsibility.

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

Correct.

And this is because I think there is a potentially very significant 
danger of harm at not informing the community that I contributed with 
this appeal.

Coming from you, this comment has a very important weight, because 
what is partly at stake is what I call the ML-DNS, i.e. an extension 
of the way I currently use the DNS on my machines for tests. This way 
permits me to resolve the 25.000 Multilinc preparatory TLDs today and 
exchange mails with my co-testers. It permits me to test .fra. Yet I 
did not write a single line of code. I just wrote and run a script. 
Yet I do not violate any of the RFC suggestions, use no alt-root, 
fully respect the ASCII DNS, I am fast, protected and secure.

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

Correct. Except that we are in a real world. Where national policies, 
international bodies strategies, corporate investment, people's money 
depend on the IDNA2008 credibility as propagated by IESG, IAB and ICANN.

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

Andrew, IDNA2008 is not a new protocol (a new protocol was what i-DNs 
deployed ten years ago, or what we ran with KDD thirty years ago). 
IDNA2008 is supposed to be based upon years of field experience and a 
positive enhancement of IDNA2003. Please, there are millions of IDNs 
in operations today.

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

Moreover, the IDNABIS reached twice a consensus. Last one no later 
than a month ago, at the request of the AD.

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

I am probably very unclear in the document. Its basic premise is that 
IDNA2008 is a superb achievement.

What is not is that the IESG has not measured its real architectural 
impact both on the Internet fundamentals (support of diversity) and 
on the User side architecture (the same user entries can resolve to 
different hosts).

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

I am afraid this is confusing.
- there is NO "more work needed" on the Internet side (IDNA2008), 
i.e. in the IETF scope.
- the work needed is not a "more", but a start on the user side, i.e. 
not on the IETF area, except that Mapping states that in an "unusual" 
manner it is the IETF area. This permits IESG to approve IDNA2008, 
... without documenting what to do in that area (except a list of 
possibilities in the non-approved Mapping document that (without a 
disclaimer) conflicts with the IAB's current position).

This means that someone has to clarify this confusion for us and 
state "where" that work has to be carried. I engaged that work at the 
IUCG. The WG Chair supported the idea, but wanted an I_D to be 
published first on that work (it is currently labelled IDNA2010/2012 
to block ICANN's confusion that an IDNA2010 could change IDNA2008). 
However, I considered I could not publish an I_D prior a published 
position of the IESG and IAB deciding:

- if this works belongs or not to the IETF scope
- if yes which WG is to address the issue
- if not how the IETF unusual involvement out of its territory is 
going to relate with those (probably several ones) taking the work over.

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

No problem.

The appeal is twenty lines long, but actually boils down to one single line:

- "the IESG should have asked IAB first and then decided to include 
the response in a disclaimer or not"
- plus the documentation that I think necessary to decide yes/not on 
a technical, precautionary and scope basis.

So,
- either the IESG reject the appeal and I will ask IAB its position.
- or it considers the appeal and directly ask the IAB's position.

jfc

PS. You added:

>I'm extremely uncomfortable speculating about what M. Morfin really
>means (yes, I am entering that in the understatement of the year
>competition),

This is embarassing for me: how do I report that to people who do 
understand it, and to people who will understand or use it.

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

No. This is not IDNA2008 job. IDNA2008 is to document the way the 
Internet expect things to work so others can build upon it. IDNA2008 
carries that job and is FINAL. Changes would mean to change the 
billions of applications that will use IDNA.

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

No. The publication is awaited for a decade! What is premature is to 
make ICANN believe users can use it. IDNA2008 is not for users, it is 
for the developpers of non-Namprep based applications. These 
developpers have no other guidance as yet than the non-approved 
Mapping documents and the IAB IDN I_D which (seem at least to) conflict.

>That's more specific than the general and standard disclaimer.

Yes. It certainly is.

In addition, it is always interesting to note that IDNA2008 does not 
support properly French and other Latin languages.

jfc

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 12 Mar 2010 15:43:22 -0500

On Thu, Mar 11, 2010 at 10:07:45PM +0100, jefsey wrote:

> The argument is the opposite. It is that we reached a consensus over the 
> Mapping document. Actually twice since the AD wanted to check. The 
> argument is that the IESG position is lame. It accepts documents (WG 
> Summary) that were only made consensual due to a consensual document the 
> IESG does not approve. The appeal is to know where the IESG position 

I'm not going to get into a lengthy exchange of emails with you in
which everyone on the cc: list is copied, but to be perfectly clear:
the IDNABIS WG never was in a position to submit a bunch of documents
and say that they all have to go through together, unless those
documents had normative references to each other.  The mapping
document delivered no protocol, was not aimed at the standards track,
and was not a reference in any other document's normative references
section.  Therefore, the WG _did not_ reach consensus due to a
document of which the IESG did not approve.

> I note that you focus on the two minor bullets. They are important only 
> in relation to the two major ones which are that the IDNA architecture is 

My reading of your submission was that those were not the "minor"
bullets, but actually the major ones because they implied a certain
precedent.  I'm sorry if you think my interpretation is not correct;
but perhaps in future, if you wish to be better understood, you will
spend less labour on covering all the ground even tangentially related
to the topic, and more effort on making crystal clear precisely the
point you're trying to make.  I spent too many years studying academic
philosophy to be stopped short by dense prose.  I nevertheless had to
use every possible principle of charity even to make the sense I did
of your arguments.

> depend on the IDNA2008 credibility as propagated by IESG, IAB and ICANN.

If this is the real root of your complaint, then _go work on those
bodies_, rather than wasting everyone's time with appeals of IETF
work.  The energy -- and time! -- that you wasted on this effort could
better have been spent hammering away at national governments,
international bodies, and so on to get investment in building the
superstructure that has to live atop the protocol that comes from the
IETF.  The IETF is simply the wrong forum in which to solve many of
the problems you're tackling.

> - there is NO "more work needed" on the Internet side (IDNA2008), i.e. in 
> the IETF scope.

Good.  Then we're done.  Let's all of us now stop talking about it.
You can withdraw your appeal, and save anyone else from having to wade
through the opaque prose, irrelevant sidebars, and
more-postmodern-than-thee contextualizing of everything.  If even you
admit that the documents should stand as they are, then let us please
shut up and get on to real work.

> The appeal is twenty lines long, but actually boils down to one single line:

If only!

A

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

---

From: jefsey <[email-masked]>
Date: Sun, 14 Mar 2010 23:04:35 +0100

Dear Andrew,
sorry, I was traveling.

At 21:43 12/03/2010, Andrew Sullivan wrote:
>The mapping

This is not what I read in the WG summary (quoted in the appeal).

Anyway, the point is not here. IDNA2008 provided me with the 
architectural responses that I had been calling twenty years for and 
that RFC 1958 and RFC 3439 only introduced. Either I am fooling 
myself - if so, Davidson, Haraway, or Wittengestein may be of use in 
explaining why - I do not think that they will be of any help for the 
IETF except for maybe John Day, or I am not fooling myself and the 
IESG failed in its duty to make you aware of the architectural 
principles that I believe underlie the IDNA2008 consensual logic. 
This means, the general Internet architectural principles that:
- we used in the case of the support of the human orthotypography of 
the natural linguistic diversity
- that are necessary for IDNA2008 to not conflict with the IAB IDN 
related current position
- that I used for example to send this very mail without changing a 
single bit of the existing technology in an faster and more secure 
DNS environment easily supporting the 25.000 TLDs of the Multilinc 
project, and possibly millions of others,
- may break the Internet operational stability if not properly handled.

My role here is not to substitute myself as the IAB, nor is it to 
oppose what I fought ten years for and eventually obtained, or to 
possibly restrict the possible IDNA2008 implications to only these 
which I perceive. My role is to neutrally provide all the IESG and 
IAB people, who did not fully investigate IDNA2008 prior to approving 
it because of its perfect fitting value, with the possibility to 
investigate it more deeply on their own and for them to decide 
thereby as to what their decision may additionally have brought to 
the Internet, and under which conditions. In turn my role here is to 
protect myself from anyone's protest, who might not be pleased with 
the technology that I (and most probably many others) will deploy as 
accepted through the IETF network development architectural concepts 
of IDNA2008.

If you do not succeed to read this appeal in that perspective, i.e. 
as it was written, I am afraid that you cannot understand anything of 
its true meaning and purposes. However, you will confirm my feeling 
that an help should be provided by the IAB, that should be triggered 
by the IESG.

Best
jfc