Subject: Appeals, post-appeal discussions, DoS attacks on the IETF, and the depth of turtles

From: John C Klensin <[email-masked]>
Date: Sat, 22 Jul 2006 10:41:12 -0400

Hi.

I had hoped to stay out of this one, but the volume has risen to
a level...

It seems to me that some major and important principles are
being lost in the noise, so let me suggest a different point of
view.  The following is, obviously, just my opinion.

Appeals, in the IETF, are not a judicial procedure.  They are a
mechanism for encouraging/ forcing another look, or a broader
look, at a decision.  We have appeals to the IESG about IESG
actions precisely because the function of such an appeal is to
say "you may not have understood the issues correctly, please
take another look, considering these issues in particular" and
not "please judge this behavior".

While there is no requirement to do so, an appeal that asks the
IESG to review one of its decisions, or a decision or action by
one of its members that has not been resolved by discussion with
that member, should probably be made public by the person
initiating the appeal if there is any reason to believe that
community discussion will help inform the IESG review and
reconsideration.

At least IMO, the correct action if members of the community
believe that an IESG member is persistently misbehaving or
acting against community interest is not a series of appeals
from individual actions, but, depending on timing and urgency,
discussions with the relevant Nomcom or a recall procedure.   If
those mechanisms are ineffectual, then we need to concentrate on
fixing them, not on trying to retune or recast the appeals
procedures to compensate for the problems with Nomcom or recall
procedures (see Note 1, below).

One major difficulty with the appeal procedure --or any
reconsideration procedure-- is that, if it is used outside the
model of cooperatively initiating a second look at a decision
and in the spirit of making the IETF produce better results
within its general framework, it can easily become an avenue for
DoS attacks on the IETF process.  We have learned in recent
weeks that this is particularly problematic when the intent of
the IESG (or other) action was to block a denial of service
attack on the IETF or one of its WGs or other activities.  If
that action can be appealed, and the decision to uphold the
action can be appealed, and the mechanisms used to make those
decisions can be appealed, we have what Ted described as a
"turtles all the way down" situation.  In such a situation, the
appeals, and discussions of the appeals, can become a more
effective mechanism for denial of service (or just drowning the
IETF mailing list in noise) than the original (actual or
alleged) abuse.

It seems to me that, if an appeal involves an action connected
to a claimed denial of service attack on the IETF (with mailing
list abuse being the primary example) we need a procedural model
that bars the appellant from initiating (or even participating
in) a post-decision reprise on the IETF list, especially if
there is also an intention to initiate an appeal of that
decision.  We've also got to figure out how to prevent multiple,
or layered, appeals resulting from the same action or decision
or appeals about it.

It also seems to me that we need to bar, or at least seriously
constrain, discussions that try to evaluate or complain about
appeal actions by assuming they are judicial processes and then
building arguments about the behavior of such processes.  If
appellants really want a judicial process, let them go off an
try to find judges of competent authority they can convince:
none of our appeal (or review) mechanisms are ever going to be
appropriate under those models and attacking them because they
are not is, itself, either a denial of service attack or, at
least, a situation in which the noise far outweighs the signal.

While I personally believe that it shares some inappropriate
assumptions with the way RFC 2026 is sometimes read and that it
may not have the proper balance of protections for the
community, I commend draft-carpenter-ietf-disputes-00 as an
attempt to rethink this area.  People who are interested in this
topic should probably study it.

      john

Note 1: They may or may not be the right answers, but I've made
some proposals in this area.  draft-klensin-recall-rev-00 (long
expired) was intended to make it easier for the IAB or IESG to
identify problems in their own environment that were linked to
individuals and initiate a community process to solve them.  And
draft-klensin-chair-empowerment-01 is intended to permit the
IETF Chair to initiate specific, and faster-track, action if a
problem within the IESG gets out of hand.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: JFC Morfin <[email-masked]>
Date: Sat, 22 Jul 2006 21:05:10 +0200

Dear John,
I see at least five different topics discussed in one single thread.

1. there are two different debates. The debate confuses my case and 
the need to better manage the IETF conflict resolution system. I have 
tried to differentiate what belongs to what and to help taking 
advantage from my experience for the general good. But I certainly 
follow my own pragmatic strategy. This mail is an attempt to help.

2. the qualification of the conflict. My case is typical: I am 
accused to have disrupted the consensus effort. I have actually 
obtained the consensus I was denied, with the appeal responses I 
wanted. The conflict was therefore not an RFC 3863 conflict. It was 
up to the Chairs, to the AD, and to the IESG to correctly requalify 
it. I thought Brian would do it. May be he had not the authority or the desire?

3. the particular nature of my own position. I always made clear I 
carried IETF deliverable user QA, not being a "co-designer" but an 
external system designer only wanting to help, obtain, or preserve 
interoperability with non IETF solutions like mine. As such, I 
obviously object to the RFC 3935 defined IETF mission "to influence 
the way people [me in this case] design, use and manage the Internet" 
and its resulting effort of exclusion and DoS of what is perceived as 
a technical "competition" of mine.

4. the different types of conflict. This is the most important point 
for the IETF common process. The IETF needs to address at least three 
different kinds of conflict for a single solution.

4.1. technical conflicts. These conflicts can result from a mistake, 
or from external interferences. The IESG's target should be to avoid 
the errors and to protect the IETF from external short terms or 
unilateral interests. The two main sources of these problems have 
been clearly identified as "affinity groups" (RFC 3774) and 
"commercial R&D funding" (IAB RFC 3869).

4.2. personal issues. The IETF is a human group where there can be ad 
hominem conflicts, attitudes, or deliberate actions. I disagree that 
they should be carried through external judicial process. For three 
reasons I experienced: (a) the IETF is not organized to take the 
outcome into account  (b) a judicial process may involve the IETF if 
it is claimed it fostered the ad hominems (c) IETF participants have 
not been educated of the resulting risks. Instead the IETF should 
organize itself to mechanically prevent defamation. IMHO the error is 
the RFC 3863  public LC and the lack of balanced risk for the 
plaintiff in case of DoSing an opponent.

4.3. IANA registries. The IETF RFC 3935 "influence" is limited by the 
market adhesion to its standards. In the case of IANA registries 
there is no market alternative [we saw that in the alt-root case]. 
The control of a IANA registry can therefore be strategic. Until now 
the IANA had three main areas: numbers, names, protocol parameters. 
The numbers/names are pure Internet issues but were considered 
sensible enough to be delegated to ICANN. The new area of languages 
is not an Internet issue, is far more important and sensible than 
names and numbers, and is de facto [this is what I object] delegated 
to UNICODE. The IETF is obviously not prepared to this kind of 
fundamental conflict.

5. IETF strategy. There are cases where a possible solution is a 
significant change of the IETF, or even to kill the IETF itself. The 
conflict I am engaged into, is certainly of that nature. RFC 3935 
gives "IETF leaders" the capacity to address such situations, except 
when the opposed option is defended by one/several IETF leaders. We 
should not consider that such conflicts are exceptional: the lack of 
architectural guidance by the IAB raises several other issues. After 
the Multilingual Internet, what about the multilateral, the 
multitechnology, etc. support?

Ad hominem rules. It is always advisable to take advantage from 
experience, but it is always unadvisable to build rules in 
considering one single case. And doing that to reduce the normal 
appeal mechanism which is part of the normal process. The only direct 
effect of my PR-defamaction was to permit my ban from a list I had 
left and from a list where I had sent my last mail. However, the 
indirect effect is to maintain a temporary situation [the RFC 3066 
Bis had addressed] to prevent me to participate to the IANA Language 
Registries review process (and obtain interoperability with "my" 
system in sensible areas). This kind of ad hominem ruling absurdly 
perpetuates a contention point which hurts the IETF/IESG/IANA image 
and credibility, and I can so easily dispute or overcome.

jfc

---

From: JFC Morfin <[email-masked]>
Date: Sun, 23 Jul 2006 01:59:14 +0200

At 16:41 22/07/2006, John C Klensin wrote:
>We have appeals to the IESG about IESG
>take another look, considering these issues in particular"

Dear John,
you miss an important role of the appeal IMHO. The possibility to get 
a documented position from the IETF on a point a WG process refused 
to address. To protest that a point has not been addressed is unfair 
if it has not been appealed - even if one known the answer. Users 
will not know.

As far as I am concerned the most important contributions in the case 
of RFC 3066 Bis were made by the IESG. To permit interoperability the 
need was not to change the document but to get clear IETF positions. 
I obtained many clarifications in the document itself, against my 
propositions. The appealed points and their responses (for RFC 3066 
Bis and the Draft in filtering) were/are necessary to the 
http://bcp47.com which will document how to use the BCP from the 
Multilingual Internet.

This should result in an I-D. I documented this a long ago. I do not 
consider this as obstruction, but as normal, fair, and positive 
Internet standard process application. This is what is DoSed: I fully 
understand that this may irritate some who preferred a certain 
confusion degree. However, if a BCP purposely does not document all 
the existing practices the market may chose from, this must be 
seriously and authoritatively documented. This authority can only 
come from the IESG and of the IAB.

jfc

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 24 Jul 2006 07:07:08 +0200

John C Klensin wrote:

> I commend draft-carpenter-ietf-disputes-00 as an attempt to
> rethink this area.  People who are interested in this topic
> should probably study it.

Yes, it's interesting.  With a mandatory "attempt of peaceful
settlement", probably a good idea.  But I won't subscribe to

| Participants in the IETF are deemed to agree to these
| procedures in full and final settlement of such disputes.

Also interesting is "deciding to issue a Last Call cannot be
the subject of the DRP".  That misses the point of a decision
NOT to issue a last call, e.g. whith the known caee of two
mutually exclusive documents.  So that clause is no progress
in relation to 2026, it's only clearer.

Is the "single dispute per topic" okay ?  There can be legit
cases of different disputes per 'topic', if a 'topic' is the
disputed decision.  Again the known example, IMO both appeals
made sense, and addressed different technical 'topics'.  They
also got different decisions.

Otherwise the draft is clearer than the related points in 2026.

> draft-klensin-recall-rev-00 (long expired) was intended to
> make it easier for the IAB or IESG to identify problems in
> their own environment that were linked to individuals and
> initiate a community process to solve them.

s/community/Nomcom eligible/ - the recall stuff is restricted
to the paying members.

> draft-klensin-chair-empowerment-01

Apparently not yet available, looking into -00:  A duel, good
idea.  Add an enforced delay, a week or so, it's too easy to
do something stupid.

Frank

---

From: John C Klensin <[email-masked]>
Date: Mon, 24 Jul 2006 01:46:46 -0400

> | procedures in full and final settlement of such disputes.

Yes, that one bothered me too, perhaps for different reasons and
perhaps not.  From my point of view, there has to be an
opportunity for a more judicial/ legalistic process somewhere.
If we want to see appeals as part of a cooperative, potentially
multi-step, reconsideration model, then it becomes even more
important to move the judicial proceedings elsewhere.  And
trying to ban them simply won't work, although I would predict
that someone who resulted to the courts and lost would find him
or herself rather throughly shunned in the IETF thereafter...
not as a matter of procedure or rule, but as a matter of
predictable human behavior and reactions.

> in relation to 2026, it's only clearer.

I tend to agree on this too, or at least I think I do.  I don't
see it as desirable to permit appeals on the decision to issue a
Last Call, since I believe that the IESG should be able to Last
Call substantially anything to get clear community input.  But I
believe that, in general, if an AD, or the IESG, as a whole, is
asked to issue a Last Call and declines to do so, that decision
should be subject to appeal.   And, if the IESG wants to see
that "in general" narrowed --as I think it should be-- then they
should be generating, or convincing someone else to generate-- a
clear statement about the conditions under which Last Calls will
and will not be issued and get community consensus behind that
statement.

>...

There are two issues in this.  The first is that we have active
participants (and contributors) in the IETF who do not attend
meetings.  There were good reasons to exclude them from Nomcoms,
but it is less clear that they should be excluded from recall
activities... Except that it is hard to identify them in a clear
way and that, rather than "paying" was an important reason for
the Nomcom criterion

The second and far more important, IMO, is that, at present,
members of the IAB and IESG --who "pay" with not only
registration fees but with considerable time devoted to the IETF
-- cannot participate in requesting a recall because they cannot
serve on Nomcoms.  Their exclusion from Nomcoms was intended to
prevent a number of obvious possible abuses, but it is not clear
that the same principles apply to recall petitions.  My own
belief is that, when the "Nomcom eligible" rule was applied to
recalls, the IAB and IESG members were excluded as an unintended
side-effect.  Certainly I recall no community discussion about
whether that exclusion was wise and/or necessary.  What that
draft proposed was eliminating the restriction.

> idea.  Add an enforced delay, a week or so, it's too easy to

A delay would probably be a good idea, but I don't see an
obvious way to start the timer.  I suppose the Chair could
propose that action to the Nomcom Chair and the Nomcom Chair
could wait a week before doing anything, then ask the Chair if
he or she was still serious and notify the relevant IESG member
to see if any other action was likely to be forthcoming before
presenting the question to the Nomcom.  Is that what you had in
mind?

    john

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 24 Jul 2006 10:26:24 +0200

John C Klensin wrote:

 [DRP excl. last calls]
> in general, if an AD, or the IESG, as a whole, is asked to
> issue a Last Call and declines to do so, that decision
> that "in general" narrowed --as I think it should be-- then
> they should be generating, or convincing someone else to
> generate-- a clear statement about the conditions under which
> Last Calls will and will not be issued and get community
> consensus behind that statement.

Yes, they need something against bogus (or malicious) last call
requests.  That something would have the same DoS protection as
the proposed 'dispute resolution process'.

 [active participants for the recall procedure]
> it is hard to identify them in a clear way
 [...]
> IAB and IESG members were excluded as an unintended side-
> effect.

Maybe - if you intend to revive that draft -  you could add all
(co-) authors of "n" or more standards track documents, for an
"n" covering all past and present IAB and IESG members.

 [duel draft]
> the Nomcom Chair could wait a week before doing anything,
> then ask the Chair if he or she was still serious and notify
> the relevant IESG member to see if any other action was
> likely to be forthcoming before presenting the question to
> the Nomcom.  Is that what you had in mind?

Yes, maybe as explicit right.  If the IETF or IESG Chair added
Cc: [email-masked] or similar it's hopeless, no further delay,
they have to shoot it out.

Frank

---

From: Martin Duerst <[email-masked]>
Date: Mon, 24 Jul 2006 18:17:56 +0900

At 04:05 06/07/23, JFC Morfin wrote:

>4.3. IANA registries.  ....  In the case of IANA registries there is no market alternative [we saw that in the alt-root case]. The control of a IANA registry can therefore be strategic. Until now the IANA had three main areas: numbers, names, protocol parameters. The numbers/names are pure Internet issues but were considered sensible enough to be delegated to ICANN. The new area of languages

This is not a new area. IANA has managed a language tag registry
since around 1995 (see RFC 1766). But it is important to note that
IANA just registers language tags (or since recently, language
subtags), not languages. 

>is not an Internet issue,

RFC 1766, RFC 3066, as well as its approved successors
(draft-ietf-ltru-registry, draft-ietf-ltru-initial and
draft-ietf-ltru-matching) only deal with language tags
on the Internet. It is difficult to understand how language
tagging on the Internet would not be an Internet issue.

>is far more important and sensible than names and numbers,

I wouldn't be co-chair of the LTRU WG if I wouldn't believe
that language tagging is important, but there are far more
important issues (it's e.g. easy to show that 'charset'
tagging is much more important than language tagging,
because the consequences of failures are much greater).

Also, I agree that language tagging occasionally can be
a sensible issue (a look at the [email-masked]
mailing list would definitely give that impression), but
by and large, most language tags are used in practice
without any problems.

>and is de facto [this is what I object] delegated to UNICODE.

It's difficult to object to something that isn't the case.
The language subtag registry is de facto delegated to ISO
(for language codes, country codes, and script codes) because
the IANA registry (except for blunders by ISO that we hope
they won't make anymore) just reflects the relevant ISO
standards. Of the above three kinds of codes, language codes
are obviously the most important (no language tag without a
language code), and script codes are the least important
(most language tags don't need a script code). The Unicode
consortium is designated as the for registration authority
for script codes. But this doesn't mean that they can assign
new script codes at will; ISO 15924 (see e.g.
http://www.unicode.org/iso15924/standard/) describes that
new codes need at least four positive votes from the six
voting members of the Joint Advisory Committee. Only one of
these members is from the Registration Authority (Unicode),
all the others are from other, ISO-related, organizations.

>The IETF is obviously not prepared to this kind of fundamental conflict.

In order to talk about whether the IETF is prepared for a certain
kind of conflict, we first would need to know what kind of conflict
this is. But I can't find any fundamental conflict in the paragraph
above.

>5. IETF strategy. There are cases where a possible solution is a significant change of the IETF, or even to kill the IETF itself. The conflict I am engaged into, is certainly of that nature. RFC 3935 gives "IETF leaders" the capacity to address such situations, except when the opposed option is defended by one/several IETF leaders. We should not consider that such conflicts are exceptional: the lack of architectural guidance by the IAB raises several other issues. After the Multilingual Internet, what about the multilateral, the multitechnology, etc. support?

There are two ways to understand "Multilingual Internet" above.
One is that the Internet is already to the most part multilingual:
There are Web pages in a large number of langugages, emails are sent
around daily in a similar number of languages, and so on, and some
of the remaining issues, mostly in the area of identifiers, are either
on the verge of being fully deployied (IDN) or at least work has started
(internationalized email addresses).

The other way to understand "Multilingual Internet" is that the
"Multilingual Internet" is something completely different from what
we have now, much more multilingual for the end user, or whatever.
But while we have heard much buzzwording about that, we haven't
seen any of that in any actual kind, shape, or form, nor have we
actually been told what it's going to look like, or how it's going
to be better than what we have now (see previous paragraph).
So it's vaporware even by the standards of vaporware.

A similar analysis can be made for "multilateral" and "multitechnology"
above. Of course the Internet is "multilateral", it allows multiple
parties to communicate with each other. Of course it is "multitechnology",
on many levels (from the physical and link layer up to the applications
layer).

Regards,    Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: JFC Morfin <[email-masked]>
Date: Mon, 24 Jul 2006 19:48:03 +0200

Dear Martin,
Thank you for your comment. It makes plain we belong to two different 
worlds. My concern is the interoperability of these two worlds. My 
problem is your difficulty to realise that your world is not the only 
one on earth. Let go through your mail to try to understand why.

At 11:17 24/07/2006, Martin Duerst wrote:
> >4.3. IANA registries.  ....  In the case of IANA registries there 
> is no market alternative [we saw that in the alt-root case]. The 
> control of a IANA registry can therefore be strategic. Until now 

This is both true and untrue. The new language registries subtags and 
extensions have full autonomy in their area, while the former langtag 
registries was not much used (72 entries in 10 years). The capacity 
of the new registry is important (440 languages, 100 scripts, 250 
country codes which can be organised together to build thousands of 
langtags). The capacity of extensions is limitless. Technology will 
reasticly support sociolects and idiolects, meaning billions of tags.

It is also correct to say that the IANA just registers language 
subtags and not languages. This means labels used to build the 
designation of a language. This means that if you cannot tag (name 
with the RFC 3066 Bis format) a language, that language just do not 
exist in the digital system using that tagging. This may no be of 
importance in an obscure local application, this is not the same for 
the whole Internet.

>tagging on the Internet would not be an Internet issue.

Domain Names are an Internet issue. IP addresses also are. Their 
concept originates in the Internet. Languages concepts do not 
originate in the Internet technology. Language Tags permit the 
Internet technology to interface the Language reality. The importance 
of the Internet in the world life make a conflict between the 
Language reality and the Internet Language support a major political, 
societal and economic conflict.

The point is to know who is the master and who is the slave: the man 
or the machine. The IETF or the people. Should the RFC adapt to users 
or users to RFCs. With in background the fact that if people are to 
adapt to RFC, they will have to adapt to the concepts and interests 
of those who wrote the RFC. RFC 3935 answers that point: people are 
to be influenced by the IETF in the way they design, use and manage 
the Internet for the Internet to work better.

I accept that in a technical vision of the world you can think this 
is a good thing. I acknowledge that you may/can want to develop it. 
However, I cannot support you there: I have a significant (quasi 
universal) different vision. I serve the users rather than 
influencing them. Your vision is exclusive and wants to exclude mine 
(we saw it). Mine is to support everyone, including you - this is why 
I needed you to clearly define the way your system is to work.

>because the consequences of failures are much greater).

I am afraid you are trapped by your own conceptions and strategy. 
Language tagging or charsets are technical concepts. Reality is made 
of languages, graphemes, phonemes, etc. people, cultures, history, 
countries, etc. What you discuss here is related to the limitation of 
your concepts. You just tell that Language Tags (which are the IETF 
interface to languages) should consider charsets before scripts.

You may remember that you opposed this I explained.

We both know the reason why Unicode chose ISO 15924 and scripts 
rather than keyboards and charsets. And that reason is not technical. 
I do not share that reasons. I do not use ISO 15924 except for what 
it is: a list of tags you can use to qualify charsets.

>by and large, most language tags are used in practice

This is a ... premature affirmation. Up to now there were 72 IANA 
language tags and a lose usage of ISO 915-1/2.

What is at stake is the e-cataloguing (with the impact resulting from 
the importance of the Internet in the world's life) of what is the 
most sensitive human resource. It affects human identity, cultural 
development, national sovereignty, and more and more is identified as 
probably the most important economic resource/way of influence of the future.

We saw it with the denial of "en-eu" which most probably decided of 
the split between the IETF Internationalized Internet and the IGF 
Multilingual Internet. I am afraid that the practice is not "without 
any problem", it is just that you do not seem to see the problems you create.

>standards.

Dear Martin, we both know that the "blunders by ISO" are when ISO and 
Unicode disagreed and that the "we" you use are the members of 
Unicode. http://www.unicode.org/consortium/memblogo.html - 
http://www.unicode.org/consortium/directors.html .

>Of the above three kinds of codes, language codes

The problem is that you probably co-wrote the Charter of the WG-LTRU 
and did not ask your WG to read it before starting a clean sheet 
work.  We both know that what Unicode brings to the IETF is its 
globalization vision, doctrine, and possible practical management.

I do not object that the IETF delegates its language doctrine, 
strategy, and eventual control to Unicode and to who may be a leader 
in the Unicode consortium. I object that this is done through a 
distortion of the RFC 3066 Bis rules and not as a formal MoU as in 
the ICANN case for numbers and names. It should be clear that the 
IETF follows the Unicode vision or is not limited to the Unicode 
globalization. My appeals to IESG and further on to the IAB are just 
to obtain that answer. So we know how to finalise http://bcp47.org.

>this is. But I can't find any fundamental conflict in the paragraph

My post was related to conflict resolution, not to this conflict in 
particular. This conflict is the effort engaged for the control of 
the IANA. It is mainly perceived in the USA as a "tuning" between 
ICANN and industry stakeholders, where the IANA "new registries" can 
be a trump card for some. It is going to be a fundamental 
architectural issue for the rest of the world between a centralised 
and a distributed approach of the Internet metadata.

The main issue is over IRI-tags, ISO 11179, and the need for the IETF 
to have a multilingual distributed referential/registry system 
doctrine and solution. This is a global architectural evolution.

> significant change of the IETF, or even to kill the IETF itself. 
> The conflict I am engaged into, is certainly of that nature. RFC 
> 3935 gives "IETF leaders" the capacity to address such situations, 
> except when the opposed option is defended by one/several IETF 
> leaders. We should not consider that such conflicts are 
> exceptional: the lack of architectural guidance by the IAB raises 
> several other issues. After the Multilingual Internet, what about 
> the multilateral, the multitechnology, etc. support?
>

It is surprising to see such globalization patches qualified as 
multilingual somethings. IDNs are internationalized domain names and 
certainly are neither multilingual nor on the verge of being fully 
deployed (unless you talk of the Chinese Names?). I would be very 
interested to know where internationalized (not multilingual) LHS is 
presently under discussion.

>So it's vaporware even by the standards of vaporware.

Multilingual Internet is a demand, therefore a specification. It is 
up to you to document they way you intend to support an Internet IETF 
multilingual architecture. It is true that until now the pretence 
that IETF internationalization fits the job and the IAB denial to use 
the word multilingual is vaporware.

I am one of those working on a Multilingual Internet architecture. I 
am not alone :-) . But I am certainly the only one who think that it 
can only be an evolution in usage, and who therefore care about 
immediate interoperability. You just spent two years refusing me that 
interoperability. Actually, I think that this multitechnology, 
multilateral, multinational, etc. interoperability is most of the 
Multilingual Internet.

>on many levels (from the physical and link layer up to the applications

I feel you give the clue. You say "of course the Internet is ...". 
Instead of "how can we help people to make their Internet ...".
Take care.
jfc