Re: [ga] A Root with a view..., etc.

[JFC Morfin <jefsey@xxxxxxxxxxxxxxxx>]

Dear all,
IMHO the contributions from Joe, Stephen and Thomas bring different 
lights on a common problem/challenge we are to accept. The Legacy 
Internet is unable to match the Multilingual and Semantic Internet 
requirements. Based upon experimentation respecting as much as I 
could the ICANN requirements, my evaluation is optimistic but different.
At 20:09 28/11/2007, Joe Baptista wrote:
> Stephane Bortzmeyer wrote:
> > Unless GWB declares that fighting DNS misconfigurations is part of 
> > the "war against terror" and decides to send US Marines to check 
> > BIND configuration everywhere?
> Right now it could be argued that it should be.  It directly affects 
> national infrastructure therefore the whole idea of internet police 
> qualifies.  Alot of DNS software on the net is bad.
> A government serious about national infrastrcuture protection should 
> considering moving in that direction.  And we don't have to send out 
> the marines.  could just be a government body dedicated to closing 
> down security issues proactively - and the dns is one of them.  And 
> now at this point in U.S. history the nation and government is in 
> such a state of national security choas it would be an opportune 
> time to impliment the network police using terrorism as a proxy to 
> speed up passage of enabling legislation.
> regards
> joe baptista
This policy is defined. And applied, at least progressively.
http://whitehouse.gov/pcipb

It results from experience and work that are precious to every other 
country. It also creates the treat you describe: a US digital 
umbrella on the Internet. This is something the WSIS was to protect 
us from. This was achieved by the Tunis deal mainly between David 
Gross for the USA (along a Congress unanimous resolution) and Martin 
Boyle, the UK representative speaking on behalf of Europe.
This deal says that (1) the Legacy Internet is US territoy (2) 
emergent issues are to be resolved through IGF and an 
inter-government enhanced cooperation still to be defined. ICANN and 
USG seem to behave as at this enhanced cooperation was a US digital 
umbrella. This leads the Governments to make the independance of 
their national internet structure a priority. For example the 
ccNSO/GAC approach of IDNs starts looking as an e-NATO and an 
e-commerce (English inside) Registrar based trade globalization. The 
technical confusion between internationalization and 
multilingualisation increases this feeling.
Time has certainly come for a user originated clean sheet clarification.

At 15:57 27/11/2007, Stephane Bortzmeyer wrote:
> On Tue, Nov 27, 2007 at 03:19:32PM +0100,
>  Avri Doria <avri@xxxxxxx> wrote
>  a message of 41 lines which said:
> > True but it can become 'IETF work' by going through a 4 week last
> > call etc..  when it is finally cooked.
>
> My pronostic is that it won't become 'IETF work' but, of course, it 
> is just a personal feeling.
> At the present time, it is *ICANN* work. ICANN promotes it, refers to
> it, uses its terminology ("A-label") instead of the standard one, etc.
>
> Most *individual* Internet-Drafts are never the subject of so much
> attention from a powerful international organization.
You forget the twice LC failed Draft which became FC 4646. We face a 
technically inadequate but consistent Unicode orginated vision. Its 
positive aspect is that at least it is a proposition (IETF has none). 
Its problem in addition to be inadequate is to have to adapt to IDNs 
and also to IRI, mail addresses, etc.
> > So, while not a normal IETF product, it is also not quite a normal
> > independent submission.
>
> Yes, what is *not* normal is that ICANN promotes this work as if it
> were IETF standard.
Correct. Or it confirms that ICANN is biased and not fit for a non-US 
centered job.
> > I think it would be cool to see some substantive discussion on some
> > of the revisions.  do people think it will an improvement?  will it
> > work?
>
> Right, but this is a bit off-topic for this list, no?
If you wish to remember the initial WG-IDNA Charter. It started with 
the need of a market study and the analysis of the user contribution. 
This was never carried. Like for RFC 4646 there is a tendency to 
start from a solution, rather than to consider a problem. This can be 
understood because such a study may show the radical nature of the 
need. However, today we are faced with the radical nature of the delay.
At 02:45 28/11/2007, Thomas Narten wrote:
> > > An informal expert panel, working as what the IETF calls a "design
> > > team,"
>
> IMO, the text here is a bit awkwardly worded because it is talking
> about an IETF nuance that people not familiar with the IETF wouldn't
> appreciate (or probably even care about).
>
> The fact is that the IETF has not chartered a WG to do the IDNAbis
> work. Thus, "officially" or "formally", the IETF isn't doing any work
> here. But that is an extremely narrow, legalistic reading of reality.
Correct. But it also means that there is no IAB/IESG commitment on a 
Multilingual Internet architecture, this means that the Internet is 
designed to interelate american machines, not world's people. I have 
nothing against it, but it means that we must build two new layer's: 
a separation from the English core (the missing presentation layer) 
and one or two linguistic/metalinguistic layers.
> In fact, it is widely understood that IDNAbis is needed. There are
> real problems with the existing RFCs that MUST be fixed. (See RFC
> 4690.)  But rather than charter a formal WG, the IETF leadership opted
> to let the work be done via a more informal "design team" (this is not
> all that unusual of a step). That work has been done openly. There are
> public mailing lists, there have been face-to-face meetings at the
> IETF, etc. At some point (hopefully within the next month or two) the
> team will declare itself "done". At that point, the documents will
> formally go through the IETF as an "Independent Submission" with the
> aim have of having the document set become Standards Track
> protocols. They will go through the normal IETF Last Call, followed by
> an IESG evaluation, and assuming that any issues that arise are worked
> out satisfactorily, the documents will be approved by the IESG and get
> published as RFCs. This is normal IETF process, no magic here.
I am afraid the magic here is that you confuse plural and singular 
and over describe what is going on.
There are to my knowledge, two very low traffic design teams. One by 
Harald Alvestrand, and one by MLTF.
The one you refer to is Harald's. Its orientation is to patch the 
mostly Unicode problems in exising RFCs. It has currently a few mails 
after a long silence.
The MLTF one has a different vision. It considers a generalised 
multilingual and semantic name space. This is not a small topic and a 
transition must be permitted. This is why this effort will result 
into an ICANN ICP-3 conformant test, in a UN/IGF Dynamic Coalition, 
and an independent IETF Draft. For the time being it has produced a 
review of the ICANN quoted texts which has been released for 
appropriate consideration: there is no need to block an IETF error at 
this stage as there was with FC 4646.
> > Be aware that it is *not* IETF work, it is just that: three persons
> > informally gathering to propose things, that's all. It has no official
> > status, the IDNA standard is still RFC 3490, as before. And there is
> > no consensus on the proposed changes.
>
> Your last sentence suggests that there is "no consensus" for the
> changes, i.e., that they are unlikely to become adopted. I hope that
> is not what you are saying, because IDNAbis is needed, and if the work
> done so far isn't adopted, we have a HUGE problem because we won't
> have fixed the known problems with IDNA. (Again, see RFC 4690.)
RFC 4690 does not identifies the main IDNA problems. They are 
architectural. RFC 4690 and current draft analysis show it. Basically 
the problem is the same as the ROAP problem you know well. The 
network was not designed for such a load, such a size, such demands.
> That said, technically, there is "no consensus" for the
> changes. Technically, there is no way to formally measure the degree
> of consensus until the IETF Last Call begins.
A consensus is a consensus. The consensus which counts is the user 
consensus. It increasingly shows that it disfavors the premises of 
the IETF solution.
> But there is a HUGE
> assumption that that IDNAbis will become a Proposed Standard.
> Certainly, all the folk that have been working on it for a year or so
> wouldn't be wasting their time if they thought the effort wasn't going
> to produce an replacement for RFC 3490.
First IDNs started being sold and operationally used 8 years ago. 
They were both better supported and hurt by the WG-IDNA RFC. IDNAbis 
(which still has a _very_ long way to go to match what _you_ and 
_users_ expect from it [I do not think they can]) is an IDNApatch. 
This patch is probably necessary because of the work we did not carry 
"to save time" until we can have a stable, generalised and equal one.
The real problem is to understand what we want to achieve and are 
ready to accept. This is something you IETF guys must say for us to 
say if we are to work together or separately. But remember the one to 
decide of the result will be the TLD, ISP, private system managers.
We know we disagree: this is the same for IDN and ROAP. You think 
that the technology should be better designed to support unforeseen 
challenges. I think the technology is good enough (and has or it 
could not diversify), but the IETF "brainware" (culture, way of 
working, ethics, piorities, etc.) is the problem. There is a need for 
a new multilateral paradigm replacing/completing the current IETF 
unilateral paradigm as expressed in RFC 3935.
Happily, there is no big difficulty applying ICANN ICP-3 for testing, 
except the need of a clear separation between the US legacy 
unilateral operational usage and the International innovative 
multilateral real user testing. There is no magic solutions to make 
it and respect ICP-3, but an addition of acceptable suggestions 
(replacing a unilateral vision by a multilateral one can not be a 
centalised move ...).
jfc