|
Re: Last Call: 'Procedures for protocol extensions and variations' to BCP (draft-carpenter-protocol-extensions)
2006-09-06 10:19:02
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
|
|