From: Brian E Carpenter [mailto:brc(_at_)zurich(_dot_)ibm(_dot_)com]
The proper cure for the disease Keith names has been agreed upon
for years now: early cross-area expert review.
I fully agree.
The question is whether this necessarily works to the intended effect.
I think that it has to be possible for a WG to solicit cross-area review but
after due consideration of the advice reject it.
For example lets take BEEP which is still nominally an IETF Draft Standard even
though at this point a rational evaluation of its status would be to consider
it HISTORIC or DEPRICATED*. BEEP is simply not a player in the Web Services
world where the only platforms that are being discussed are SOAP or layering on
raw HTTP.
So now lets imagine that someone brings a proposal to the IETF that is layered
on SOAP and the WS-* stack. Are they to be required to rewrite it to support
BEEP just because a few folk in the apps area don't recognize reality?
There has to be room here for "Your proposal adds nothing of value to our
project and will only harm it".
In particular I think we really need to squash the mindset that goes "I do not
have to think about how to persuade people to deploy my protocol because I can
attach it to other protocols that people actually want to deploy".
BEEP is a case in point. It was rushed through in a few months so that the IETF
could claim it had peed on the Web Services area first. The authors did not
attempt the type of broad outreach that the proponents of SOAP engaged in.
If the authors had been forced to think about the problem of evangelising their
platform it might have been more successful. Instead they rammed it through the
IETF without any attempt at consensus building in the application developer
community then tried to imply that IETF standards are expected to be based on
BEEP, not SOAP.
This is particularly important in the security area and for any protocol with
security issues - in other words always. Not so long ago we used to have a
habit of insisting that everything work over everything and that agnostic
support for HTTP, SMTP, NNTP, MIME, PGP, S/MIME. Now we recognize that the
kitchen sink approach is terrible for security, we multiply the number of code
paths for no good reason.
* There is actually a bug here in BCP 9. It should be possible to change the
status of a platform specification so that no future standards track
specifications are built on it without affecting the status of existing
standards. For example IPv4 hould at this point be considered DEPRICATED since
all new standards proposals are required to support IPv6. An interesting
feature of the IETF process is that a majority of RFCs with 'STANDARD' status
would be more appropriately considered DEPRICATED or HISTORIC (RFC 822, etc etc
etc )
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf