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>
|