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.