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

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 world, 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. As 
long as the Internet stays with its 1984 DNS, its 1983 IPv4, and its 
interoperability problems with the InterNAT we will not be able to 
progress in common.

What is the external interoperability of the mono-Internet or what is 
the extended nature of the internal interoperability of the 
Multi-Internet? I do not have any engineering problem with that. But 
as John Klensin explained to Todd, my solution is my decision not a 
concerted standard.

Cheers.
jfc