overall, I like the document. some comments: > However, while Dave Clark's famous saying > > "We do not believe in kings, presidents, or voting. > We believe only in rough consensus and running code," is this an accurate quote? I've usually seen it written We reject kings, presidents, and voting. We believe in rough consensus and running code. I agree with this form, but not with the way you've stated it. I certainly don't believe "only" in rough consensus and running code - I also believe in explicit definition of goals and requirements, careful design by knowledgable experts, analysis, iterative specification, wide public review, etc. > "The purpose of the IETF is to create high quality, relevant, > and timely standards for the Internet." I actually believe IETF has a somewhat wider purpose than that. What I usually say is "we're trying to help the Internet work better". We do this partially by authoring and maintaining protocol standards, but we use other mechanisms also. In addition to standards, we produce informational and experimental documents and BCPs. We provide formal and informal advice and feedback to various parties about operational practices, implementation practices, efforts by other SDOs, proposed regulations, etc. All of these are relevant to, and consistent with, the purpose of helping the Internet to work better. We *ought* to provide more architectural direction or advice - our failure to resolve architectural issues in advance of deployment of products with conflicting views of the architecture (or in some cases, a simple lack of care or foresight on those vendors' parts) has caused a number of conflicts and operational problems, and has impaired the ability of the Internet to support diverse applications. I also believe that some amount of experimentation (perhaps not all that is being done under IETF's purview) is part of the process of "trying to make the Internet work better" > The IETF > has identified interoperability, security, and scalability as > essential, but without attaching measurements to those > characteristics. that's a start. there are a lot more characteristics than these that should be considered in a design, that we haven't articulated yet, but we need to. > It is important that this is "For the Internet," and does not include > everything that happens to use IP. IP is being used in a myriad of > real-world applications, such as controlling street lights, but the > IETF does not standardize those applications. I disagree with the sentiment as I understand it. I don't think it's realistic anymore to take the view that what people run entirely on private networks is their own business and outside of IETF's purview. NATs, private addresses, and DHCP with short lease times have all had devistating effects on the Internet's ability to support applications. Insecure applications can facilitate the breeding of viruses that affect the entire network even if their intended interactions are only between a local client and server. We do have to limit our scope. We don't have the ability to scale to the point where we could standardize everything that uses IP, and it would be silly of us to try to claim authority to do so. But it might be reasonable for us to define standards for how local networks work (to provide applications with a predictable environment), or to define standards which all applications should adhere to (to minimize security issues) which can be incorporated by reference into other protocol specifications. regarding the section on "Quality and Architectural Review". what strikes me about this section is the (implicit) assumption that architecture is done after the fact. rather than looking ahead to minimize and resolve conflicts well before they acquire the inertia of wide deployment, we try to fix things after the fact.