Hi Robin,
Thank you for your note. I'd like to respond to the meta-issues you raise. |The descriptions of these approaches in 3.3.1.x are exceedingly |minimal. I don't know why everything has to be so terse. Internet |drafts are printed on 100% recycled electrons, and I think it is |important to help people - including those outside the RRG - identify |and understand the various possible architectures as clearly as |possible. Unfortunately, length and detail do not create clarity. Instead, they frequently obscure it. The point of having broad, overall descriptions is to first describe the key aspects of the particular segment of the solution space. These create abstractions that we can actually discuss and manipulate in some pragmatic fashion without drowning in implementation detail. Yes, once we have made the key architectural decisions at the uppermost layers of the solution space, then we can and should recurse downwards into more detail, but until then, the details simply serve as noise in conflict with any insights and generalizations that we might have. |The taxonomy should clearly cover every seriously proposed |architecture - and should probably not cover anything else without |noting that such an architecture may be possible, but has not yet |been proposed. I strongly disagree. The point of the taxonomy is to cover as much of the solution space as we can possibly see. Specific proposals are only points in this space and our top-down decision making should have us first try for consensus at the broadest possible levels of abstraction. Regards, Tony _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
