Re: Last Call: 'Procedures for protocol extensions and variations' to BCP (draft-carpenter-protocol-extensions)

[Jefsey_Morfin <jefsey at jefsey.com>]

At 15:30 06/09/2006, Sam Hartman wrote:
>     Jefsey> - either you consider the Internet as Harald Alvestrand
>     Jefsey> considers it in RFC 3935: something the IETF leaders
>     Jefsey> influence the building along their values. This vision is
>     Jefsey> OK with me as long as this Internet is one system among
>     Jefsey> others. Ex. TCP/IP vs. OSI. You can decide to constrain it
>     Jefsey> to force the inner interoperability its unique governance
>     Jefsey> wants. As does Harald with languages and you would with
>     Jefsey> HTTP. Every time you give an URL you are to reach the same
>     Jefsey> site. As also the IGF still considers the things: every
>     Jefsey> time you give an URL you hope you reach the same site.
>
>     Jefsey> - or you consider the digital system as it is: a living
>     Jefsey> global mess with many technologies, bugs, conflicts, etc.,
>     Jefsey> with its own ecology (the way it usually reacts to
>     Jefsey> something). Every time you give an URL you do not know if
>     Jefsey> you will reach the same site. So you organise yourself to
>     Jefsey> preserve and develop interoperability and increase your
>     Jefsey> chances, depending on your contexts.
> [Apologies to Harald.  I realize you don't run the Internet any more
> and realize I'm taking your name in veighn:-)]
>
> I want something in the middle.
>
> If I fully embrace your vision, I end up with something far more
> complicated than is necessary, although I will admit that it has
> significant intellectual appeal.  There's actually a lot of
> interesting science fiction written about network models similar to
> what you are looking at.  I'm not intending to be pejorative by saying
> that people are writing science fiction about it.  However I don't
> think we understand how to engineer a network like that today and
> think that if we tried to design such a network we'd make a mess.

Dear Sam,
the error you make is "how to engineer". This were the Harald's RFC 
3935 error is. The world is not engineered. It is by itself. What you 
engineer are ways to make the best of it.

> However, if we try and design the Internet that you think harald wants
> but we do so with our eyes open, I think we can get somewhere in the
> middle, somewhere that balances complexity against functionality.  We
> use the ecological forces.  As we see specific problems that people
> actually want to solve, we make changes to Harald's Internet to solve
> them.

Don't confuse me. I do not say that Harald wants to design the 
Internet one way or another or that there is an Harald's wrong 
internet. But that he thinks that the Internet can be engineered. RFC 
3935 is about the mission of the IETF. The error is "the IESG is to 
influence the way people design, use and manage the Internet". All 
the rest is fine. The problem is in the confusion about what he calls 
the Internet.

For thousands of years we believed in Ptolemee's model. It gave a lot 
of rewards, including the correct distance between the earth and sun. 
And many roosters that beleived they rose the sun every morning, in 
different religions, stories, etc.

It is just that by essence a model cannot scale.

> We try to be moderately ecologically focused in our thinking.
> For example, when we see NAT issues in one network management
> application, we ask ourselves whether the same problem will pop up
> elsewhere (Hi, Eliot).  We make sure that things are extensible so
> that we can change them.

:-) yes in a pragmatic way. Not in a cartesian way. You make things 
extensible (so you have scalability limits). I try to make them 
intelligible (to understand the nature of the solution when the same 
problem diversify somewhere else). Induction and deduction.

> I understand you're trying to get us to do this.  I think though, you
> are too forward thinking and your work is not motivated enough by
> specific real-world problems.

I am afraid this is exactly the opposite.
I will tell you a simple think: I make my personal living for 20 
years this year of that too forward thinking. I agree that it is not 
that easy as I five years in advance on the market and the market is 
5 years late on itself. But we are now at a time where we could sell 
for $ 250 at the supermarket what I sold $ 250.000 to Monopolies. 
Look at the last ASUS wifi box.

From my point of view you are accumulating unnecessary problems. We 
are in real wFrom ietf-bounces at ietf.org Wed Sep 06 13:19:16 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GL11S-0006DQ-0i; Wed, 06 Sep 2006 13:17:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GL11Q-0006BM-Qm
	for ietf at ietf.org; Wed, 06 Sep 2006 13:17:08 -0400
Received: from montage.altserver.com ([63.247.74.122])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL11M-0006Hz-IE
	for ietf at ietf.org; Wed, 06 Sep 2006 13:17:08 -0400
Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=asus)
	by montage.altserver.com with esmtpa (Exim 4.52) id 1GL11G-0000BX-OY
	for ietf at ietf.org; Wed, 06 Sep 2006 10:16:59 -0700
Message-Id: <7.0.1.0.2.20060906183256.0368beb0 at jefsey.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Wed, 06 Sep 2006 18:39:31 +0200
To: Keith Moore <moore at cs.utk.edu>,Robert Sayre <sayrer at gmail.com>
From: Jefsey_Morfin <jefsey at jefsey.com>
In-Reply-To: <44FEEACC.5060904 at cs.utk.edu>
References: <E1GAXNg-0008BD-5D at stiedprstage1.ietf.org>
	<tslzmde1awe.fsf at cz.mit.edu>
	<68fba5c50609051139t1eee6df3ye2e3901c4963d9f5 at mail.gmail.com>
	<tsld5aa140e.fsf at cz.mit.edu>
	<7.0.1.0.2.20060905225317.03f5b008 at jefsey.com>
	<tslejupzm5o.fsf at cz.mit.edu>
	<68fba5c50609052258r588269e1wa0b6d02cb19e444 at mail.gmail.com>
	<44FEEACC.5060904 at cs.utk.edu>
MIME-Version: 1.0
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage.altserver.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Spam-Score: 3.8 (+++)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Cc: Sam Hartman <hartmans-ietf at mit.edu>, ietf at ietf.org
Subject: Re: Last Call: 'Procedures for protocol extensions and
variations' to BCP (draft-carpenter-protocol-extensions)
X-BeenThere: ietf at ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1175222770=="
Errors-To: ietf-bounces at ietf.org

--===============1175222770==
Content-Type: multipart/alternative;
	boundary="----MTxagxraeekkdantogwbmbjrfunkbzebbc"

------MTxagxraeekkdantogwbmbjrfunkbzebbc
Content-Type: text/plain; charset=us-ascii; format=flowed;
	x-avg-checked=avg-ok-250BA0D

At 17:35 06/09/2006, Keith Moore wrote:
> If the web were split across several networks with dissimilar 
> characteristics, it would be much more difficult to arrange seamless 
> access via proxies.

The "if" is the reality. Forgetting about it does simplifies things. 
This is like computing the trajectory of a rocket in using scientif 
formulas without corrections. Simpler, but you miss the target.

Ask the Chinese people if it was as seamless for them as for you to 
access the Internet in your mother tongue. Now it is, because they 
split their extenet from yours, in a way which works and hurts no 
one. But it was more difficult. What is poor is that such a way 
should have been first documented by the IETF, based upon an IAB 
guidance. So we could have an optimal, or common solution. Like in 
the HTTP.1.1 case.
jfc




------MTxagxraeekkdantogwbmbjrfunkbzebbc
Content-Type: text/html

<html>
<head>
</head>
<body>
At 17:35 06/09/2006, Keith Moore wrote:<br />
&gt;If the web were split across several networks with dissimilar <br />
&gt;characteristics, it would be much more difficult to arrange seamless <br />
&gt;access via proxies.<br />
<br />
The &#34;if&#34; is the reality. Forgetting about it does simplifies things. <br />
This is like computing the trajectory of a rocket in using sciorld, so we are to process by abduction. Not by 
decision. Eïstein produced a formula, he did not decide the way 
energy should behave from now on.

> Let's take your language tags work.  If
> you had come to us with a specific application that was well enough
> thought out that we could understand how it works even with users
> menting their own languages, we would have considered your needs more
> seriously.

For you to steal it?
Actually I loyally starded and was rebuked. So, ...
Addison Phillips phrased it in a simpler way: come with a solution 
and that the better win (not much a standardisation attitude). Coming 
with one solution when we belong to an emerging industry they want to 
strangle. We just wanted them not to win. And we succeeded.
:-)
I am in competition with Unicode. You do not want to accept it, but 
they do know it. They use the IESG to impose something blocking their 
competition, of which I am a small part. As probably the most R&D 
advanced and the quickest to respond being a light structure, I was 
the one who volunteered when I understood what some others were ready 
to undertake. Our competition want to make billions on our prospects 
and spoil our whole economy.

This is where the layer violation is. You are at "application" layer, 
I am at "architectural" layer. In wanting to mix them, you are 
building castles on the sand. Let understand this first, then let 
find where there is rock, then build an interoperable distributed 
system with deep foundations.

This is why the Internet is blocked. RFC 1958 is great but it is a 
recipe book. We dearly miss a model to support development whatever 
it can be (NGN, GENI, etc.). Not an invented or decided model of the 
Internet. An observed model of the real world digital ecosystem. I 
use and keep validating one for 22 years. It suits me. Work out your 
own, I am sure you can. Then we can talk.

The problem with the langtags was that WG-LTRU missed an IAB RFC to 
provide them with architectural guidance (like in the OPES case), and 
that they even refused to consider their own charter. And the 
implications of what was missing meant.

So they developped a small application. Good. Claiming it was 
univesal, only introduces confusion.

> But as your problem was presented, it was very much a pure research 
> problem not an engineering problem.

You can qualify it the way you want. All I know it is in tune with 
standardizers, users, politics, our needs, and demand wherever I go. 
But I agree their degree of maturity is not the degree of maturity 
of  the intended proposition of the "stakeholders" (cf. RFC 3869).

> This is the IETF not the IRTF and so we will make the valid 
> engineering decision to limit complexity rather than enable research.

Let put it another simple way. You use engineering to impose 
commercial decisions which seem reasonable for your evaluation of 
your market stable corporate oriented economy. And ... I do the same. 
The difference is that my market is more diversified and my economy 
has a different user centric stability algorithm. I only expect from 
it a technological advance. Not sure I why I should give it away :-)

Now, please note that (too keep with the langtag example), IESG look 
IRTF to me. In october alone I have three major "how to" meetings. 
RFC 3066 Bis would be OK, should the IESG respect it. Brian had said 
the ltru-matching would be answered quickly, and I hope it is as well 
answered as the RFC 3066 Bis appeal. This would conclude this 
harassing saga: it was not in order to convince Unicode of anything, 
but to avoid they use the IETF and the IANA against us.

The IETF should not be the place for that kind of strategic 
conflicts. Once the IESG respects RFC 3066 Bis, we will all be able 
to forget the attempt and to patch the interoperability issues.

This being said, your problem today is the intrinsic nature of 
interoperability scaling engineering. To come with a clear and simple 
definition of it is a sine qua non condition for the Internet to 
develop. I am quite glad you eventually rose the issue with Brian. Asentif <br />
formulas without corrections. Simpler, but you miss the target.<br />
<br />
Ask the Chinese people if it was as seamless for them as for you to <br />
access the Internet in your mother tongue. Now it is, because they <br />
split their extenet from yours, in a way which works and hurts no <br />
one. But it was more difficult. What is poor is that such a way <br />
should have been first documented by the IETF, based upon an IAB <br />
guidance. So we could have an optimal, or common solution. Like in <br />
the HTTP.1.1 case.<br />
jfc<br />
<br />
<br />
<br />

<img src="http://i.msgtag.com/al/rmy/oiu/ogldgfBaEz/rcApan/fd/waamAg.gif"; alt=" " border="0" id="MSGTAGImage"/></body>
</html>

------MTxagxraeekkdantogwbmbjrfunkbzebbc--


--===============1175222770==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============1175222770==--