> From: Brian E Carpenter [mailto:brc@xxxxxxxxxxxxxx] > > 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf