David Conrad <drc(_at_)virtualized(_dot_)org> writes:
Do you believe IPv4 (or ANY other successful large scale technology),
when it was designed, had all the little details worked out?
No, of course not. But the analogy is misleading, IMO. When IPv4 was
designed, it was used by a _very_ small set of players and very few
people really depended on it. Making changes was easier. Experimenting
with a "play" system is always easier.
Today, the Internet is part of the world's basic infrastructure. We're
kind of past the point of being able to say "let's just bet the farm
on this, and see if we can work out the open issues later".
As I have said elsewhere, I've come to believe that one of the
fundamental failures of the IETF is that it permits or even
encourages protocol design to be directed by corner cases.
This is sometimes very true. But I disagree that this is the reason
we haven't done an ID/Loc split yet. At the end of the day, we have
yet to see a real design fleshed out in enough detail that folk can
honestly say "yep, I think we can make this work in practice and I
think I understand how the pieces will all fit together". And I'm
talking about _all_ the pieces, not just the 80% that are the easiest
and we know how to do.
In this particular case, it isn't even clear to me there is
agreement on what the problem we're trying to solve actually is.
Yes, this is a key issue (like in so many cases). People are all over
the map in terms of (picking ID/loc as an example), how frequently the
mapping needs to be able to change. Once a week? Every few minutes?
Quickly enough for mobility, etc. These sorts of questions are
critical to answer before focussing too much on solutions.
And we have a place for that work to happen in the IRTF.
Actually, I suspect if the work were to happen in the IRTF, it would
be doomed. The IRTF is, after all, focused on research.
If there is engineering work to do, make the case it is ready for the
IETF. Personally, I think the ID/Loc work is still in that gray area
between engineering and research. Ready for engineering means we know
how to do it, there are no hard problems to still work out. We just
need to agree on a standard way to do something.
On the other hand, if we don't know how to do a scalable mapping part
yet, that sounds like research to me. (Insert long-running discussion
here about how DNS is or is not good enough to provide this
functionality.)
I can imagine the people in the IRTF contributing towards a solution
but that isn't where a solution will come from. Given real world
constraints, a solution will come from engineers (protocol, network,
hardware, and/or software), singly or working together, coming up
with an approach that meets real world requirements (not what
researchers believe are real world requirements). It almost
certainly won't be architecturally pure and it probably won't be
pretty, but it will probably meet commercial and operational needs.
Yep. But I would hope that the research side can do the work that
leads to answering the previous question with an answer of "yep, I
think we know how to this and can make it work and just need to agree
on the bits."
Thomas
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf