Hi Scott, > First, a lot of this is general comments on goal, motivation > and problem statement. This should all be put up at the front, as > context. I would have the order in front be Introduction, then Problem > Statement, then "Proposals" with "Abbreviations" being the first > subsection under that.
I have no problems with that, however, moving up to the front would move it out from underneath the disclaimers at the head of the section. I think that a lot of folks would then have an issue with it. > For each of your justification paragraphs, I think you should have a > summary bullet, e.g. "must be applicable to IPv6", "must be good for the > long term". Would section headings do? >> These are not >> incompatible specifically because we truly intend short-term >> improvements to be completely localized and temporary. As the long- >> term solution is rolled out and gains traction, the short-term >> improvements should be of less benefit and can subsequently be >> withdrawn. > > Ha ha ha. "Incremental" isn't just about new things coming in, it's > about old things going out as well. The text should note that the > short-term tweaks will be with us for a long time, but that they are > necessary steps. When you get down to specifics later, explain why > having the short-term tweaks hang around isn't a terrible problem. You can laugh all you like, but I do suspect that the operational pain of AIS is going to motivate operators to retract it as quickly as possible. Added text as you suggest. > Brian's right, renum-needs-work is not a solution, it's a discussion. I > would mention it in the "Rationale" as something that helps make ILNP > more feasible in the long term, but not up here where you're talking > about "solutions". Already done. >> We recommended ILNP because we find it to be a clean solution for the >> architecture. It separates location from identity in a clear, >> straightforward way that is consistent with the remainder of the >> Internet architecture and makes both first-class citizens. Unlike >> the many map-and-encap proposals, there are no complications due to >> tunneling, indirection, or semantics that shift over the lifetime of >> a packets delivery. > > "Clean" etc. doesn't say much -- you should be less subjective. In what > ways is it cleaner? Why specifically are tunneling and indirection > considered problems? Heh. This dovetails nicely into other conversations that I've been having recently. Unfortunately, architectural complexity seems to be very subjective. Suggestions for text? >> We recommend further work on automating renumbering because even with > > Here's where you mention renum-needs-work as a focal point for this > important effort, but skip the last sentence -- it's unnecessary since > you are no longer presenting it as a solution. ? Brian asked me to add it, now you want me to take it out. > Finally, I recommend a new section: A bulleted list of issues the IETF > needs to consider in order to turn this recommendation into real > engineering for real networks. I think that would help the IETF figure > out what to do with this recommendation. I'll try to contribute to that > next but as you have seen I don't have a lot of time these days. I welcome the text. We should be careful to suggest work that should be done and not how it should be done. > Oh, and I appreciate all the work you're doing. Thanks. Glad someone does. ;-) Tony _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
