David Conrad <drc@xxxxxxxxxxxxxxx> 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf