John,
JCK> Since the secretariat is
JCK> operating with very tight resources (something else that has
JCK> been in enough documents and presentations that I assume/hope
JCK> everyone knows), it is in _our_ advantage to let them automate
JCK> anything they can sensibly automate without causing _severe_
JCK> problems. Conversely, asking for things that might take large
JCK> amounts of time and energy (such as per-user setting of tag
JCK> fields or application of spam filtering), is, IMO, pretty lousy
JCK> prioritization.
Let's take this a bit further: For any suggestion involving computing
and/or communication functionality, proposals should come with the
resources to do the major work, where the Secretariat only has to
provide some interface information.
JCK> (iii) I am, personally, getting concerned that the IETF is
JCK> approaching the point where we are more concerned about process
JCK> and administration than we are about doing high-quality design
yup.
So, here is a simple suggestion for anyone proposing anything in the
IETF:
Explain what real and significant problem it responds to and what
it will take to develop and operate it. Who must do the work,
what are their incentives for doing it and why should we believe
they will be successful at doing it anytime soon?
Interestingly, this applies both to protocol design suggestions
and to IETF process revision.
We need to start focusing on small sets of essential, near-term
problems, with core, near-term solutions. As a group, we have zero
success with any other approach.
d/
--
Dave Crocker <dcrocker-at-brandenburg-dot-com>
Brandenburg InternetWorking <www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>
|